It surprises me that the eBook (clarification: epub) format is basically XHTML because 1) that means that every eReader needs to basically be a web browser 2) this sounds like it would make reformatting for different devices NOT easier
Each renderer differs in capabilities, and most are stuck in a subset of early-2000s capabilities, so designing an ebook is very much like designing for the 90s era web. Lots of hacks are required to get the same file to look good on many different renderers, and achieving that is one of the goals of Standard Ebooks.
Also, xhtml is just markup. It doesn’t mean you have to support all the possible tags and styles of modern html and css. It would be a sensible choice even if you had basic needs. You just parse it into whatever representation you want.
And so it's not a programming language runtime (i.e. javascript or wasm), nor a css renderer, nor a bunch of web-apis.
It's these things, not the (X)HTML parsing and rendering that makes a browser the complex thing it is.
> [T]he third comment violates the Cooperative Principle, specifically Grice’s Maxims of Relation and Manner, and ends up implying ignorance where there is none. Let’s break it down a bit more with that framework in mind:
> VIOLATION OF GRICE’S MAXIMS
> The second ["EPUB folks have continued to evolve their bespoke format instead of ditching it for something that legacy browsers already know how to handle"] commenter criticizes EPUB for continuing to evolve a packaging format that is not browser-native. They're not confused about what EPUB is—they're lamenting that it isn’t something simpler, like a plain web bundle a browser could just open.
> The third commenter responds by explaining what EPUB is, as if that somehow rebuts the original critique.
> Factually true.
> Entirely irrelevant in context.
> This failure to meet the relevance standard creates an implicature: the previous commenter must not have understood the format they were critiquing.
> THE IMPLICATURE TRAPS THE THIRD COMMENTER
> By stating something the second commenter obviously already knows, the third commenter unintentionally shifts the conversational footing in a way that belittles rather than builds. That’s why the tone feels off: not because of overt rudeness, but because the presupposition of ignorance is baked into the structure of the reply.
> FINAL THOUGHT
> The third comment reads like an attempted “correction,” but since the original comment didn’t contain a factual error, only a value judgment or proposal, this “correction” becomes a non sequitur—one that subtly undermines the prior speaker’s credibility while failing to address their actual point. That’s what makes it rhetorically broken, even if factually fine.
as for (2) I'm not sure why you think it would make it less easier? being html, text reflows automatically based on screen size, font size, line height, etc
also that things like footnotes or anything that has a floating reference (table of contents links for example) might get very complex or require javascript
footnotes aren't really a thing with ebooks (at least as far as displaying the note on the page with the text). Because it is just a html renderer, footnotes are presented as mutual <a> elements located in the endnotes at the end of the book