On 05/02/2013 10:41 PM, Norman Gray wrote:
Sarven and all, hello.
Hi Norman :)
On 2013 May 2, at 18:38, Sarven Capadisli <[email protected]> wrote:_What_ sucks on the web? Certainly not PDF.HTML/Web, PDF/Desktop?PDF/Web, HTML/Desktop? I'm not sure what you're trying to say here.
I was just trying to point that HTML is essentially Web friendly and that PDF is desktop friendly. Surely, both formats work on the other application, but there is at least some "intention" of where they are to be viewed. I'm not saying that's an absolute but more like a most common scenario.
So, I think PDF rather sucks on the Web because I can't always access it from any random Web browser.
Thus HTML can do some unimportant things better than PDF,Web pages. It will never take off.No no, the web is massively successful. HTML is a really clever hypertext format which is successful because it lets a number of things go wrong (it doesn't guarantee link integrity, links are all one-way, there's minimal text metadata, and so on). These deficiencies are seriously smart things to use to create a global hypertext. Web pages have taken off in a big way. It does not follow that HTML-based hypertext solves all text problems. In particular, there is nothing in the above set of clever properties which makes HTML obviously ideal for communicating long-form textual arguments.
Good points. I guess it is a philosophical discussion point whether HTML is suitable to communicate long-form of text. Frankly, if I really have to read something super long, I want it in paper in my hands.
It also does not follow that, such because the information is HTML-based somehow we are restricted from printing it.
And what is this 'desktop' of which you speak? PDF is for making posters, presentations, on-screen documents, and on-tablet documents -- lots of very distinct layout problems there. In the last case, you can even transfer the things to paper and read them in the bath, if you want.
I agree. I think I tried to clarify that earlier with HTML/Web, PDF/Desktop point.
but what itcan't do, which _is_ important, is make things readable. The visual appearance -- that is, the typesetting -- of rendered HTML is almost universally bad, from the point of view of reading extended pieces. I haven't (I admit) yet experimented with reading extended text on a tablet, but I'd be surprised if that made a major difference.I think you are conflating the job of HTML with CSS. Also, I think you are conflating readability with legibility as far as the typesetting goes. Again, that's something CSS handles provided that suitable fonts are in use.CSS can help make HTML pages more readable. Myself, I usually put quite a lot of effort into the CSS which accompanies web pages I write. But it takes a lot of effort to produce good CSS, and the case you're aiming to optimise is the case of a normal-length web-page (under 1000 words, say), with relatively small investments on the part of the reader. Distributing PDF, you have easy and precise control over fonts, layout, and overall design (or rather, you in principle have access to a style which is carefully designed). This makes it easy to produce something which is easy to read for thousands of words.
Indeed it takes time to pixel-perfect CSS if one wishes to do so. How long did it take LNCS or ACM-SIG to get it right?
It follows that, we do our lncs.css or acmsig.css and people simply use that in the HTML template (which we could also provide). So, no one is starting from scratch. That would be absurd and an unfair comparison.
But this is to some extent irrelevant, because I think we're now talking about a non-problem:Also, HTML is not the same as linked data; there's no 'dog food' here for us to eat.That's quite a generalization there? So, I would argue that "HTML" is more about eating dogfood in the Linked Data mailing list than parading on PDF. We are trying to build things one step at a time; HTML today, a URI that it can sit on tomorrow. Additional machine-friendly stuff the day after.What, seriously, is the connection between HTML and linked-data? If there is a deep connection, then HTML articles represent the linked-data community's dog-food, and it should be eaten. But there is no such deep connection.
It is a gateway. RDFa, Microdata, or even microformats to a certain degree can get us there. One block at a time. That's the point. I'm repeating this point constantly in this mailing list, so here it is one more time:
I don't care whether workshops, conference, or journals want to use XHTML or HTML5, or RDFa, Microdata or XYZ. They can decide that for themselves for the reasons that makes them sleep better at night. The point is that, if we have at least something like HTML, that's an excellent starting point.
I favour (X)HTML+RDFa for the task at hand, but I'm not going to demand that because I'm just one little me. At the end of the day, what I want to really see is that we can read each other's research on a standard looking webpage. I want to link to its interesting parts. I want to print it right off my browser. I want to dereference it and get structured statements out of it e.g., claims, conclusions, references etc. I want to interact with the charts by clicking randomly to learn more about it. I want to be able to change the sample data right from the page to see how their algorithm works. All of that.
We have these possibilities. Yet, some of us are overlooking this future, or insisting to keep things as is, meanhile preventing the community from getting there because they have their own agendas. That's clear!
-Sarven
smime.p7s
Description: S/MIME Cryptographic Signature
