6 ms·

> This is unsurprising given the total willingness and business incentive of major players such as Google to drive the applications use case and their comparati

> This is unsurprising given the total willingness and business incentive of major players such as Google to drive the applications use case and their comparative disinterest in the semantic hypertext use case Indeed, I am consistently surprised at the document-display features that are still missing from web browsers that are increasingly preoccupied with serving as application runtimes. The web was originally envisioned as a platform for scientists to share documents, but thanks to Google dropping MathML, there's still no cross-browser, non-kludge way to display math. Browsers still can't justify text properly. Even with hyphenation (which iirc is still a problem in Chrome), the greedy algorithm used for splitting text across lines still results in too much space between words when justified. There seems to be a complete lack of interest in Paged Media support, so if you want your web-page to be printable with nice formatting, you basically need to provide it as a PDF. I've gotten to the point where I'm often happier to read something in-browser as a PDF than as a web-page. Sure, it can't reflow properly, but at least it won't have a 2-inch sticky header and make XHR requests to 10 different domains. My vision-impaired father reports that his text-to-speech software now works better with PDFs than with real web-pages. This is insanity.

ahartmetz 7y ago
Also there is no way to include a file... Let's say you have a menu at the top of your website. You can't use frames because frames are bad mkay, and you can't include it. So you have to copy-paste it into every page manually, using some build system or even using some DHTML technology. Chrome and only Chrome has an include extension, but for security reasons (something about cross-site foo), you can't use it when testing an HTML file on your disk, because you need a hostname to check the same origin policy. You need to put it into a local webserver, which, fortunately, is fairly easy with Python.
- wodenokoto 7y ago
  Yeah, I never understood why there wasn't an <include> element in HTML, that would just paste the content of the linked document. Why wasn't such an element added in the late 90's or early 2000? In the early days, when dynamic webpages were processed by something called CGI and even when we started using PHP, this was like 90% of the use case for doing a dynamic webpage. The last 10% might have been some sort of counter.
  - tyingq 7y ago
    Server side includes were pretty common back in the day. https://en.wikipedia.org/wiki/Server_Side_Includes https://en.wikipedia.org/wiki/Server_Side_Includes
    - ahartmetz 7y ago
      Right, but server-side includes mean unnecessary technology and bandwidth use to work around the absence of a trivial(ish, there are probably a few snags) feature.
    - meerita 7y ago
      They weren't common. It depended mainly of the server configuration, language used, etc. Most of the websites were static with some dynamic pages. Includes becane really popular with the rise of PHP and ASP language.
  - sjy 7y ago
    When I first started out I was using free web hosts that didn't support server-side includes or PHP, so I ended up building my own JavaScript front end framework. Unfortunately, I didn't actually know any JavaScript, so I wrapped every line of my HTML header template in document.write() and included it in a script tag. There were some performance issues.
  - zmix 7y ago
    > I never understood why there wasn't an <include> > element in HTML, that would just paste the content of > the linked document. Why wasn't such an element added > in the late 90's or early 2000? As far as I know, for SGML (and therefore old fashioned XML, too), 'include' gets realized via parsing of external &entities;. That's how the Mozilla XUL applications (Seamonkey, Firefox, Thunderbird) etc. realized localization, for example. I don't know, when XInclude has first been ratified (the current, 2nd revision, of the spec is from 2006), but with it, a generic inclusion mechanism exists for XML, therefore also for XHTML. With XHTML you could (in theory, as said, the spec is there) use XInclude. <?xml version='1.0'?> <html xmlns="http:www.w3.org/1999/xhtml" xmlns:xi="http://www.w3.org/2001/XInclude"> <head> </head> <body> <p>120 MHz is adequate for an average home user.</p> <xi:include href="disclaimer.xml"/> </body> </html> I am not quite sure, yet, how namespace mixins are handled in XHTML, I think, one must define a new schema (which, honestly is a crappy requirement and should be abandoned), effectively creating an XHTML+XInclude document type, but that may be only a real issue for strict validation.
