Baldur Bjarnason

A response, of sorts

– Baldur Bjarnason
I wrote a post on Tools of change a while back on issues that need standardisation.

Because the ToC blog doesn’t do comment notifications I didn’t notice that Bill McCoy had replied to it until today. Since the comment thread on the original post is quite dead, I decided to reply to it here.

(I don’t understand why people keep demanding that blogs implement comment support. They clearly don’t work on most sites that do have them and the responses you get via email or other blogs are always much more substantial than anything you get in a comment thread.)

The quoted sections below are from Bill’s comment. The rest is me.

To a significant extent “existing reading system behavior” represents bugs and/or transitory artifacts, especially as the ecosystem is in mid-stream moving from EPUB 2 to EPUB 3 (a major evolution from 12-year-old XHTML 1.1 and CSS2 to today’s HTML5 and CSS3). IMO there’s no point in standardizing such reading system behavior, particularly for proprietary engines that are in the process of being scrapped in favor of browser-engine-based renderers, almost all via WebKit, that will among other things do CSS much more consistently.

There are a few things wrong with Bill’s statement here.

It’s technically correct that ebooks would be more consistent if they were all implemented on WebKit. But we’d be opening ourselves just to inconsistencies on a different level. It wouldn’t solve nearly as many problems as people think and would cause quite a few new ones.

As a web developer, chasing down Chrome bugs that don’t exist in Safari is a much bigger pain point now than even dealing with IE. (IE’s a known quantity with known issues. Chrome bugs aren’t known and breed like fungus in a frat house fridge.)

The reason for this is simple (people should note this down for posterity):

WebKit isn’t a single rendering engine.

Webkit is two things. First of all it is a library framework for building an HTML/SVG+CSS+JS rendering engine for your platform. Secondly, it is a collection of rendering engines that have been ported to various platforms. The WebKit in QT supports different features from the one built on GTK, which in turn is different from the one that uses the Enlightenment libraries, which is different from Android WebKit, which is different from Chrome Webkit—the list goes on: Blackberry, Mac OS X, iOS, they are all different.

Even Chrome varies from OS to OS. There are differences in behaviour and features between Chrome for Mac, Chrome for Windows, and Chrome for Android.

You can assert a similarity in terms of CSS and JS support between various WebKits with about as much confidence as you can between Safari and Firefox. That’s how different they can be.

Then there’s the difference between V8, which Chrome uses for javascript, and JavaScriptCore, used by Safari and the other WebKits, which is substantial in terms of language features and behaviour. V8 is quite a bit ahead in terms of experimental support for ECMAscript Harmony features (the next iteration of javascript which will be ratified as ES6 some time next year), for example.

And this bears repeating:

I was not talking about bugs. I was talking about deliberately and intentionally implemented overrides.

Sure, bugs are a pain, especially since most vendors never ship bugfix releases to older devices, but inconsistent overrides are a much bigger process issue for ebook developers.

That said since EPUB is by design more flexible in how reading systems are expected to process CSS and overall do pagination and layout. So I do think some additional norms for how the CSS cascade should work in re: reading system / user overrides could be useful. Maybe you could come up with something specific to propose?

I made a specific proposal. It’s in the post. You can only get more detail than that by getting the vendors involved. They’re the ones that are implementing these things and are the only ones who know what’s actually going on. The rest of us are guessing based on what we see in testing.

Here are my suggestions, recapped, for those who ‘read’ my post without actually taking in any of the words:

We need to clarify:

  1. Where the vendor’s override styles enter the cascade.
  2. Where the reader’s settings enter the cascade.
  3. Where the publisher’s styles enter the cascade.
  4. How the cascade is modified when the reader turns the publisher styles on or off. What styles are removed. What styles are inserted. How it’s done.
  5. Exactly what happens when publisher styles are turned on or off.
  6. What features are covered by the override stylesheet.

Get vendors into a room. Get them to clarify the above and agree on a consistent behaviour. Write it up and publish as a recommendation.

Then please consider standardising some sort of metadata opt out so that well-behaving publishers can avoid the overrides, similar to what Apple has done with iBooks.

That is what I suggested in my post. How is this not a specific proposal? How can somebody read the post and not see that as a specific proposal? What more specifics can I, an outsider who isn’t working for a publisher, ereader vendor, or tool-maker, give? Seriously, what?

As far as modularizing EPUB 3 with finer granularity than its current 5 specs (7 if you count alternate stylesheets and fixed-layout metadata): that ship has sailed.

