ePub already supports XHTML and CSS. Extending it to support HTML5 is trivial if the renderer is using Webkit...which many eReaders do. And lets not forget the importance of content and form. Having a document that looks like a newspaper out of Harry Potter doesn't improve the quality of the message. They're different mediums and the message doesn't always improve with more distractions.
While I understand all the initiatives to simplify ebook publishing, there will never be anything easier than just use HTML5 with all resources included in one single file. No need to zip/unzip. And if there is any shortcoming in that approach, just ask the W3C/WHATWG to include any extra feature to satisfy that need.
I need a book that can store an unlimited quantity of marginal notes, can play embedded video and audio, shows dynamically updated graphs of everything in the universe, a video chat room, a whale and a vase of petunias.
I think that's all in HTML5 already, except for the petunias. Who do I e-mail at WHATWG for that?
And when is my Kindle going to run HTML5 chatroulette anyway?
But basically, ePub is full of bugs (that take ages to be solved until the huge committee agrees on every point), it is complex to build and debug, and does not support HTML5. Heck, there is not even a way to define a cover.
Just to be clear, HTML5 is composed of many parts. You might be thinking about canvas or video/audio, but one of the most important introductions are the new tags, that turn out to be perfect for crafting electronic publications (semantic richness). That you can use it in ePub doesn't mean you're meant to.
The point here is that HTML5 is a semantically richer format to create books. ePub uses too many configuration files that become a barrier when it comes to authoring.
If we had a decent standard, these e-reading startups probably wouldn't be creating their own.
I don't get it. He starts bashing ePub and then states that HTML5 is the solution. Does he not realize that ePub is just normal XHTML, which can use HTML5 features in supporting rendering engines? ePub is a perfectly decent e-book format.
The fact that ePub = (X)HTML is perfect, however the standard doesn't incorporate HTML5 yet. But this is not the problem.
If you look at the ePub specs you'll quickly notice that the standard is way to bloated! You have to specify all kinds of settings/resources/meta-info and crap in 100.000 different files, you have to create you're own book spine, set up structure and whatever not...
HTML5 itself is descriptive enough to specify reading systems with the right information to display it as a book. The zhook guidelines specify - based on the HTML5 Outline Algorithm - how a book should be build up. So zhook is nothing more than a friendly reminder to keep it simple, slim and stick to the web standards. The only thing zhook adds is a specification on how to add a cover image to your book.. because even though the ePub standard is bloated as I don't know what - there is no standard way to add an image as the cover of you're book.
ePub already supports XHTML and CSS. Extending it to support HTML5 is trivial if the renderer is using Webkit...which many eReaders do. And lets not forget the importance of content and form. Having a document that looks like a newspaper out of Harry Potter doesn't improve the quality of the message. They're different mediums and the message doesn't always improve with more distractions.