4 ms·

HTML is the answer. - Can be opened on every device - Content can be embedded in base64, so you only have to share one file - Dynamic layout, so it looks ni

HTML is the answer. - Can be opened on every device - Content can be embedded in base64, so you only have to share one file - Dynamic layout, so it looks nice even on phones - Searchable, standardized XML structure - Great customizability through CSS and optionally JS - Can be written in markdown - Basic support for page breaks, if you really must print the document (IA Writer already has some HTML-Templates meant for printing.) The only downside I can think of, is that you can't lock the document to prevent edits. However, conventions are what keeps PDF alive. Until the academic world realizes that they can do better than Latex, we're stuck.

chromanoid 6y ago
I disagree. The answer is not found yet. Even when using semantic HTML elements it's too much of a styling language. We need a system that solves the overlapping markup problem and is fully semantic.
adrian_b 6y ago
I have seen here similar opinions about HTML vs. PDF in a few other threads. However, this is a matter of personal opinion and I am certain that nobody knows how many people prefer PDF and how many prefer HTML. I strongly prefer PDF for any non-ephemeral content that I might need to read twice or more times, so I hate anyone who forces me to read an HTML user manual or scientific paper, instead of providing PDF documents for them. Even if HTML can be opened on every device, it also looks different on every device and it looks bad on those that are different from the one used by the developer (unless the HTML pages have been carefully designed to look good on various devices, which seldom happens). Even on a small smartphone screen, I prefer a good PDF viewer with a good user interface that makes it easy to zoom & pan, instead of the feeble attempts of the Web browsers to reformat the text, which make very difficult the navigation through complex technical documents. "Print" support is horrible for HTML. Modern Web pages, which use a lot of JS, are almost always mutilated when you use the "Print" command in both Chrome and Firefox, even if they display the pages correctly outside the "Print" mode.
zzless 6y ago
To make some counterpoints: - On any device as long as it runs a browser - You can write TeX documents as a single file with ease - Phones are not designed for reading, so dynamic layout or not, it will still be inferior to finely typeset document - With care so can be TeX; carelessly written HTML docs will be just as bad as anything else - CSS is a pretty poor layout tool; typographically speaking, CSS is very subpar to TeX's capabilities, using JS... well how much better is it than just using macros in TeX/LaTeX? - markdown is fine for simple stuff but for highly complicated documents involving lots of generated tables, lists, and mathematics it is almost like having no tool at all; - but many people DO like printed documents (I rarely can stand reading anything but basic technical stuff on screen, say language reference is fine but anything that requires thinking, has to be printed); TeX is not locked to pdf in any way (it is not even it's native format). HTML's support for formulas is primitive (the only decent tools available are ... based on TeX). Academic world is not entirely uniform either but while I do think LaTeX is not ideal (TeX is though), I simply shudder when I think about Word or any MS or Adobe products.
- rsfern 6y ago
  Counter counter point: I pretty regularly read pdf docs on my phone, and it’s a horrible experience. I went so far as to write a script that downloads the Tex source of a paper from arxiv, changes up the paper size to match my phone screen, and recompiles the paper. It’s ok for text-heavy documents, but doesn’t work well for most figures. And most of my field does not post preprints (or use LaTeX at all). For me the ideal solution would be something like org mode -> html output. I think the main gap that isn’t really addressed by any tool I’ve seen is reference management
