• Print

Ebook problem areas that need standardisation

A user experience plea for more consistency across platforms

The “best price” phase of TOC NY 2013 registration is about to end. Don’t wait or you’ll end up paying more than you would today. To save even more on your registration, sign up here and use the discount code JOE20 to get an additional 20% off the current price on the conference package of your choice.

Ebook publishing is full of problem areas, most of which cannot be addressed through standardisation but can only come about via a sea-change in the behaviour and nature of the various participants in the ebook industry.

There are, however, several issues that could be addressed, at least partially, via standardisation, that would make everybody’s life easier if implemented.


One of the major issues facing publishers today is the spiralling complexity of dealing with vendor rendering overrides.

Each vendor applies different CSS overrides with differing behaviours, sometimes even only enabling features through server-side manipulation, which means that proper testing of an ebook is not only difficult, but impossible.

If vendors cannot be talked out of requiring these overrides then they need to be standardised and normalised. Any reading system that implements a CSS override is in violation of how the CSS standard defines the cascade and so is in violation of the EPUB 3 standard.

CSS overrides come in four broad types:

  • Vendor styles only — The publisher’s styles are completely ignored in favour of the vendor’s.
  • Aggressive vendor styles, but publisher styles enabled — Very little is seen of the publisher styles in this scenario. They mainly surface in edge cases that weren’t accounted for in the vendor’s stylesheet.
  • Minimal overrides — The vendor only really enforces control over margins, backgrounds, and possibly font styles.
  • Publisher styles — The mode that the reading app goes into when the reader deliberately selects ‘publisher styles’. Under ordinary circumstances this would simply disable the overrides but in most reading apps this mode has a unique behaviour.

What needs to be standardised

How does the cascade work in each scenario? These overrides change how the cascade behaves. User settings in web browsers come second in the cascade, after the browser’s defaults, and both are overridden by the publisher’s stylesheet. In many reading apps user settings are mixed in with the overrides, which come after the publisher’s stylesheet in the cascade.

This has unfortunate consequences. Publisher styles in the browser context can build on the defaults and user settings, which is something they can’t reliably do in reading apps. Setting font sizes or other properties before the defaults and preferences are applied can result in different behaviours from setting them afterwards, depending on how the overrides are implemented. Unfortunately, reading apps are inconsistent in their behaviour, often varying wildly from app to app and device to device from a single vendor.

Because many of the user’s setting are a part of the override and not actual defaults, what the reader sees when they select ‘publisher styles’ is often a barren page that doesn’t take any of their preferences or defaults into account.

Reading apps clearly ignore the rules of the cascade. Standardising their behaviour is preferable to the current wild west that dominates the ebook reading app landscape.

What features are covered by the override stylesheets? (This applies to both minimal and the more thorough vendor styles.) It isn’t uncommon for some vendors to override both text colours and background colours. But some (I’m looking at you Kobo) tend to only override one or the other, often resulting in invisible text and unusable links. The current behaviour of CSS overrides frequently results in a much worse result: unreadable text, unusable links, and broken designs.

This behaviour needs to be normalised and standardised so that publishers know what to expect. And vendors need to properly think about how their overrides interact with existing designs so they don’t actually make the book much worse than it would have been without overrides.

Of course, none of this matters when vendors keep adding design features that are only enabled through server-side munging. Which means that the only way publishers can test books is by actually publishing them.

(I hope I don’t have to explain how much of a quality assurance disaster this trend is.)

Things that wold be nice to standardise

How detailed is the vendor stylesheet? Publishers need to know what cases are and aren’t covered by the vendor stylesheet so that they can avoid them in books that have to behave properly on platforms where vendors are overly aggressive.

Override opt-outs. It would be interesting to see if vendors are open to standardising a way for publishers to opt out of overrides, much like how iBook’s specified-fonts options toggle works.


There is no interoperability between ebook annotations systems today. If you’re lucky, you might encounter a vendor that lets you export your annotations as simple HTML, which usually discards a lot of the original context, metadata, and styles.

