Thanks for reporting this problem! I filed a Firefox bug:

https://bugzilla.mozilla.org/show_bug.cgi?id=1506038

This bug is actually a regression in Firefox 58 from the fix for a use-after-free bug (CVE-2018-5097):

https://bugzilla.mozilla.org/show_bug.cgi?id=1387427

I thought it was intentional and not a bug - thanks for reporting! It's true that I don't see flash-of-unstyled-content on HTML and XHTML pages, unless the CSS file is delayed by many seconds. I noticed another bug though - the Firefox inspector tool doesn't show style rules for the XML document.

Once upon a time, the whole internet was going to be built this way!

Client side XSLT has one terrific advantage : it allows splitting up a page into dynamic and static parts. This allows you to cache almost-static-but-not-really pages very efficiently. E.g. a news paper front page with a “logged in as…” section top right, but otherwise equal content. Or HN comment pages for logged in users, which currently are uncached and can cause quite heavy load on the server for heavy threads, simply by virtue of people viewing it. I remember a situation where they explicitly asked: please log out when viewing this comment page—that shouldn’t be necessary.

I still think client side XSLT is a good thing. I write simple documents and it is automatically converted client side. The world's best static site generator.

I gives me the best of two worlds: simple markup with complete control of output and CSS styling and instant changes of all documents without a compilation step.

XSLT got an unfair shake. Yes, XML is ugly, and verbose, and painful to write code in, but the ideas were very good. Most users never understood the processing model or the declarative/functional nature of XSLT, and so tried to write procedural code with it, with predictably nasty outcomes (hint: <xsl:if> is almost always a code smell). But those who did get it, could use it to write some pretty elegant little programs.

I liked XSLT for XML to XML but using it for creating HTML was a nightmare.

I agree this is very unusual. It's also somewhat annoying, for example I can't just send this to my Kindle to read it, and I can imagine other tools failing on this as well.

Which is more the fault of the Kindle than the authors. It's Docbook, a standard that was invented for the purpose of writing books.

It's great to use DocBook for writing books! (Actually, I don't think this is true for most books, but you do you.) But I would argue that processors that are designed to take HTML as input are not at fault for failing to process non-HTML documents. (Many, but not all) web browsers can render and style XML like this, but I'd argue that this is -- somewhat ironically given the article's subject -- probably not the best approach to putting DocBook files on the web.

The only way to build a fully conformant browser is to support rendering HTML as SGML with a DTD. Toy/specialty renderers skip over that step since you can assume 99.9999% of web documents will be HTML. However, they would completely fall apart on standard SGML, styled XML, etc.

Writing good software is hard I guess :)

I just tried it on Pocket, and it keeps switching me to the web version... which is a bit frustrating, since the source code / DocBook [1] XML format looks ideal for describing a Pocket article.

Seems DocBook has been around since 1999, judging from when the first O'Reilly book was published about it [2].

I just flagged it with the Pocket app's "Report An Article Display Problem" feature, but it is such a niche use case that I can't imagine them spending time on it.

[1] https://en.wikipedia.org/wiki/DocBook

[2] https://www.oreilly.com/openbook/docbook/book/docbook.html

Kindle will probably take it away from you anyway.

ya and here I am trying to save this to instapaper and wondering wtf is wrong with this guy.

Also cannot read with dark reader. My eyes! -.-

This is XML, Dark Reader works for HTML only.