PDF was designed to look the same on any device/viewer and that's something that HTML/CSS/JS will likely never be able to do (every browser does things slightly different!). HTML also lacks good support for embedding resources in a single file and is much heavier to display (try coding a whole HTML + CSS + JS engine vs a basic PDF/A viewer!). Moreover HTML/CSS lacks all the typesetting features that Latex/Typst support out of the box.

But anyway here's a challenge for you: take some random small document in Latex/Typst and try converting it to HTML/CSS/JS while keeping the same layout and visual feelings. Make it a single file you can share with people and try seeing if all browsers display it the same way.

The key difference between print systems and web tech is responsiveness. Anything print related is primarily designed with dead tree format in mind, so the layout won't change, and you don't have to worry about text reflowing after editing.

It's also why LaTeX/PDF to HTML converters are so difficult to build, because the underlying engine has no semantic information about the structure (this may be changing with LLMs and multimodal setups).

One could ask if responsiveness is relevant for documents.

You could simply use a static layout for your html, and then add borders or zoom (just like in a pdf viewer).

Then you'd have the editability, accessibility and performance of html, with the same responsiveness as a pdf (none).

I've never really given this much thought, but html could reallly become the standard file format for documents.

> The key difference between print systems and web tech is responsiveness.

True, but... we were very good at building unresponsive websites in the early 2000s. Can't we just return to tradition and disable a lot of the responsive behaviour that we've layered onto HTML with an off-the-shelf stylesheet? Hardcode some width properties, ya know? (This is not a rhetorical question, genuinely curious).

You can trivially define a CSS stylesheet that eg. hides all the interactive elements like INPUTs and FORMs, or renders <A> tags like plain text.

But "H" in "HTML" is for "Hyper(text)", which really talks about the interactivity. And then you get a really bad language for typesetting that simply lacks a gazillion features of true typesetting systems like TeX or even Typst.

Then you might as well just use PDF.js and render the PDF in its entirety.

Regarding LaTeX to HTML, I have had some success with pandoc, e.g. https://ykonstant1.github.io/power-draft.html

It is much trickier if you are using tikz heavily, but it still doable.

Publishing is heavily dependent on the output media, and multi-format output is still hard for anyone desiring a high quality output.

HTML is specifically designed as a publishing system for our screens and has mostly evolved that way (media CSS tags excluded) and as a web application UI language, along with some push into semantic markup (but TEI or DocBook are much more comprehensive when it comes to semantic markup).

Some of the large problems of typesetting printed documents (page layout, with hyphenation, figure placement, orphans, justification...) are simply unsolved (or badly solved) with HTML+CSS, and they are hard problems even if you focus only on them (TeX systems will sometimes ask you to manually "pick" your poison — if you've ever seen those black bars in the margins).

Some of the beauty of TeX box model could have been transferred to screens though (like tunable and collapsible whitespace), and to an extent they have, but TeX's model remains incompatible with the HTML/CSS box model.

The fact that no language does all 3 (UI for apps, screen rendering of documents, paper rendering of documents) perfectly or even acceptably well — not to mention a fourth class that's a mix between screen and paper: ePub/eBooks — should tell anyone that this is a very hard problem to solve generically.