HTML in EPUB thoughts
I filled out the survey a few weeks ago and I didn't feel like my responses there were particularly pro or con HTML in EPUB. But the idea has been on my mind since then and this thread on mobileread.com clarified a couple of things for me.
My current project takes a particular writers-first perspective I haven't seen shared yet. Some links first to provide some context for how others are interpreting this proposal:
Here's post by Laurent Le Meur on the EDRLab blog in July 2025.
https://www.edrlab.org/2025/07/06/allow-pure-html5-in-epub-3/
"Therefore, allowing pure HTML5 as EPUB content documents should not be considered an evolution targeting senior professionals, but rather a way to open EPUB creation to a new generation of publishers and third-party developers with a Web background."
I'd say "to open EPUB creation" is pointing at something important here.
And (creator of Calibre) Kovid's comment in this thread on mobileread.com:
https://www.mobileread.com/forums/showpost.php?p=4523794&postcount=3
"The *only* advantage I can see for the HTML 5 serialization over the XML serialization is that the former is easier to write by hand."
The idea that writers are going to benefit in this way strikes me as a limitation of the EPUB ecosystem right now.
My thesis
If the motivation for allowing HTML document types in EPUB is to address the hostility of XML to writers, designers and developers, I'd argue that it doesn't go far enough.
No-one wants to write XML by hand. But that's not its primary role in EPUB. XML provides a flexible and well-defined machine-readable basis, and its proper place is in software tooling, not writer-facing authoring tools.
But, and this is my point, most people don't want to write HTML by hand either.
Consider the current landscape of social media, blogs and other hosted writing platforms, which mostly abstract away the markup entirely or provide a workflow for light, plain-text markup (like Markdown) that then gets converted to browser-readable HTML.
To me, the piece that's missing for future wider adoption of the EPUB 3 format isn't the lack of HTML document support, but the availability of tools that give writers a choice about which writer-friendly plain text format to use. Authors writing on the web don't often hand-craft their thoughts in HTML though that's the underlying technology. They choose a platform and a template, and they just start writing for their channel and audience.
Writers and designers aren't excluded from creating EPUB files by the lack of HTML support in the spec. It's the complexity of the format that is surfaced in user-facing applications that ... cools engagement and ambition. It's so much easier to write and publish on the web.
It should be easy to write and publish as EPUB for other distribution channels.
Part of my motivation for developing the browser-based SEED.html app is to lower the barrier to entry for writers who want to create good-looking digital books using the Open Standard EPUB® 3 format, without having to learn anything at all about the Open Standard EPUB® 3 format.
The SEED.html app is a work in progress, but it's already useful for me to iterate on book layouts and behaviors without having to write xml and push to a device for feedback.
To be clearer about this project's goals, here's a non-exhaustive list of what SEED.html is not:
- not a general-purpose EPUB editor (it's idiosyncratic and opinionated, and tricksy)
- not a distraction-free writing tool (it provides just a textarea for content, css, javascript)
- not a replacement for complex publishing workflows with multiple outputs (it only produces EPUB 3)
- does not enforce the application developer's idea of which plain text format a writer will want to use - there are sample projects on the SEED.html web site with markdown, textile, asciidoc, fountain and latex content in various combinations. All produce valid EPUB 3 packages with xhtml chapters
- not well documented
The app provides a low-friction pathway for a non-technical writer to get their words into an EPUB format. It's also a tool with a sliding scale of complexity for designers and developers to iterate on digital book concepts.
No-one using the app has to read or write XML. Ever.
In conclusion
The very desirable goal of reducing the friction of creating EPUBs by making tools more accessible to the people who might create digital books (including writers and designers) aren't significantly advanced by allowing HTML documents in the EPUB 3 spec. It doesn't substantially address that goal, and brings significant risk of platform fragmentation.
Stewart Haines