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.
Overrides
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.
Annotations
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.