Allowing HTML in EPUBS

[pdurrant]

Originally Posted by KevinH

All that you are going to achieve by adding html as a allowed core media type is to further fragment the epub publishing marketplace for no real gain. Just increased costs, along with yet again delaying the industry adoption.

Hear, hear!

[Quoth]

Originally Posted by KevinH

I really wish this talk about the xml serialization of html going away would stop. It is pure nonsense spread to create doubt. True FUD.

...

Please stop spreading misinformation.

And as for archival formats (and epubs need to be able to meet those archival standards), true xml is the dominant text storage technology, and in use by most wordprocessors and office suites.

And as for increasing epub adoption, right now you can take html code and put in in Calibre or Sigil and it will nicely be "fixed" to meet the xml serialization rules needed for epub. So using html for authoring works already exists. We (Sigil) already encourage users to use Word, OpenOffice, LibreOffice (ie. real writing tools) to create the source matter and then they can use Sigil or Calibre to make it meet the epub standards.

All that you are going to achieve by adding html as a allowed core media type is to further fragment the epub publishing marketplace for no real gain. Just increased costs, along with yet again delaying the industry adoption.

Yes. All true. Bold added.

[slm]

Originally Posted by KevinH

And as for increasing epub adoption, right now you can take html code and put in in Calibre or Sigil and it will nicely be "fixed" to meet the xml serialization rules needed for epub. So using html for authoring works already exists. We (Sigil) already encourage users to use Word, OpenOffice, LibreOffice (ie. real writing tools) to create the source matter and then they can use Sigil or Calibre to make it meet the epub standards.

The question becomes why shouldn't html be allowed in the epub spec if the code to "fix" it to XML is straight-forward: the code could just as easily be in the book-reader software as in the book-creation software.

[Turtle91]

The code to "fix it" is making educated guesses that aren’t always correct. XML doesn’t require (allow) guesses.

[KevinH]

Did you actually read the part about fragmenting the marketplace? Allowing html as a core media type, means that your html using epub will no longer work with the installed user base of epub3 e-readers, and furthermore any epub3 that used html can not be made to be backwards compatible with epub2 anymore. Given how slow adoption of epub3 has been, the standard marketplace would then have to split epubs into those with html and those that cannot for no added benefit.

Also xml parsers form the backbone of the epub publishing toolchain. Forcing epub producers to completely retool if html is allowed, as it would break tools that depend on open and close tag pairs, would break many regular expressions, etc.

So the result is added costs, delayed uptake, multiple versions of epub2, epub3 e-readers made obsolete, more user confusion.

The only advantage claimed for html is that it is easier to write by hand but few do that, and since you can import html into Sigil and Calibre to get it serialized as xhtml, what is the point? Why break everything and end up with no benefit?

Who is going to pay for all the extra software development costs to move from xml parsed toolchains to full html parsers? Who is going to reimburse all the users of e-readers that are now obsolete? Who is going pay to rewrite their e-reader software and firmware update costs for those that can still be updated? And all for what ... to add a new buzzword to their marketing?

Keeping the epub spec as xhtml is the only sane path forward.

[seed_html]

I wrote up some of my thoughts against adding html to the EPUB spec here;

https://blog.stewarthaines.com/2025/...-thoughts.html

Essentially, I think most writers want to write in something even simpler than HTML, like we all do on the web. There's no reason writing for EPUB distribution can't be as simple as writing for wordpress, or whatever this forum software is.

[Quoth]

Originally Posted by KevinH

Did you actually read the part about fragmenting the marketplace?

…

Keeping the epub spec as xhtml is the only sane path forward.

Agree totally.

[DiapDealer]

Writers already have many methods available to them to write in something simpler than HTML: simply choose one of the many word processing programs available to them. There are many ways to quickly get Word and LibreOffice documents into EPUB producing software cleanly. If they need something simpler than that to create their content, they're already in way over their heads. And no amount of dumbing down of the EPUB specification is going to help with that.

Nobody needs to (or should) be authoring their content in any kind of markup language.