Annotations are, however, a big part of editorial work and the writing process. In the absence of interoperable annotations, publishers (self- or traditional) are forced to use PDFs if they want to read and annotate drafts on a device or a tablet.

(And when I say editorial work, I don’t just mean publishing. Almost every modern business needs to review and edit text every single day. If you want EPUB to compete with PDF and other document formats then this needs to be addressed.)

There are two ways of addressing this:

  • Specify a detailed and lossless format for exporting annotations and hope that vendors will implement support.
  • Specify a way of embedding bookmarks, highlights, and annotations in a DRM-free EPUB and wait for niche vendors to come out with EPUB reading apps with specialised editing and annotation features.

The first route would be ideal if we could actually expect it to work. If all ebook reading apps were full of proprietary export formats then it would be the path I recommend. But no ebook reading app to date even tries to do feature-complete, lossless, annotations import and export. Standardising a file format for a feature nobody is interested in implementing seems futile.

The second route is, IMO, likelier to succeed as the plurality of PDF readers with specialised annotation features demonstrate. This might be one of those niches where vendors can actually charge for their reading apps. Especially if they integrate features that tie into the workflows of most businesses.

Modularised EPUB

EPUB 3 is a sprawl of a specification. It’s full of complex crap that is extremely problematic to author and support.

I’ve heard from a couple of people that the IDPF is interested in standardising a stripped down, simple, version of EPUB 3.

I think that’s an excellent idea. I also think it should be the first step in modularising the EPUB 3 spec.

You’d have the core EPUB 3 features as the core spec.

epub:switch? Separate spec.

epub:case? Separate spec.

epub:trigger? Separate spec.

Scripting? Put all of that in a separate spec.

Bindings? Metadata? Media Overlays? CFI? All separate specs with their own groups, editors, and timetable.

Or you could always aggregate all of the dead-end features into a single trashcan spec that everybody can safely ignore.

Staying out of CSS

Nothing good can ever come from forking CSS and, make no mistake, any attempt on behalf of the IDPF to add ebook-specific features to CSS is going to result in a fork. Ebooks already behave too differently from the browser baseline as it is. Anything that increases that deviation is going to increase costs and the complexity of publishing ebooks.

So I propose that the IDPF give up on its efforts to standardise CSS extensions for EPUB and focus on advising the CSS WG on what ebooks need from CSS.

Graceful degradation for Fixed Layout

Both reflowable EPUB 3 books and fixed layout EPUBs support media queries. Both of them support a wider range of CSS design features than you find in EPUB 2 systems.

There is no easy way of creating a fixed layout EPUB 3 that uses features such as positioning, backgrounds, colours, etc. and degrades gracefully in EPUB reading apps that don’t support the fixed layout spec.

This is a problem especially for mixed-mode EPUB 3’s that include fixed layout pages in otherwise reflowable books. These pages often look incredibly ugly or are simply rendered blank in reading apps that don’t fully support the fixed layout spec, such as the recently released iBooks 3.0.

Figuring out some mechanism for graceful degradation in this context would be nice…unless, of course, everybody thinks that mixed-mode EPUB 3’s are a dead end that will never be widely implemented anyway.

What else?

There are a lot of things that should be standardised if we could reasonably expect them to be supported at all in the ebook industry.

But those issues should not take priority over normalising and standardising existing reading system behaviour.

tags: , , , , , , , , , , ,

Comments: 3

  1. oh geez, baldur.

    just when i thought you were getting smarter,
    you start writing for o’reilly.

    now i have to give up on you again.

    by the way, you used “it’s” two times here,
    and one of them is wrong.


  2. 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.
    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?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. 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). You – and maybe even some actual publishers –  may only care about straight-text novels, and may not even care about accessibility thereof. 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. Of ones you mention: media overlays is critical for accessibility as well as children’s talking books, and combo eBook+audio books . Scripting is critical for interactive titles and in education is essential for things as basic as quizzes. 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. 

    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.

Leave a Reply

Your email address will not be published. Required fields are marked *