Hacker News Reader

> 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.

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.

> 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!

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.

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.

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.

Server side includes were pretty common back in the day. https://en.wikipedia.org/wiki/Server_Side_Includes

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.

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.

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.

    > 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.

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

The fixed height requirement makes them hard to use in a responsive way.

A neat solution for this: https://github.com/davidjbradshaw/iframe-resizer

That's a lot of code just to set the height of an iframe.

> 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 .

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.

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

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.

Yep, I’m not disagreeing with anything you’re saying here :)

> 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.p...

[2] https://blogs.msdn.microsoft.com/murrays/2016/09/07/unicodem...

> 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?

> 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.

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?

But people do print web sites.

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.

This is exactly what the print media query is for, which is supported in all modern browsers.

https://joshuawinn.com/css-print-media-query/

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.

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.

It's actually all already standardised in CSS, since like a decade ago or so, yet no major web-browser has proper support for it.

I've tried using it for my resume since may about 10 years ago, to make it possible to convert it to PDF with a standard browser, but to this day many of these features aren't fully supported.

That's kinda the main selling point of software like Prince, which has implemented all of this ages ago, but it requires a licence.

https://en.wikipedia.org/wiki/Prince_(software)

The partition into pages is not a crucial point of proper typesetting. If I understand the OP, the main complain is that you cannot properly typeset text with equations in a standard way that looks acceptable.