There is no upside to allowing html as a core media type in EPUB3 (sorry -- making it slightly easier to do something nobody's ever going to be doing is not a real upside). It's all downside in the form of breakage, fragmentation, and confusion. It's breaking things just to break them. All in the name of some irrelevant (not to mention unlikely) deprecation that the people proposing this change don't really seem to grasp the implications (or non-) of.

[sueneu]

Thanks for all the replies. I’ll take this information to the maintenance group, and post our anonymized findings on MobileReads

[DNSB]

Originally Posted by seed_html

I wrote up some of my thoughts against adding html to the EPUB spec here;

https://blog.stewarthaines.com/2025/...-thoughts.html

Essentially, I think most writers want to write in something even simpler than HTML, like we all do on the web. There's no reason writing for EPUB distribution can't be as simple as writing for wordpress, or whatever this forum software is.

For what it may be worth, I do some work for local authors. I take their word processor output, convert it to ePub with formatting for headers, text messages, etc., do some basic checking for spelling and grammar errors. I finally check the ePub and KFX/azw3 output on several apps and devices. To them, their word processor (Word, LO Writer, etc.) is their writing tool.

While most of them have learned (or being honest, been forced to learn ) to use styles with their word processor which makes the conversion a lot simpler, only one of them has shown any interest in the nitty-gritty of ePub internals.

[Quoth]

Originally Posted by DiapDealer

Writers already have many methods available to them to write in something simpler than HTML: simply choose one of the many word processing programs available to them. There are many ways to quickly get Word and LibreOffice documents into EPUB producing software cleanly. If they need something simpler than that to create their content, they're already in way over their heads. And no amount of dumbing down of the EPUB specification is going to help with that.

Nobody needs to (or should) be authoring their content in any kind of markup language.

There is no upside to allowing html as a core media type in EPUB3 (sorry -- making it slightly easier to do something nobody's ever going to be doing is not a real upside). It's all downside in the form of breakage, fragmentation, and confusion. It's breaking things just to break them. All in the name of some irrelevant (not to mention unlikely) deprecation that the people proposing this change don't really seem to grasp the implications (or non-) of.

Agree totally & absolutely 100% with all you write on that post. I couldn't put it as clearly.

[Quoth]

Originally Posted by seed_html

Essentially, I think most writers want to write in something even simpler than HTML, like we all do on the web. There's no reason writing for EPUB distribution can't be as simple as writing for wordpress, or whatever this forum software is.

LO Writer or MS Word, especially with styles is simple. Only plain text is simpler and all the fragments of that can be trivially put into MS Word or LO Writer, and styled.

Then it's trivial to have an epub using Calibre, Sigil or other free tools.

The sort of interface this forum or Wordpress uses is inferior and harder as it's direct formatting rather than a template with styles that only needs set up once.

The two hard bits for self publishing are:
1) Writing decent content (you know the plot, characters, dialogue, narration, actions, places etc).

2) Marketing. Really, really hard.

An agent/trad-publisher is usually wanting an MS-Word doc, (which can be from LO Writer), though getting them to take an interest is very difficult.

Actually making an epub from a docx, then SP on Amazon, Draft2Digital (who now distribute to Amazon as well as Apple, Smashwords, Kobo, Barnes & Noble etc) and Google Playbooks (once you've done it once) is the easiest bit. Especially if proper styles & headings are used.

Edit:
Proofing / edit even after a 1st draft liked by Alpha Reader is far more difficult than making an epub. Many Writers doing SP need to hire someone to do that as it's a different skill & experience to writing.

[Sarmat89]

Originally Posted by KevinH

Allowing html as a core media type, means that your html using epub will no longer work with the installed user base of epub3 e-readers, and furthermore any epub3 that used html can not be made to be backwards compatible with epub2 anymore.

Any serious reader is built around an HTML control, which can handle HTML. So the real HTML support can be implemented with trivial changes.

[DNSB]

Originally Posted by Sarmat89

Any serious reader is built around an HTML control, which can handle HTML. So the real HTML support can be implemented with trivial changes.

Can I get a kilogram of what you've been smoking for my next party? It sounds like some righteous shit.

As for multi-line chapter headers? In ePub2, they were pretty trivial. In ePub3, they are even easier.

[KevinH]

Originally Posted by Sarmat89

Any serious reader is built around an HTML control, which can handle HTML. So the real HTML support can be implemented with trivial changes.

And then you add in the costs of rewriting the publishing industry's epub toolchain software. And then the you add in the costs of rolling out firmware updates to your epub3 e-readers already in place. And of course that breaks any that are no longer providing firmware updates. Any you keep ignoring the costs associated with breaking backwards compatibly with epub2 only e-readers which are still a big part of the market, especially in Europe, and all of that for what benefit?

You really do not understand epub publishing processes at all.