- geokon 7y ago
  Why are iframes bad in this case? In my purely HTML github pages I ended up hacking a header into the common CSS file bc that's "included" everywhere.. it's ugly and I don't think you can even put links in it... but it sorta works. If I wanna tweak it then it's all in one file PS: this is a naiive question from a non-web dev
  - tyingq 7y ago
    The fixed height requirement makes them hard to use in a responsive way.
    - CharlesW 7y ago
      A neat solution for this: https://github.com/davidjbradshaw/iframe-resizer https://github.com/davidjbradshaw/iframe-resizer
      - ChrisSD 7y ago
        That's a lot of code just to set the height of an iframe.
- josefx 7y ago
  > but for security reasons (something about cross-site foo), you can't use it when testing an HTML file on your disk, I think you can disable that check as a command line option. I cannot check it right now since I don't have chrome installed however I think it was --allow-file-access-from-files .
- colanderman 7y ago
  You can do this with XSLT, which actually works in Chrome, Firefox, and Safari, both on mobile and desktop. (I've been using it in a small site of my own for a while.) You can even do stuff like page-dependent highlighting of menu items without any JavaScript. Granted, I'm surprised XSLT is supported at all in modern browsers, and who knows how long it will continue to be supported, but it does work now for the basic "menubar at top" use case.
robin_reala 7y ago
Chrome didn’t drop MathML, they dropped their horrible implementation. Currently Igalia are building a new Chromium MathML implentation: https://mathml.igalia.com/ https://mathml.igalia.com/
- deleted 7y ago
  [deleted]
- aplaice 7y ago
  They dropped their implementation of MathML in 2013. In the six years since then, they didn't fix it or replace it with a better one. I'm extremely excited by Igalia's work on MathML and glad that the Google Chrome team had given it their preliminary approval, but in the context of criticising Google for working on the "application web" and ignoring the "document web" (for scientists and others), it doesn't change anything[0]. Google is neither doing the work, nor funding it[1], and their contribution until now has mostly (solely?) been to be open about merging it. [0] not that you explicitly said that it did... [1] It's funded by the NISO and the Alfred P. Sloan Foundation.
  - robin_reala 7y ago
    Yep, I’m not disagreeing with anything you’re saying here :)
AndrewDucker 7y ago
A "page" exists because paper exists. When you aren't using paper why would you break up your content into arbitrary fixed size increments, rather than using (say) "sections", which are the size of the content you put into them?
- Tomte 7y ago
  But people do print web sites.
- pgcj_poster 7y ago
  Right, you shouldn't do that. Instead, you should leave your content as-is when viewed on a screen but add a separate stylesheet that gets applied only when you print to format your content for the paper: eg. put footnotes at the bottom of the page. Unfortunately, features like this are largely missing from browsers.
  - gboss 7y ago
    This is exactly what the print media query is for, which is supported in all modern browsers. https://joshuawinn.com/css-print-media-query/ https://joshuawinn.com/css-print-media-query/
- coldtea 7y ago
  For one, because you want to display existing, page-divided documents (e.g. books), and keep the same frame of reference (the page). Second, because you want to print -- in which case, your artifact ends up in a page. Third, because a screenful, even if dynamic (based on resolution, etc) is still a kind of a "page" (in HTML parlance, a "viewport"), and you might want to design to take advantage of what fits in one.
- sjy 7y ago
  Breaking up documents into arbitrary (but specified) fixed size increments is a useful way to refer to parts of a large document. Sure, it'd be better if everything was hyperlinked with semantic anchors, but until the trends identified in the article are reversed, that's not going to happen. Pagination is a good fallback option that everyone understands intuitively.
sidpatil 7y ago
> Browsers still can't justify text properly. Even with hyphenation (which iirc is still a problem in Chrome), the greedy algorithm used for splitting text across lines still results in too much space between words when justified. > There seems to be a complete lack of interest in Paged Media support, so if you want your web-page to be printable with nice formatting, you basically need to provide it as a PDF. These are the two main reasons I think of whenever someone complains that scientific publication should be Web-based instead of PDFs. Browsers are still generally lacking when it comes to proper typesetting.
- Joeri 7y ago
  On the other hand, the restriction that scientific publications must be renderable onto reconstituted dead trees makes it that authors often spend multiple “pages” explaining what a single interactive chart would explain far better. This makes science less accessible than it should be and in my view is part of the reason media so often misrepresent scientific findings.
  - rauhl 7y ago
    > On the other hand, the restriction that scientific publications must be renderable onto reconstituted dead trees makes it that authors often spend multiple “pages” explaining what a single interactive chart would explain far better. On the gripping hand, in a century those reconstituted dead trees will still be legible by anyone who can lay hands on them; the likelihood that an interactive presentation from 2019 will be legible to anyone other than a computer archæologist in 2119 is effectively nil. Heck, there’s a decent chance that it won’t work in a year or two!
  - ska 7y ago
    Interactive charts are great for supplemental material, but moving primary sources (e.g. journal papers) to anything as ephemeral as the current web stack is a terrible idea.
