[HN Gopher] How HTML changes in ePub
       ___________________________________________________________________
        
       How HTML changes in ePub
        
       Author : raybb
       Score  : 48 points
       Date   : 2026-01-02 23:11 UTC (3 days ago)
        
 (HTM) web link (www.htmhell.dev)
 (TXT) w3m dump (www.htmhell.dev)
        
       | RadiozRadioz wrote:
       | > Then there was the problem of fragility: any syntax problems
       | with your XHTML and your users would get a blank screen
       | 
       | I don't call that fragile, I call that well-founded. It has
       | always perturbed me that, when encountering an error, HTML
       | parsers will guess what they think you meant instead of throwing
       | it back. I don't want my parser to do guesswork with potentially
       | undefined behavior. I don't want my mistakes to be obscured so
       | they can later come back to bite me - I want to be called out on
       | issues loud and clear before my users see them.
       | 
       | Perhaps it works under the context of manually-authored markup
       | with minimal effort, so I can see why the choice was made. These
       | days it's yet another reason why the web is a precarious pile of
       | sticks. HTML freely lets you put a broken oddly-shaped stick
       | right in the middle and topple the whole stack.
       | 
       | The people turning the web from a handcrafted document sharing
       | system into the world's premiere application platform should have
       | made XHTML win.
        
         | robin_reala wrote:
         | It's Postel's law at the end of the day: "be conservative in
         | what you do, be liberal in what you accept from others". As a
         | site owner I want my site to fail loudly and quickly before a
         | user sees a problem; as a user I never want to see a problem.
         | 
         | ePub is in a nice place: the number of documents to check for
         | errors is reasonable, and the resulting artefect is designed to
         | be shipped and never (or rarely) amended. That means that we
         | can shift the balance towards strict parsing. But for a web
         | site of thousands (or millions) of documents that are being
         | amended regularly, the balance shifts back to loose parsing as
         | the best way of meeting user needs.
        
           | thisislife2 wrote:
           | Isn't the developer always the first user? With strict
           | parsing, testing a site before launch would show you the
           | problem right there and allow you to fix it to launch a bug
           | free site.
        
             | michaelmrose wrote:
             | What about a 5 year old client hitting a new server or the
             | reverse? Is the only solution just don't do that?
        
           | wat10000 wrote:
           | Postel's Law sounds nice but it can result in major problems.
           | It results in a de facto spec that differs from the written
           | spec, and disagreements about what a piece of data actually
           | means can lead to bugs and even security vulnerabilities.
           | 
           | Having strictly parsed HTML from the start would be fine.
           | You'd check it before you ship it and you'd make sure it's
           | valid.
           | 
           | Requiring it _now_ would be a disaster, of course. There 's
           | so much malformed HTML out there. But making HTML parsers
           | accept garbage at the beginning was the wrong choice.
        
         | taeric wrote:
         | My favorite is how this interacts with the oh so fun mistake
         | many people make of adding a `<div/>` thinking they are doing
         | it right.
        
           | panzi wrote:
           | Especially since it is correct in JSX, adding to the
           | confusion.
        
         | michaelmrose wrote:
         | What about evolving standards in a system that must handle
         | clients or servers which implement anything from tomorrows
         | feature today to 10 years prior. Shouldn't failures be as
         | graceful as possible?
        
       | robin_reala wrote:
       | Author here, happy to answer any questions / clarify anything.
        
         | ivansavz wrote:
         | Thanks for all the explanations. I always thought it was
         | regular HTML, but now I know to watch out for the differences.
         | 
         | Can you say a few more words about the library
         | https://github.com/standardebooks/tools ? Can it generate ePub3
         | from markdown files or do I have to feed it HTML already. Any
         | repo with usage examples of the `--white-label` option would be
         | nice.
        
           | robin_reala wrote:
           | The tooling does two main things: create a valid epub3
           | skeleton for your content, and build your book into
           | "compatible", Kobo and Kindle versions. You need to supply
           | the valid XHTML.
           | 
           | There's more info on the build process at
           | https://news.ycombinator.com/item?id=46469341
        
         | pavon wrote:
         | Are there any sites that provide e-reader engine support charts
         | for ePub, similar to what MDN provides for HTML?
        
       | ahmedfromtunis wrote:
       | Sometimes I wish some kind of weird disaster would strike that
       | somehow only erases the protocols and styling/markup languages
       | invented in the last 60 years -- without losing any data -- to
       | force us to start over, but with the benefit of hindsight.
       | 
       | Oh, and JavaScript.
        
       ___________________________________________________________________
       (page generated 2026-01-06 23:05 UTC)