4 ms·

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) t

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

contact9879 2y ago
this also somewhat surprised me at first but I think it's obvious in hindsight, though they don't have to be a full-blown web browser (you can go read the epub specs at W3C to see what's supported) 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
- pmarreck 2y ago
  I guess I assumed that, for example, multi device support on websites for various device widths entails a bunch of CSS, which means the epub renderer would have to also do that, which basically means a whole web browser. 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
  - contact9879 2y ago
    since ebooks are primarily (only?) text you don't have to worry about UI elements and such which simplifies a lot of the css 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
badsectoracula 2y ago
Yeah (i guess you mean epub), though in practice readers support only a tiny subset and epubs avoid using anything fancier than basic XHTML. Epubs that try to use fancy stuff (like most CSS outside of setting fonts - that readers can ignore either because they do not support it, or because the user wants to use another font) tend to not display correctly.
acabal 2y ago
It makes a lot of sense when you recall that HTML and its ancestors were designed to mark up and format documents, i.e. books. One of the most fundamental elements is <p>, which stands for... paragraph. 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.
hombre_fatal 2y ago
Including a web browser seems a lot easier and simpler than coming up with your own rendering system once you want to support a feature set past the trivial. 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.
- berkes 2y ago
  > Also, xhtml is just markup. 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.
carlosjobim 2y ago
The greatest surprise is that no popular web browser opens ePubs natively! This in 2025, where they all display PDFs, high resolution video, 3D games, etc.
- robin_reala 2y ago
  Edge used to, until MS rebuilt it on top of Chromium. Shame.
  - mjmas 2y ago
    Yes, and that was a great viewer too. Having the whole book laid out horizontally rather than vertically was a good idea.
- cxr 2y ago
  A bigger surprise (failure) is that the EPUB folks have continued to evolve their bespoke format instead of ditching it for something that legacy browsers already know how to handle. An "EPUB" should just be a Mac-style bundle (i.e. a directory) with an XHTML file in it written to conform to a specific metadata profile.
  - duskwuff 2y ago
    EPUB isn't all that different from what you're describing. It's bundled as a ZIP archive with a couple of XML metadata files - and the content is split into one HTML file per chapter or section to make it easier to handle - but the idea is the same.
    - robin_reala 2y ago
      There’s also an epub-namespaced set of attributes which extend XHTML with ebook specific semantics. But those typically aren’t necessary for the visual representation of books.
    - cxr 2y ago
      Hey, ChatGPT, tell me what's wrong with this person's comment. > [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.

contact9879 2y ago

this also somewhat surprised me at first but I think it's obvious in hindsight, though they don't have to be a full-blown web browser (you can go read the epub specs at W3C to see what's supported) 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

pmarreck 2y ago
I guess I assumed that, for example, multi device support on websites for various device widths entails a bunch of CSS, which means the epub renderer would have to also do that, which basically means a whole web browser. 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
- contact9879 2y ago
  since ebooks are primarily (only?) text you don't have to worry about UI elements and such which simplifies a lot of the css 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

badsectoracula 2y ago

Yeah (i guess you mean epub), though in practice readers support only a tiny subset and epubs avoid using anything fancier than basic XHTML. Epubs that try to use fancy stuff (like most CSS outside of setting fonts - that readers can ignore either because they do not support it, or because the user wants to use another font) tend to not display correctly.

acabal 2y ago

It makes a lot of sense when you recall that HTML and its ancestors were designed to mark up and format documents, i.e. books. One of the most fundamental elements is <p>, which stands for... paragraph. 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.

hombre_fatal 2y ago

Including a web browser seems a lot easier and simpler than coming up with your own rendering system once you want to support a feature set past the trivial. 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.

berkes 2y ago
> Also, xhtml is just markup. 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.

carlosjobim 2y ago

The greatest surprise is that no popular web browser opens ePubs natively! This in 2025, where they all display PDFs, high resolution video, 3D games, etc.

robin_reala 2y ago
Edge used to, until MS rebuilt it on top of Chromium. Shame.
- mjmas 2y ago
  Yes, and that was a great viewer too. Having the whole book laid out horizontally rather than vertically was a good idea.
cxr 2y ago
A bigger surprise (failure) is that the EPUB folks have continued to evolve their bespoke format instead of ditching it for something that legacy browsers already know how to handle. An "EPUB" should just be a Mac-style bundle (i.e. a directory) with an XHTML file in it written to conform to a specific metadata profile.
- duskwuff 2y ago
  EPUB isn't all that different from what you're describing. It's bundled as a ZIP archive with a couple of XML metadata files - and the content is split into one HTML file per chapter or section to make it easier to handle - but the idea is the same.
  - robin_reala 2y ago
    There’s also an epub-namespaced set of attributes which extend XHTML with ebook specific semantics. But those typically aren’t necessary for the visual representation of books.
  - cxr 2y ago
    Hey, ChatGPT, tell me what's wrong with this person's comment. > [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.