I would say similarly to hyphenation is TeX's ability to place page breaks optimally. I don't believe any web technology can solve this problem at the moment.
Just printing the <p> tag, with its constraints of text layout on all layers (word, line, paragraph, page) already has a lot of details you need to get right to get naturally readable text flow before adding on all the other complexities of html. For instance, if you have a single line creep onto the next page, but you could also just move the entire paragraph to the next page and subtly adjust spacing on the first page, then that is preferable so that each paragraph resides entirely on one page. This is obviously not always possible or desirable, so it turns into a search problem with many variables that can be dynamically altered in the middle of text flowing.
My understanding of modern CSS engines is both that a) CSS itself lacks the natural primitives to even express constraints you'd find in TeX, and also b) the concerns necessary to solve page layout to this degree fall into the type of search problem that browsers tend to try to avoid when rendering.
Of course, there's an argument to be made that if people don't realize it's missing, maybe it wasn't terribly valuable to begin with. I'd imagine for most home uses it's not very useful, but the fact that you can typeset decades old documents at a de-facto professional level, for free, OR with heavily modified engines allowing more modern practices, is really quite amazing. I hope the effort that went into formalizing "readable text" doesn't get lost as people move on from TeX--it'd be great to get some of this capacity in a browser with competing implementations; TeX is a lot to learn for most people, and it's also turing complete, which is IMHO mostly a bad sign for accessibility.
There are also projects which attempt to render HTML to TeX, but they were frankly mostly terrible the last time I looked. I honestly wonder if it's easier these days for javascript to attempt to render the DOM to TeX and just leverage the browser as much as possible, but I'm not familiar enough with the DOM to speculate on how much this is likely to work on unaltered pages. My guess is you only get so much for free before you have to specifically consider that output scenario, just like other types of responsive layout.
I would say similarly to hyphenation is TeX's ability to place page breaks optimally. I don't believe any web technology can solve this problem at the moment.
I wonder how hard it would be to just compile TeX to WebASM or something.... TeX is _ridiculously_ fast on a modern PC, hundreds of pages per second. All the libraries/macros might be problem, but I bet you could prepare a useful-but-minimal set that would fit in a MB or two gzipped.
I've always been bemused by the major focus that we need a brand new implementation of the algorithms so that they can take advantage of modern computers. Ignoring just how bloody well it already takes advantage of faster processing power.
(I get that there are some good arguments for a more developer friendly extension language.)
I think Latexbase does something like this (they claim it works offline too, using service workers). They claim to be using Emscripten/LLVM but it doesn't seem like they use wasm yet (probably because they didn't consider it a viable option back in 2016 https://latexbase.com/p/b0a174a5-09b3-4598-9686-3a73be2dc8e5). And while it's not open source I still think it's a really cool proof of concept..
Comments
I would say similarly to hyphenation is TeX's ability to place page breaks optimally. I don't believe any web technology can solve this problem at the moment.
Just printing the <p> tag, with its constraints of text layout on all layers (word, line, paragraph, page) already has a lot of details you need to get right to get naturally readable text flow before adding on all the other complexities of html. For instance, if you have a single line creep onto the next page, but you could also just move the entire paragraph to the next page and subtly adjust spacing on the first page, then that is preferable so that each paragraph resides entirely on one page. This is obviously not always possible or desirable, so it turns into a search problem with many variables that can be dynamically altered in the middle of text flowing.
My understanding of modern CSS engines is both that a) CSS itself lacks the natural primitives to even express constraints you'd find in TeX, and also b) the concerns necessary to solve page layout to this degree fall into the type of search problem that browsers tend to try to avoid when rendering.
Of course, there's an argument to be made that if people don't realize it's missing, maybe it wasn't terribly valuable to begin with. I'd imagine for most home uses it's not very useful, but the fact that you can typeset decades old documents at a de-facto professional level, for free, OR with heavily modified engines allowing more modern practices, is really quite amazing. I hope the effort that went into formalizing "readable text" doesn't get lost as people move on from TeX--it'd be great to get some of this capacity in a browser with competing implementations; TeX is a lot to learn for most people, and it's also turing complete, which is IMHO mostly a bad sign for accessibility.
There are also projects which attempt to render HTML to TeX, but they were frankly mostly terrible the last time I looked. I honestly wonder if it's easier these days for javascript to attempt to render the DOM to TeX and just leverage the browser as much as possible, but I'm not familiar enough with the DOM to speculate on how much this is likely to work on unaltered pages. My guess is you only get so much for free before you have to specifically consider that output scenario, just like other types of responsive layout.
I wonder how hard it would be to just compile TeX to WebASM or something.... TeX is _ridiculously_ fast on a modern PC, hundreds of pages per second. All the libraries/macros might be problem, but I bet you could prepare a useful-but-minimal set that would fit in a MB or two gzipped.
I've always been bemused by the major focus that we need a brand new implementation of the algorithms so that they can take advantage of modern computers. Ignoring just how bloody well it already takes advantage of faster processing power.
(I get that there are some good arguments for a more developer friendly extension language.)
I think Latexbase does something like this (they claim it works offline too, using service workers). They claim to be using Emscripten/LLVM but it doesn't seem like they use wasm yet (probably because they didn't consider it a viable option back in 2016 https://latexbase.com/p/b0a174a5-09b3-4598-9686-3a73be2dc8e5). And while it's not open source I still think it's a really cool proof of concept..