mwcampbell 7y ago
> My vision-impaired father reports that his text-to-speech software now works better with PDFs than with real web-pages. I have enough experience with PDFs and screen readers that I find this very surprising. Which PDF reader does he use, and does he get most or all of his PDFs from a particular source?
combatentropy 7y ago
> Browsers still can't justify text properly. Even with hyphenation (which iirc is still a problem in Chrome), the greedy algorithm used for splitting text across lines still results in too much space between words when justified. You might try: word-spacing: -0.1ex; Good justification of text requires that sometimes the spacing between words is a little narrower than normal. Perhaps browsers are unwilling to do this unless you explicitly give them permission. But I wish they could just adopt a good text-flow algorithm like Adobe InDesign had. But good justification also requires hyphenation. And last I looked, browser support was spotty. It did not work on Chromebooks, for example.
WorldMaker 7y ago
> thanks to Google dropping MathML, there's still no cross-browser, non-kludge way to display math. Probably a huge tangent, but UnicodeMath [1][2] is at least encodable and (basically) readable just about everywhere UTF-8 (et al) is supported, which is all browsers today, if unfortunately only just a linear presentation by default. I'm surprised there aren't more progressive renderers for it to up-level it to more traditional two-dimensional renders in browsers directly yet (after several years being standardized as a Unicode Technical Note). A cursory glance shows that even MathJax still doesn't seem to support UnicodeMath (at least out of the box), like it does MathML and AsciiMath. (But I think raw UnicodeMath is easier to read than MathML or AsciiMath in a "progressive" fashion from linear to "professional"/two-dimensional rendering. Though that's a personal preference/aesthetic that can get quite subjective.) [1] http://www.unicode.org/notes/tn28/UTN28-PlainTextMath-v3.1.pdf http://www.unicode.org/notes/tn28/UTN28-PlainTextMath-v3.1.p... [2] https://blogs.msdn.microsoft.com/murrays/2016/09/07/unicodemath/ https://blogs.msdn.microsoft.com/murrays/2016/09/07/unicodem...

ahartmetz 7y ago

Also there is no way to include a file... Let's say you have a menu at the top of your website. You can't use frames because frames are bad mkay, and you can't include it. So you have to copy-paste it into every page manually, using some build system or even using some DHTML technology. Chrome and only Chrome has an include extension, but for security reasons (something about cross-site foo), you can't use it when testing an HTML file on your disk, because you need a hostname to check the same origin policy. You need to put it into a local webserver, which, fortunately, is fairly easy with Python.

wodenokoto 7y ago
Yeah, I never understood why there wasn't an <include> element in HTML, that would just paste the content of the linked document. Why wasn't such an element added in the late 90's or early 2000? In the early days, when dynamic webpages were processed by something called CGI and even when we started using PHP, this was like 90% of the use case for doing a dynamic webpage. The last 10% might have been some sort of counter.
- tyingq 7y ago
  Server side includes were pretty common back in the day. https://en.wikipedia.org/wiki/Server_Side_Includes https://en.wikipedia.org/wiki/Server_Side_Includes
  - ahartmetz 7y ago
    Right, but server-side includes mean unnecessary technology and bandwidth use to work around the absence of a trivial(ish, there are probably a few snags) feature.
  - meerita 7y ago
    They weren't common. It depended mainly of the server configuration, language used, etc. Most of the websites were static with some dynamic pages. Includes becane really popular with the rise of PHP and ASP language.
- sjy 7y ago
  When I first started out I was using free web hosts that didn't support server-side includes or PHP, so I ended up building my own JavaScript front end framework. Unfortunately, I didn't actually know any JavaScript, so I wrapped every line of my HTML header template in document.write() and included it in a script tag. There were some performance issues.
- zmix 7y ago
  > I never understood why there wasn't an <include> > element in HTML, that would just paste the content of > the linked document. Why wasn't such an element added > in the late 90's or early 2000? As far as I know, for SGML (and therefore old fashioned XML, too), 'include' gets realized via parsing of external &entities;. That's how the Mozilla XUL applications (Seamonkey, Firefox, Thunderbird) etc. realized localization, for example. I don't know, when XInclude has first been ratified (the current, 2nd revision, of the spec is from 2006), but with it, a generic inclusion mechanism exists for XML, therefore also for XHTML. With XHTML you could (in theory, as said, the spec is there) use XInclude. <?xml version='1.0'?> <html xmlns="http:www.w3.org/1999/xhtml" xmlns:xi="http://www.w3.org/2001/XInclude"> <head> </head> <body> <p>120 MHz is adequate for an average home user.</p> <xi:include href="disclaimer.xml"/> </body> </html> I am not quite sure, yet, how namespace mixins are handled in XHTML, I think, one must define a new schema (which, honestly is a crappy requirement and should be abandoned), effectively creating an XHTML+XInclude document type, but that may be only a real issue for strict validation.
geokon 7y ago
Why are iframes bad in this case? In my purely HTML github pages I ended up hacking a header into the common CSS file bc that's "included" everywhere.. it's ugly and I don't think you can even put links in it... but it sorta works. If I wanna tweak it then it's all in one file PS: this is a naiive question from a non-web dev
- tyingq 7y ago
  The fixed height requirement makes them hard to use in a responsive way.
  - CharlesW 7y ago
    A neat solution for this: https://github.com/davidjbradshaw/iframe-resizer https://github.com/davidjbradshaw/iframe-resizer
    - ChrisSD 7y ago
      That's a lot of code just to set the height of an iframe.
josefx 7y ago
> but for security reasons (something about cross-site foo), you can't use it when testing an HTML file on your disk, I think you can disable that check as a command line option. I cannot check it right now since I don't have chrome installed however I think it was --allow-file-access-from-files .
colanderman 7y ago
You can do this with XSLT, which actually works in Chrome, Firefox, and Safari, both on mobile and desktop. (I've been using it in a small site of my own for a while.) You can even do stuff like page-dependent highlighting of menu items without any JavaScript. Granted, I'm surprised XSLT is supported at all in modern browsers, and who knows how long it will continue to be supported, but it does work now for the basic "menubar at top" use case.

robin_reala 7y ago

Chrome didn’t drop MathML, they dropped their horrible implementation. Currently Igalia are building a new Chromium MathML implentation: https://mathml.igalia.com/ https://mathml.igalia.com/

deleted 7y ago
[deleted]
aplaice 7y ago
They dropped their implementation of MathML in 2013. In the six years since then, they didn't fix it or replace it with a better one. I'm extremely excited by Igalia's work on MathML and glad that the Google Chrome team had given it their preliminary approval, but in the context of criticising Google for working on the "application web" and ignoring the "document web" (for scientists and others), it doesn't change anything[0]. Google is neither doing the work, nor funding it[1], and their contribution until now has mostly (solely?) been to be open about merging it. [0] not that you explicitly said that it did... [1] It's funded by the NISO and the Alfred P. Sloan Foundation.
- robin_reala 7y ago
  Yep, I’m not disagreeing with anything you’re saying here :)

AndrewDucker 7y ago

A "page" exists because paper exists. When you aren't using paper why would you break up your content into arbitrary fixed size increments, rather than using (say) "sections", which are the size of the content you put into them?

Tomte 7y ago
But people do print web sites.
pgcj_poster 7y ago
Right, you shouldn't do that. Instead, you should leave your content as-is when viewed on a screen but add a separate stylesheet that gets applied only when you print to format your content for the paper: eg. put footnotes at the bottom of the page. Unfortunately, features like this are largely missing from browsers.
- gboss 7y ago
  This is exactly what the print media query is for, which is supported in all modern browsers. https://joshuawinn.com/css-print-media-query/ https://joshuawinn.com/css-print-media-query/
coldtea 7y ago
For one, because you want to display existing, page-divided documents (e.g. books), and keep the same frame of reference (the page). Second, because you want to print -- in which case, your artifact ends up in a page. Third, because a screenful, even if dynamic (based on resolution, etc) is still a kind of a "page" (in HTML parlance, a "viewport"), and you might want to design to take advantage of what fits in one.
sjy 7y ago
Breaking up documents into arbitrary (but specified) fixed size increments is a useful way to refer to parts of a large document. Sure, it'd be better if everything was hyperlinked with semantic anchors, but until the trends identified in the article are reversed, that's not going to happen. Pagination is a good fallback option that everyone understands intuitively.

sidpatil 7y ago

> Browsers still can't justify text properly. Even with hyphenation (which iirc is still a problem in Chrome), the greedy algorithm used for splitting text across lines still results in too much space between words when justified. > There seems to be a complete lack of interest in Paged Media support, so if you want your web-page to be printable with nice formatting, you basically need to provide it as a PDF. These are the two main reasons I think of whenever someone complains that scientific publication should be Web-based instead of PDFs. Browsers are still generally lacking when it comes to proper typesetting.

Joeri 7y ago
On the other hand, the restriction that scientific publications must be renderable onto reconstituted dead trees makes it that authors often spend multiple “pages” explaining what a single interactive chart would explain far better. This makes science less accessible than it should be and in my view is part of the reason media so often misrepresent scientific findings.
- rauhl 7y ago
  > On the other hand, the restriction that scientific publications must be renderable onto reconstituted dead trees makes it that authors often spend multiple “pages” explaining what a single interactive chart would explain far better. On the gripping hand, in a century those reconstituted dead trees will still be legible by anyone who can lay hands on them; the likelihood that an interactive presentation from 2019 will be legible to anyone other than a computer archæologist in 2119 is effectively nil. Heck, there’s a decent chance that it won’t work in a year or two!
- ska 7y ago
  Interactive charts are great for supplemental material, but moving primary sources (e.g. journal papers) to anything as ephemeral as the current web stack is a terrible idea.

mwcampbell 7y ago

> My vision-impaired father reports that his text-to-speech software now works better with PDFs than with real web-pages. I have enough experience with PDFs and screen readers that I find this very surprising. Which PDF reader does he use, and does he get most or all of his PDFs from a particular source?

combatentropy 7y ago

> Browsers still can't justify text properly. Even with hyphenation (which iirc is still a problem in Chrome), the greedy algorithm used for splitting text across lines still results in too much space between words when justified. You might try: word-spacing: -0.1ex; Good justification of text requires that sometimes the spacing between words is a little narrower than normal. Perhaps browsers are unwilling to do this unless you explicitly give them permission. But I wish they could just adopt a good text-flow algorithm like Adobe InDesign had. But good justification also requires hyphenation. And last I looked, browser support was spotty. It did not work on Chromebooks, for example.

WorldMaker 7y ago

> thanks to Google dropping MathML, there's still no cross-browser, non-kludge way to display math. Probably a huge tangent, but UnicodeMath [1][2] is at least encodable and (basically) readable just about everywhere UTF-8 (et al) is supported, which is all browsers today, if unfortunately only just a linear presentation by default. I'm surprised there aren't more progressive renderers for it to up-level it to more traditional two-dimensional renders in browsers directly yet (after several years being standardized as a Unicode Technical Note). A cursory glance shows that even MathJax still doesn't seem to support UnicodeMath (at least out of the box), like it does MathML and AsciiMath. (But I think raw UnicodeMath is easier to read than MathML or AsciiMath in a "progressive" fashion from linear to "professional"/two-dimensional rendering. Though that's a personal preference/aesthetic that can get quite subjective.) [1] http://www.unicode.org/notes/tn28/UTN28-PlainTextMath-v3.1.pdf http://www.unicode.org/notes/tn28/UTN28-PlainTextMath-v3.1.p... [2] https://blogs.msdn.microsoft.com/murrays/2016/09/07/unicodemath/ https://blogs.msdn.microsoft.com/murrays/2016/09/07/unicodem...