3 ms·

How exactly do you think your HTML files from 2005 would render differently today? Sure, your modern browser engine would probably make slightly different decis

How exactly do you think your HTML files from 2005 would render differently today? Sure, your modern browser engine would probably make slightly different decisions with fonts and margins, but would that negatively impact the usability of a legal document, research paper, etc.? Meanwhile, you would have gotten things like robust search and real compatibility with mobile phones and e-readers for free. A heavily restricted subset of HTML to replace PDF as the 'archival' format would make the world so much better of a place.

Spooky23 7y ago
Formatting is important — all of the arguments made in favor of HTML can be made for plaintext. If you don’t care about format and want to read the document 30, 50, 100 or more years ago, you should use text. Will HTML formatting on a 4K display will look the same as an 800x600 monitor? Will all of the ancient display elements display the same? Will IE4 specific artifacts display? Search works fine in PDF. Mobile is not optimal, but platforms optimized for mobile require different design considerations. Few webpages look or function identically on mobile.
- ghostly_s 7y ago
  How is formatting important though? Semantic formatting, sure, but again, a 20-year-old HTML file still has that preserved. The em-perfect formatting inherent in PDF seems entirely purposeless unless you for some reason need to be able to reproduce a printed copy of the document exactly. Formulas are a special case, but the great majority of documents I see distributed in PDF would be more useful as HTML, and I don't buy the argument that it would risk archivability. At the end of the day, HTML is a plain-text format which is quite human-readable even if all the world's HTML renderers were somehow lost to the ages. The only use-case I can conceive for perfectly-reproducable layout if you are not a print publisher is in fields where it is convention to reference text by page+paragraph number; in those cases, the page number is actually semantic information so could quite trivially be encoded in the content of the document to maintain that referent. > Search works fine in PDF. Search works fine in PDFs that don't use hyphenation or which properly implement it, and when they don't it breaks silently in ways that are potentially disastrous. > Mobile is not optimal, but platforms optimized for mobile require different design considerations. And my point about mobile was you don't need to optimize for it. >Few webpages look or function identically on mobile. Again, it doesn't need to look identical. That is a falce requirement. There is no value in that. The only web pages that don't function on mobile are ones which have been optimized for desktop. We're not talking about general-purpose web pages here, we're talking about textual documents. This is not some hypothetical scenario, BTW. The UK has been using HTML over PDF for public-facing documents for a couple years now, it seems to be working out for them[1]. 1. https://gds.blog.gov.uk/2018/07/16/why-gov-uk-content-should-be-published-in-html-and-not-pdf/ https://gds.blog.gov.uk/2018/07/16/why-gov-uk-content-should...
  - ezequiel-garzon 7y ago
    The only web pages that don't function on mobile are ones which have been optimized for desktop. Although it's rare to find them nowadays, this is false for pages with no CSS at all. By no CSS I mean not even the infamous proprietary viewport meta tag... which is a posteriori being made CSS. Access for instance the basically unstyled page [1] with a $1000+ smartphone of our day... and you're likely to find unreadably small font. Now, you could argue [1] functions on mobile, but let's agree it's stretching the meaning of that term. But that's not the main point: HTML elements come and go (for instance MENU; find others in [2]), so it's clear that archival reliability is not a big priority. We all agree that ideally the source should always be made available (mandated if tax payers' money is involved if you ask me), but that doesn't invalidate the value of a universal presentational format. [1] http://www.qrg.northwestern.edu/papers/files/simhobby-local.htm http://www.qrg.northwestern.edu/papers/files/simhobby-local.... [2] https://meiert.com/en/indices/html-elements/ https://meiert.com/en/indices/html-elements/

Spooky23 7y ago

Formatting is important — all of the arguments made in favor of HTML can be made for plaintext. If you don’t care about format and want to read the document 30, 50, 100 or more years ago, you should use text. Will HTML formatting on a 4K display will look the same as an 800x600 monitor? Will all of the ancient display elements display the same? Will IE4 specific artifacts display? Search works fine in PDF. Mobile is not optimal, but platforms optimized for mobile require different design considerations. Few webpages look or function identically on mobile.

ghostly_s 7y ago
How is formatting important though? Semantic formatting, sure, but again, a 20-year-old HTML file still has that preserved. The em-perfect formatting inherent in PDF seems entirely purposeless unless you for some reason need to be able to reproduce a printed copy of the document exactly. Formulas are a special case, but the great majority of documents I see distributed in PDF would be more useful as HTML, and I don't buy the argument that it would risk archivability. At the end of the day, HTML is a plain-text format which is quite human-readable even if all the world's HTML renderers were somehow lost to the ages. The only use-case I can conceive for perfectly-reproducable layout if you are not a print publisher is in fields where it is convention to reference text by page+paragraph number; in those cases, the page number is actually semantic information so could quite trivially be encoded in the content of the document to maintain that referent. > Search works fine in PDF. Search works fine in PDFs that don't use hyphenation or which properly implement it, and when they don't it breaks silently in ways that are potentially disastrous. > Mobile is not optimal, but platforms optimized for mobile require different design considerations. And my point about mobile was you don't need to optimize for it. >Few webpages look or function identically on mobile. Again, it doesn't need to look identical. That is a falce requirement. There is no value in that. The only web pages that don't function on mobile are ones which have been optimized for desktop. We're not talking about general-purpose web pages here, we're talking about textual documents. This is not some hypothetical scenario, BTW. The UK has been using HTML over PDF for public-facing documents for a couple years now, it seems to be working out for them[1]. 1. https://gds.blog.gov.uk/2018/07/16/why-gov-uk-content-should-be-published-in-html-and-not-pdf/ https://gds.blog.gov.uk/2018/07/16/why-gov-uk-content-should...
- ezequiel-garzon 7y ago
  The only web pages that don't function on mobile are ones which have been optimized for desktop. Although it's rare to find them nowadays, this is false for pages with no CSS at all. By no CSS I mean not even the infamous proprietary viewport meta tag... which is a posteriori being made CSS. Access for instance the basically unstyled page [1] with a $1000+ smartphone of our day... and you're likely to find unreadably small font. Now, you could argue [1] functions on mobile, but let's agree it's stretching the meaning of that term. But that's not the main point: HTML elements come and go (for instance MENU; find others in [2]), so it's clear that archival reliability is not a big priority. We all agree that ideally the source should always be made available (mandated if tax payers' money is involved if you ask me), but that doesn't invalidate the value of a universal presentational format. [1] http://www.qrg.northwestern.edu/papers/files/simhobby-local.htm http://www.qrg.northwestern.edu/papers/files/simhobby-local.... [2] https://meiert.com/en/indices/html-elements/ https://meiert.com/en/indices/html-elements/