Switch_off Switch_on Switch_off
Inventive Labs: Web Problem Solvers

Zhook, a really simple ebook format [19072010]

Perhaps it’s just a thought experiment. Perhaps it has a place, like YAML has a place beside XML. It’s not intended a slur against EPUB, or a vainglorious attempt to supplant it. But the more I think about books, the more I believe that the content of them is not special, and is wholly within the capabilities of the HTML and CSS specifications. All we really need is a transmissable package (zip is fine), and a bunch of reasonable mark-up conventions.

That’s what Zhook is.

ochook Read the official specification of Zhook on Ochook.org.

The book-reading platform that we’re building around Monocle will accept Zhook uploads as well as EPUB uploads. We’ll be providing the required documentation for our Zhook support closer to launch.

Vitorio [Mon 19 Jul 2010, 3:28PM] said:

All of this is off the cuff, but I read Zhook as the Mencken quote of book formats: neat, plausible and wrong.

It’s a throwback to the early 90’s web, “this page best viewed in X.” New browsers — I mean, reading systems — may or may not work at all. Publishers won’t continually offer new stylesheets to upgrade your book in perpetuity. Instead of browser-specific markup and CSS making some crank’s free home page inaccessible, RS-specific CSS will make inaccessible an actual work of literature for which I paid too much, and I’m going to be upset with the author (rather the publisher or device maker) if I can’t read it. You can’t trust the device: RSes will lie about the features they support, whether out of malice or ignorance, just like Safari on iPhone says it supports things like text in canvas, but it actually doesn’t, and just like other phone browsers say they support images and other content types they don’t.

From a structural and semantic perspective, Zhook can’t say “any HTML from 4 on” but then discuss HTML5 semantics. If you want the semantics, you really want to require validating, structurally-correct HTML5. Otherwise you can’t use existing tools to generate Zhook content well.

In addition, rather than define devices as body IDs, you probably actually want to require CSS3 media query support. Media queries let you define stylesheets based on the capabilities of the device, such as resolution, color/monochrome and bit depths, as well vendor-specific extensions for things like touch. You’d define additional sets of vendor-specific media queries to handle the layout changes, and provide a way to query those from JS for interactivity to support graceful degradation.

However, it ultimately sounds like, instead, two things are needed.

First, a “retro-spec,” like HTML 2 was and much of what HTML5 is, documenting the current, actual, tested rendering of EPUB across devices in active use and providing two sets of recommendations: one for EPUB editors to ensure the content they are responsible for can be rendered at some known level of fidelity across existing devices, and one for device creators to ensure they don’t make things worse. This spec could define the existing XHTML 1.1 format in terms of XHTML5 to help with forward compatibility. XHTML5 will allow you to support “old” EPUBs (because the parsing model is consistent) while paving the way for future ones.

Second, a new specification of EPUB (“Zhook”) as a mandatory (“must”) subset of HTML5, with recommended (“should”) microformat and distributed extensions to define things like magic footnotes or addresses or what-have-you. Optional (“may”) HTML5 features are everything in HTML5 that isn’t mandatory in the Zhook spec, and are handled with feature detection. Zhooks are distributed as HTML5 offline applications. (You can transfer the Zhook around in a zip file if you like, but it should actually live on the device as files with a manifest in a directory to allow for updates if the RS supports a network connection.)

Feature detection — not provided by the reading system, but done by the content, just like on the web — would turn on and off additional “magic” content like interactivity or dancing Alice-in-Wonderland character artwork. Because you can’t trust the reading system, and because it is an HTML5 offline application, standard feature detection for content is provided at a known URL by the Zhook standards body to ensure that new, lying RSes are handled appropriately and they don’t break existing content. If a RS supports a network connection, feature detection can be upgraded whenever the book is installed.

By using HTML5, browsers become EPUB readers (even moreso than with all the Webkit adoption) and the Zhook body can provide multiple iBook- and Monocle-style renderers as well as style sheets like Arc90’s Readbility that stress different areas of the spec, all while ensuring the most basic of readers such as Lynx and old Palm Pilots and first-gen Kindles continue to be useful.

CSS3 media queries can be adopted if non-reflowable layouts are desired, but they should be mandatory, and all RSes should be required to offer the user the ability to not use the publisher-provided fancy layout and instead use the reflowable layout.

Joseph [Mon 19 Jul 2010, 5:45PM] said:

If you go complicating things like that, Vito, you’ll never ship.

  • By providing base CSS rules, and then custom rules for specific renderers, you have progressive enhancement, which is the cornerstone of all effective modern web design (and why text-shadow is f'n everywhere). “Inaccessible” is plain wrong.

  • You missed the bit in the HTML5 link where it shows you how to extract a structure from a HTML4 document. It’s right at the start.

  • I’m not going to require validation.

  • CSS already supports media queries. So if the RS does as a result, that’s great. Progressive enhancement. It’s how we get innovation. “Require” is how we get stagnation. Let the designers innovate.

  • EPUB is your retro-spec. I’d recommend you read the three documents that make up that spec, except I don’t.

  • Browsers don’t mandate HTML5, but they support it. I don’t see why Zhook should arbitrarily differ.

  • Yep, zip is the intermediate package. I don’t care what the RS does with it (of course I do: but that’s Monocle, not Zhook).

  • Zhook standards body? You’re not shipping, Vito.

  • The RS can be HTML5 (and gain offline/geo/roto/whatever) whilst rendering content of any HTML flavour: that’s what iframes do. And indeed what Monocle does. But I’m not architecting other people’s reading systems here.

  • Non-reflowable layouts? Ask me again when Blio ships. (Tee hee.)

Vitorio [Mon 19 Jul 2010, 6:51PM] said:

That’s funny, I thought by simply declaring a subset of HTML5 I’d be more likely to ship than if I were to write something new.

As written, the Zhook spec doesn’t recommend “base CSS plus custom rules for specific renderers.” It barely recommends supporting CSS at all. Progressive enhancement is what you get when an editor understands that there are less-capable and more-capable devices and she wants a layout to be legible on all of them, regardless of capability, even though it’s not the way she wished the world worked. When the Zhook spec declares up-front that everyone needs to tell the content what they support, you’re turning it into a free-for-all with a real risk of having no commonalities, like the non-iPhone mobile phone market.

Progressive enhancement only works on the web because everyone renders everything quite close enough. Zhook gives RS developers the liberty to construct a completely different display and input system, and if you look at how many Android apps simply don’t work outside of a Nexus One, you’ll see why that’s a bad thing. There needs to be a line in the sand, some common ground.

Inferring a structure is not the same thing as declaring a structure. If the reason ebooks still cost as much as paperback because the editors still cost the same, then they better be declaring a structure for the ebook and not letting the software infer it, or else what am I paying for?

EPUB isn’t a retro-spec. EPUB is a wish. How the various EPUB-supporting devices support EPUB (all slightly differently) is the standard, which isn’t compared or documented. What are the best practices across each device? Zhook expects you to know these things, but they’re not outlined anywhere. Doesn’t that have to come before Zhook?

Browsers don’t mandate HTML5, but best practices dictate you use it in your processes and that your tools generate it. At some point, more pages will be HTML5 than not. By declaring yourself HTML5, you get the documented parsing method and structural system that makes it possible to not be a web browser and still be able to sensibly organize and render the content. And because it’s HTML5, if you want to let content designers be lax, the documented parsing method will be able to support them, too.

Maybe the Zhook standards body is you in a bar with a URL, but any editor still wants to know that URL will be valid in eighteen months, and any reader wants to know that URL will be valid in five years when they go to re-read that book again on a new device.

And you’re right, my resume doesn’t validate, although my personal site does. Hiring a designer to lay out the resume was the fastest way to ship it.

Joseph [Mon 19 Jul 2010, 7:00PM] said:

‘As written, the Zhook spec doesn’t recommend “base CSS plus custom rules for specific renderers.”’ Indeed. And there’s also no specification for sucking eggs, either.

‘Inferring a structure is not the same thing as declaring a structure.’ Good mark-up doesn’t imply a structure. It declares one.

‘Hiring a designer to lay out the resume was the fastest way to ship it.’ And that is my point. It’s perfectly well-designed.

LinC [Sun 26 Sep 2010, 1:16AM] said:

The whole content must be in index.html! After 5 years I just finished transcribing an old book (written in 1722, about 1200 pages 10"x14"). The whole lot has the original contents, indexes, and errata tables, all hyperlinked. As one file this would be cumbersome to manage. Even working alone (a retirement project) I managed to stage and parallel the work, having one computer running OCR on a batch of images, while another ran Applescripts to clean up the OCR output of a previous batch. All restartable if anything went wrong, which it did, with storms and power fails, every now and then. Along with illustrations, illuminations, and original page images, it’s about a gigabyte. And it’s only in monochrome. Forget about short stories and crime novels, start thinking about real books.

Joseph [Sun 26 Sep 2010, 5:55AM] said:

Actually, short stories and novels are real books. What you have, if you have a 1gb ebook, is an outlier, for which there are better options than Zhook, but none that will serve you particularly well. Still, try EPUB. Good luck!

Sorry, comments are not available on this post.