Five documents shipped in lockstep aren’t five specifications. They are one specification delivered in five (or more) documents. For them to be separate specs they would have been delivered, each according to their own timetable, staggered over time as they were ready and, most importantly, as interoperable implementations were released. If EPUB3 were actually modularised, neither media overlays nor canonical fragment identifiers would be specs today. They’d still be drafts waiting for interoperable implementations, but neither would have stopped or even delayed the other parts of EPUB3 from becoming official recommendations. There would, in effect, be no such thing as the EPUB3 standard, just a collection of standards grouped under the EPUB3 umbrella.

And that ship hasn’t sailed unless you expect that no further work will be done on EPUB standards ever again. CSS2 didn’t prevent the CSS WG from modularising CSS3.

And we want to encourage complete, consistent EPUB 3 implementations, and discourage fragmentation. A subset profile of EPUB, if one is created, should be targeted to support content archivability not subset reading systems (as with PDF/A: there’s no such thing as a PDF/A viewer, only PDF/A content).

Sure. I don’t see how that affects my point. The key to modularisation hinges on requiring interoperable implementations to exist before a standard is officially ratified.

You are never going to get complete EPUB3 implementations. Not many of them, at least. The standard is too big and too varying, with too many options, shoulds, and maybes for that to ever happen, even if you disregard implementation issues. That’s the reality of all complex technological standards. The best you can hope for is interoperability and consistency.

So, my suggestion is to use the subset profile as a base specification and define every other feature as a module with its own timetable, editorial process, and require at least two interoperable implementations before each module is ratified as an official spec.

You - and maybe even some actual publishers - may only care about straight-text novels, and may not even care about accessibility thereof.

If my tone in this post is on the annoyed and angry side, you can put the blame squarely on this statement. I find it difficult to believe that anybody can read what I’ve written on this site and still think that I only care about straight-text novels and not about accessibility at all.

I’ve come to expect this sort of condescending attitude from Bowerbird but, unfortunately, it looks like it’s a tactic Bill McCoy is going to use as well.

First of all, the remark comes at a time when I’ve been spending most of the week testing a new website in screen-readers and fixing the quirks and bugs that I find. This entire week has been dominated by accessibility work. (Side note: the VoiceOver rotor is an awesome nifty thing.)

I test all of my ebooks in a screen reader, where available.

I take accessibility seriously. Much more seriously than the ebook industry does as a whole.

Because accessibility sucks in ebooks. Most ebook reading apps on iOS don’t support the VoiceOver screen reading feature at all. The text of the book is invisible to the reader and you’re lucky if the app exposes the UI to VoiceOver properly. The only reading app I’ve tested that supports VoiceOver without major bugs and odd behaviours is iBooks. Amazon even removed the built-in screen reader from its newest eink device. Screen reader support in Android (which is the basis for most non-Apple tablets) is atrocious, so that’s not something that app developers can do much to fix, even if they were trying, which they aren’t.

Amazon does ship text-to-speech for books and documents in their latest Kindle Fires (not the original Kindle Fire, though), but that only highlights how little the EPUB ecosystem cares about accessibility. (I don’t know if it is a proper screen reader that exposes the device’s UI. Don’t have one to test, unfortunately.) If you want ebook text-to-speech support, your only choices are iBooks on iOS or one of Amazon’s new Kindle Fires.

Most of the issues I’ve been complaining and pondering about on my site and elsewhere (CSS, javascript, interoperability, interactivity, and quality—just look through this site and see what I write about) are non-issues for straight text ebooks. If all I cared about were straight text ebooks, I’d be a happy man. It’s because I want more that I complain.

It’s safe to say that I’m a little bit pissed off by Bill’s remark.

So there may be EPUB 3 features that a particular content developer can and should ignore. But EPUB as a standard is being adopted in many segments of publishing and for interoperability to work, we want to encourage implementations to be able to handle any conformant content, not just some content. And I don’t see any individual feature of EPUB 3 languishing for lack of adoption.

Then Bill hasn’t been testing enough. My testing of, for instance, iBooks 3.0, which has been touted as being ahead of others in terms of EPUB3 support, would indicate otherwise. So, unless Bill’s definition of ‘adoption’ doesn’t require actually shipping the ereader or app to the market, then it’s a plain fact that there are a few features of EPUB3 that are indeed languishing for lack of adoption.

(‘Segments’ that don’t include major apps and major platforms are synonymous with ‘niches’ and hardly qualify. They’re nice to have once the major platforms are on board, but until that happens it’s like the W3C getting a few universities to adopt Amaya as their default browser and claiming it as a win against Internet Explorer.)

Of ones you mention: media overlays is critical for accessibility as well as children’s talking books, and combo eBook+audio books .

