There are many reasons this comparison is not made. I will just touch on one. The target medium is different. For html, you have monitors of different sizes as well as windows that can be resized. For latex, you choose your target at the start: A4 paper? Screen presentation? A0 poster?
With a fixed medium in mind, you can be extremely particular on where on this canvas you want a piece of text/graphic or whatever.
Without a fixed medium, you have to have logic to address the different mediums and compromises have to be made.
That seems contradictory, when Latex is rather famously imprecise at placing figures and such. Weren't both languages (at least at some point) intended to take layouting control away from the writer?
But regardless, I think that, in addition to moving away from Latex we should also reconsider the primary output format. Documents are rarely printed anymore, and inaccessible, fixed-size A4 pdfs are annoying to read on anything but an iPad Pro.
LaTeX isn't intended to take layout control away from the author so much as it is intended to automatically produce a good-enough layout allowing a single author to produce a very large document without employing a designer.
HTML by contrast explicitly does remove control over layout from the author and place it in the hands of the user (and their chosen user agent).
Both languages have mechanisms to (somewhat) separate the content from the formatting rules.
LaTeX would rather produce a bad document if it cannot produce a good one. Example: overfull hbox.
A designer is still required who creates the documentclass, it is just that LaTeX comes with some predefined ones intended for scientific publishing.
HTML+CSS require pixel-perfect rendering. Example: ACID2 test.
While it might have been the idea of plain HTML at some point (<em> instead of <i>), control has never been taken away from the author thanks to CSS.
You're badly mischaracterizing tests like ACID2. The test definition includes a long list of things that invalidate the test, including things like changing the zoom level. So it's wrong to construe that test as requiring pixel-perfect rendering when it explicitly doesn't cover exactly the kind of user agent controls I'm talking about.
Your comments about LaTeX do not seem to contradict anything I said.
HTML+CSS has facilities to target a page format (CSS @page rule, cm and in dimension units). Not to say that it's on the same level as LaTeX, but it's pretty impressive by its own right.
Are there good deep dives on how far you can practically this? Especially in combination with headless browser pdf generation?
Last time I looked into it, a while ago, my impression was that it would get rickety too soon. It’d be a good place to be, I think, if web and “document” tech stacks could have nice and practical convergence.
We use CSS paged media to create e-books and invoices (using weasyprint [0]). One of the most helpful resources for me was print-css.rocks [1], they cover a lot of what’s possible and include which tools support which parts of it (tools targeting paged media, browser support is essentially non-existent and outside using JS to fake it with paged.js, not relevant). The expensive tools tend to support more features, but thanks to some donations/sponsorships, weasyprint has really caught up and now supports a very large part of the spec.
> Especially in combination with headless browser pdf generation
I have no idea why you’d want to do that. Browsers are bad at it, dedicated tools are great at it.
I'd say it's already there. See for example the https://pagedjs.org/ project which allows advanced typesetting (including for printing) using web technologies. It is already used in production by at least one book publisher (C&F editions)
I've used it for my own such production, perfect binding with a hand guillotine and screw clamps in my attic - nothing remotely professional, but you still have to start by making a
book block, and Paged.js is a solid call there. Unless beauty of typography (more than TTF/OTF hinting can handle) is of particular merit, it's usually my preferred first typesetting option.
As an old hand with PDF-in-browser production, I expected much worse of Paged.js than I found. It's powerful and mostly enjoyable to use! Oh, you end up with a large set of CSS rules, and it is not without bugs and gotchas (failing to specify a bleed rule somewhere at least once in every @page context subtly breaks layout; footnote layout is functional but automatic call numbering isn't always perfect, etc.)
You should definitely not expect to take Paged.js out of the box, slap a theme on it, and go; it comes as a box of parts with a mostly complete machine inside, and if it breaks you get to keep all the pieces. I imagine the publisher who uses it must have some prior interest in web technologies, for example.
Nor is Paged.js remotely as
capable or flexible as InDesign or a comparable tool, especially for the deeply rudimentary condition of web typography overall - something even as elaborate a tool as this can't really approach fixing.
But Paged.js is also unlike InDesign in having a much shallower (days vs months) learning curve for folks like us with prior web experience, and however equivocal a review I may now be giving of its technical merits, I do actually like working with Paged.js quite a lot.
I've also used pagedjs for a relatively complex booklet with bidirectional text in different languages, images and long footnotes. The result was great but there were some annoying bugs, some of them seeming to be possible underlying bugs in chrome and Firefox. Still, latex would have been even more frustrating.
Coincidentally, I've also used pagedjs for a project recently (125K novel) and encountered some bugs/minor issues. Overall though, I would say I had an immensely positive experience (because even when stuff broke, it was still just HTML, CSS, and JS--so I, like any other web developer, could fix it).
That said, it's a shame that the relevant W3C specs (see https://pagedjs.org/about/) still aren't fully supported by browsers (but perhaps such is the fate of niche features), but with that being the case, I'm infinitely thankful that pagedjs exists as a polyfill.
Oh, I certainly don't doubt that. And as I said, I haven't really found Paged.js all that frustrating! I have extensive though not recent Pagemaker experience; I expected InDesign to be easier, and now I rue the day when that's where I'm forced to resort.
In my experience Paged.js is at its best when building to PDF, but then that's always my intermediate format when working to paper, because that's where PDF's inflexibility shines. The source of a book block, everything that builds to that PDF, partakes of all the infelicities of the JS ecosystem. But to remake the book itself again, all I need do to start is print the PDF.
I pay for a tool to convert HTML/CSS into PDFs https://www.princexml.com/ and it seems to work well. I don't have the best idea of how it compares to the various free options though.
Yes, sometimes, but I would say that one of the benefits of latex is how easy you can switch to another layout. But I guess the point is that you typically render to a set of outputs with fixed dimensions (pdf)
TeX worked (and works) in batch mode on ancient hardware. Today's computers are so much faster, that this should actually be fast enough to run interactively without having to change or optimise too much.
With a fixed medium in mind, you can be extremely particular on where on this canvas you want a piece of text/graphic or whatever.
Without a fixed medium, you have to have logic to address the different mediums and compromises have to be made.