- comex 6y ago
  > Phones are not designed for reading, so dynamic layout or not, it will still be inferior to finely typeset document Personally, I find my phone to be my favorite medium to read prose on, not inferior to anything – including printed paper, which I never use if I can help it. It works for books and most webpages, but PDFs are a disaster. My second preference is my laptop. Its screen is big enough to make reading PDFs an acceptable experience, but not a great one. When viewing at an optimal zoom level for me, there's almost enough vertical space to fit an entire normally-sized page… but not quite. Which means I have to scroll. In the common case that the paper has two columns, I have to scroll down to read the bottom left of the page, then back up to read the top right, then back down to read the bottom right. Oh, and it's always great hunting for the figures in a paper, because of course they have to be nicely lined up in a corner of a page, even if that leaves them far from the text that references them. It's a compromise that makes total sense in print, but feels silly on a screen. So TeX's output is good in print but awkward on a screen. (It may not be limited to PDF, but I'm pretty sure all its output formats assume a fixed page size.) Meanwhile, HTML is good on a screen, but I agree that it's awkward in print. What we need is a format that's good at both, and that doesn't currently exist.
tannhaeuser 6y ago
Well, the entire idea of SGML, on which HTML is based, is to use a custom markup vocabulary adequate for your project (this is distinctively more pronounced in SGML which originally always had to have a DTD than it is in XML with its various additional, optional schema mechanisms targeted at enterprise use). However, HTML is almost the same markup vocabulary for casual academic publishing at CERN it was 30 years ago; with everything around it (CSS, JS) having changed beyond recognition. It is understandable that once JS was out there (plus div and span generic containers), evolving HTML wasn't essential as you could always fallback to using JS. Styling factored out into an ever-growing ad-hoc language with low barriers to changes called CSS further contributed to the fossilization of HTML, yet the fixation towards a 1990s vision of HTML can't entirely be explained by these two factors alone. My guess is that HTML was locked in W3C's long-standing, failed attempt to replace SGML by its subset XML as meta-syntax. With WHATWG's HTML5, parsing was specified in a procedural way, and self-contained in the HTML spec itself rather than in reference to SGML or XML. The way the HTML5 grammar was presented, though, could only lead to further hindrance of its evolution since Ian Hickson captured only the result grammar of HTML4, but not its original construction rules and principles. For example, in [1] I make the point that > By recovering HTML's original parsing rules from HTML5's specification text, we conclude that HTML5's parsing rules are represented adequately, and more succinctly, since avoiding redundantly specifying p-terminating elements. > This interpretation is also supported by the fact that for the HTML5.1 specification update (vs. HTML5), the new details, figcaption, figure and menu elements (which are flow-only elements) but not the new picture element (which can also be used in phrasing content) have been added to the set of p-terminating elements. All in all, HTML doesn't appear to be a rational, recommendable authoring format for any non-trivial writing project. After more than 30 years, it's still SGML that has all the power needed: can handle markdown and other custom Wiki syntax, can deal with and produce any HTML, has stylesheets and type-safe text macro expansion and templating. For the LISP lovers on HN, there's even the OpenJade project (dormant since about 2008 or so) for using Scheme-based DSSSL with SGML. [1]: http://sgmljs.net/docs/html5.html http://sgmljs.net/docs/html5.html

chromanoid 6y ago

I disagree. The answer is not found yet. Even when using semantic HTML elements it's too much of a styling language. We need a system that solves the overlapping markup problem and is fully semantic.

adrian_b 6y ago

I have seen here similar opinions about HTML vs. PDF in a few other threads. However, this is a matter of personal opinion and I am certain that nobody knows how many people prefer PDF and how many prefer HTML. I strongly prefer PDF for any non-ephemeral content that I might need to read twice or more times, so I hate anyone who forces me to read an HTML user manual or scientific paper, instead of providing PDF documents for them. Even if HTML can be opened on every device, it also looks different on every device and it looks bad on those that are different from the one used by the developer (unless the HTML pages have been carefully designed to look good on various devices, which seldom happens). Even on a small smartphone screen, I prefer a good PDF viewer with a good user interface that makes it easy to zoom & pan, instead of the feeble attempts of the Web browsers to reformat the text, which make very difficult the navigation through complex technical documents. "Print" support is horrible for HTML. Modern Web pages, which use a lot of JS, are almost always mutilated when you use the "Print" command in both Chrome and Firefox, even if they display the pages correctly outside the "Print" mode.

zzless 6y ago

To make some counterpoints: - On any device as long as it runs a browser - You can write TeX documents as a single file with ease - Phones are not designed for reading, so dynamic layout or not, it will still be inferior to finely typeset document - With care so can be TeX; carelessly written HTML docs will be just as bad as anything else - CSS is a pretty poor layout tool; typographically speaking, CSS is very subpar to TeX's capabilities, using JS... well how much better is it than just using macros in TeX/LaTeX? - markdown is fine for simple stuff but for highly complicated documents involving lots of generated tables, lists, and mathematics it is almost like having no tool at all; - but many people DO like printed documents (I rarely can stand reading anything but basic technical stuff on screen, say language reference is fine but anything that requires thinking, has to be printed); TeX is not locked to pdf in any way (it is not even it's native format). HTML's support for formulas is primitive (the only decent tools available are ... based on TeX). Academic world is not entirely uniform either but while I do think LaTeX is not ideal (TeX is though), I simply shudder when I think about Word or any MS or Adobe products.