Media overlays aren’t critical for accessibility because:

  1. They aren’t being implemented for accessibility. All major shipping clients only include it as a part of children’s talking books. iBooks, for example, only supports it in fixed layout books and not in regular ebooks.
  2. A feature nobody supports and doesn’t exist in any major client clearly isn’t being treated as critical for accessibility. It might benefit accessibility. It might actually be critical for accessibility, but, as I demonstrated above, the ebook industry and ereader vendors don’t give a damn about accessibility (except for Amazon and Apple, of course).

Also, in my opinion, it reflects an archaic point of view. Synced text and audio ebooks that are specifically authored for those who are disabled are a holdover from a pre-digital time. They are from a time when the only books that were accessible were those that had been specifically transcribed and dictated into braille and audiobooks.

In digital we have the opportunity to make every single ebook accessible to everybody, not just the subset of available titles that happen to have an embedded audiobook synced to the text. Everybody. Shipping ereader apps and devices with screen reader support is critical for accessibility. It’s also something that nobody is doing in the EPUB space, except for Apple.

So, I’ll start caring about media overlays as an accessibility feature when screen reader support is the norm in the ebook industry and not the exception.

And my proposal wasn’t to drop media overlays. Sure, I made an off-hand quip about unimplemented EPUB3 features in general, but the actual proposal is right there in the header: “Modularised EPUB”.

Scripting is critical for interactive titles and in education is essential for things as basic as quizzes.

Sure. And like I said, the proposal wasn’t to drop it but to separate it out into a module so that interactivity could be addressed, improved, and developed on its own timetable without holding up, or being held up, by other features.

It’d be interesting, one of these days, to write a post where people would address the actual points of the post, and not ancillary stuff they address just to avoid going into detail on the real issues. Hasn’t happened yet, but it would be nice.

Declarative triggers and bindings are more speculative pending better tool support but the principles of declarative content and modular extensibility are sound. So while as with any standard there may be a feature or two that ultimately doesn’t gain wide adoption, I personally have zero regrets at this time re: things we put in that we shouldn’t have.

The principles of declarative content and modular extensibility are indeed sound. Good theories. They are also implementation-driven principles that are hard to impose top-down. Why do you think HTML5 has rolled back some of the modular extensibility that was a core feature of XHTML?

It’s because HTML5 (for better or for worse) is driven almost exclusively by implementors and XHTML was driven by well-meaning people who thought to themselves that a spec based on sound principles and good theories would inevitably get implemented.

Of course, we are now finally getting some simple declarative interactivity in HTML5 forms but the inclusion of those features was done with a broad implementor consensus which declarative triggers and bindings clearly don’t have.

IMO, declarative triggers and bindings shouldn’t be a part of the next revision of the Content Documents spec (which should, indeed, be a spec of its own, with a timetable independent of the others). They should be put in a spec of their own and their survival as a feature of EPUB3 should hinge on their ability to generate interest from implementors.

(Personally, I’m not convinced that bindings add much value beyond what the basic modular extensibility that’s a core feature of XHTML can accomplish when combined with scripting. Bindings seem to require scripting anyway for fallbacks and graceful degradation when faced with no scripting support is what you should be doing anyway, bindings or no bindings.)

Annotations OTOH is something I regret not getting into EPUB 3.0 in the first place, albeit to the point of regretting the decision to keep EPUB 3 on schedule. The subsequent NISO effort, in which IDPF undertook to participate, has been moving rather slowly. Too slowly IMO.

Telling people about it might help. I’m pretty sure that most people in the ebook industry have no awareness, whatsoever, of any effort by NISO or anybody else at standardising annotations.

It’s certainly the first I’ve heard of it. Judging by this page on the NISO website, it looks like there hasn’t been any activity by them on the subject in 2012 at all.

I also notice that Bill didn’t actually responded to my specific suggestions on annotations in any way.

Bill also ignored my points on the IDPF staying out of CSS (I was specifically thinking about CSS page templates when I wrote that part) and on the issues with gracefully degrading fixed layout ebooks.

I can’t say that I had high hopes about the reception of my post.

The only thing I really hoped for was for more people to be aware of problems that will eventually have to be solved. I think it succeeded at that. I didn’t expect anybody to actually do much, but if a single toolmaker or programmer working for an ereader vendor pauses for a moment to consider these issues when they are working on their next big thing then I’d call that a success.

Ebook platform vendors are almost certainly aware of these issues; ebook developers shout loudly enough about them.

I even expected to get a comment from Bill dismissing my proposals and explaining why wishing really really hard that everybody would just implemented full EPUB3 support would solve everything.

Which isn’t actually too far off from what he wrote.

I didn’t expect the reply to mischaracterise the post so substantially. I didn’t propose standardising buggy behaviour. I didn’t propose dropping features. I didn’t propose that we ignore accessibility. I didn’t propose that we give up on interactivity.

I probably should have expected this sort of response, but, frankly, even I’m not that pessimistic.