rsfern 6y ago
Counter counter point: I pretty regularly read pdf docs on my phone, and it’s a horrible experience. I went so far as to write a script that downloads the Tex source of a paper from arxiv, changes up the paper size to match my phone screen, and recompiles the paper. It’s ok for text-heavy documents, but doesn’t work well for most figures. And most of my field does not post preprints (or use LaTeX at all). For me the ideal solution would be something like org mode -> html output. I think the main gap that isn’t really addressed by any tool I’ve seen is reference management
comex 6y ago
> Phones are not designed for reading, so dynamic layout or not, it will still be inferior to finely typeset document Personally, I find my phone to be my favorite medium to read prose on, not inferior to anything – including printed paper, which I never use if I can help it. It works for books and most webpages, but PDFs are a disaster. My second preference is my laptop. Its screen is big enough to make reading PDFs an acceptable experience, but not a great one. When viewing at an optimal zoom level for me, there's almost enough vertical space to fit an entire normally-sized page… but not quite. Which means I have to scroll. In the common case that the paper has two columns, I have to scroll down to read the bottom left of the page, then back up to read the top right, then back down to read the bottom right. Oh, and it's always great hunting for the figures in a paper, because of course they have to be nicely lined up in a corner of a page, even if that leaves them far from the text that references them. It's a compromise that makes total sense in print, but feels silly on a screen. So TeX's output is good in print but awkward on a screen. (It may not be limited to PDF, but I'm pretty sure all its output formats assume a fixed page size.) Meanwhile, HTML is good on a screen, but I agree that it's awkward in print. What we need is a format that's good at both, and that doesn't currently exist.

tannhaeuser 6y ago

Well, the entire idea of SGML, on which HTML is based, is to use a custom markup vocabulary adequate for your project (this is distinctively more pronounced in SGML which originally always had to have a DTD than it is in XML with its various additional, optional schema mechanisms targeted at enterprise use). However, HTML is almost the same markup vocabulary for casual academic publishing at CERN it was 30 years ago; with everything around it (CSS, JS) having changed beyond recognition. It is understandable that once JS was out there (plus div and span generic containers), evolving HTML wasn't essential as you could always fallback to using JS. Styling factored out into an ever-growing ad-hoc language with low barriers to changes called CSS further contributed to the fossilization of HTML, yet the fixation towards a 1990s vision of HTML can't entirely be explained by these two factors alone. My guess is that HTML was locked in W3C's long-standing, failed attempt to replace SGML by its subset XML as meta-syntax. With WHATWG's HTML5, parsing was specified in a procedural way, and self-contained in the HTML spec itself rather than in reference to SGML or XML. The way the HTML5 grammar was presented, though, could only lead to further hindrance of its evolution since Ian Hickson captured only the result grammar of HTML4, but not its original construction rules and principles. For example, in [1] I make the point that > By recovering HTML's original parsing rules from HTML5's specification text, we conclude that HTML5's parsing rules are represented adequately, and more succinctly, since avoiding redundantly specifying p-terminating elements. > This interpretation is also supported by the fact that for the HTML5.1 specification update (vs. HTML5), the new details, figcaption, figure and menu elements (which are flow-only elements) but not the new picture element (which can also be used in phrasing content) have been added to the set of p-terminating elements. All in all, HTML doesn't appear to be a rational, recommendable authoring format for any non-trivial writing project. After more than 30 years, it's still SGML that has all the power needed: can handle markdown and other custom Wiki syntax, can deal with and produce any HTML, has stylesheets and type-safe text macro expansion and templating. For the LISP lovers on HN, there's even the OpenJade project (dormant since about 2008 or so) for using Scheme-based DSSSL with SGML. [1]: http://sgmljs.net/docs/html5.html http://sgmljs.net/docs/html5.html