Baldur Bjarnason

Game over, Amazon wins

– Baldur Bjarnason
Peter Sorotokin responded to my griping about IDPF’s CSS Page Templates. I pretty much agree with everything he says, but it doesn’t bring me to a conclusion ePub proponents will like.

Baldur,

First of all, thank you for taking time to read the spec and write down your thoughts. I really appreciate this.

There are certain things in your post which boil down to perspective. One person’s “edge case” is another one’s hard customer’s requirement. A “tiny minority” might be a group of people who produce most of the content. It is not particularly useful to argue about it, so I won’t.

Another thing worth noting is that organizations are not people. The “F” in IDPF stands for “Forum” and “G” in CSS WG stands for “Group”. By the very nature of these organizations, the positions of the members of these groups differ wildly on almost any subject you can think of. So it is meaningless to speak about what, for instance, CSS WG wants or does not want to look at. People who are interested in driving some efforts just go and do it and group leadership cannot (and not even supposed to) really control it.

One important point that you make is that being standardized in IDPF, PGT is unlikely to ever make it in the browsers, at least in its current form. This is true, but it is not really relevant, because PGT can already be implemented in all modern browsers, using existing stable standards, through JavaScript. In ideal future world, we should be able to map PGT-styled content into CSS3/CSS4 features implemented natively in the browsers, but if that ideal would not materialize, we always have JavaScript implementation as Plan B. That makes PGT much more incremental than relying on blazing-edge CSS features which are missing from many important platforms and for which spec development could move in an entirely different direction.

Now, to the technical details, although, they are largely the function of what I have said above.

There are two parts in PGT. Part one is variables, “when”, and expressions. It is true that there is an overlap with the current CSS WG work, but this part of the spec is much more similar to macro frameworks like LESS than to what CSS WG develops. That whole part is fully implementable as a pre-processor for CSS stylesheet. Variables and calc are still very much moving targets and developing content that relies on the details of the browser implementations for these features would be very risky (blazing-edge CSS problem) and they cannot be implemented through pre-processing. There is certainly an overlap between when and media queries - and media queries are can be used instead of when, of course (when it is possible), - but once you have a set of variables, it is really convenient to use them inside of conditions as well.

PGT part two is about page masters, flows, and partitions/regions. You say that eReader vendors should just implement Regions spec. Well, but how would it be used? The seems to be a consensus in the CSS WG that currently it is almost unusable without scripting and there is a need for some other module that would “generate” the regions (either some form of page templates or pseudo-element generation). You also mention CSS Paged Media Level 3, but that module is not widely or reliably implemented and very far from being a finished spec (blazing-edge CSS problem again).

Finally, about solving simple issues first. When it comes to “plain” books with just regular CSS styling, the problem today is no so much in lack of styling options, but in the broken interaction between author’s styling and Reading System internal styling and rendering policies. Content creators and Reading System vendors just cannot agree on who controls what at the low-design end, and standardizing something requires consensus. So ironically, it is much simpler to standardize it on high-design side (fixed and adaptive layout), where everyone basically agrees that the author’s design must be honored. On the low-design side we are just stuck.

I have uploaded sample PGT-styled file, including PNG files for possible rendition. Take a look if you are interested.

http://code.google.com/p/epub-revision/downloads/detail?name=page-templates.zip

Peter

Peter,

Thanks for your reply to my post. Your email clarifies quite a few things and now I think I understand better where you are coming from.

I appreciate not arguing about the sizes of the ebook market’s various constituencies (although, I hope the masses that are creating ebooks today won’t be completely ignored or dismissed :-).

On the organisations: Both the IDPF and the CSS WG are dominated by rendering systems developers and, as such, their priorities are pretty homogeneous from an outsider’s perspective. I’ve been reading through a lot of meeting minutes for both the IDPF and CSS WG over the last couple of weeks (decided to try and understand properly what is going on there) and at least the members of the CSS WG agree much more than they disagree. Most of the distances and schisms are on marketshare issues and quite a few of the differences clearly seem massive to the participants.

But they aren’t that big. CSS WG functions as well as it does (barring the occasional mess like the recent prefix hoopla) because the priorities and interests of the members are pretty homogenous. (It didn’t use to be like this. The CSS WG is on a roll lately and functioning a lot better than it did a few years ago.)

IDPF, on the other hand, I can’t quite get a bead on, and I’ve read through about a year’s worth of mailing list emails, minutes, and about half of the pages on the wiki. It’s been doing a lot of good with the fixed layout spec but, even after reading most of what I can find online, I still don’t get the feeling that I know what’s going on in the IDPF.

Though, now that you have explained, I understand why you are doing what you’re doing. The point about Regions requiring javascript is a good one. It’s exactly something I’ve been tackling this week as I’ve been trying out Chrome’s support for the spec. And, yeah, CSS Regions really only become useful when you have support for the Regions CSS OM (which is missing in Chrome at the moment).

I’d still choose it over Page Templates any time I’d have an option, but I appreciate that in many cases Regions simply won’t be an option.

I take your point that there is a certain safety in the approach chosen with Page Templates. It’s certainly based on pragmatic decisions all the way. And it does offer quite a few nice capabilities, if at the expense of some complexity. I can even think of a few projects that might warrant those capabilities.

So I find that I agree with all of what you’ve said. As a solution for high-end needs, Page Templates look like a useful option. Organisations are diverse which results in priorities that look odd to outsiders.

But your final point is the one I feel the most keenly. Quite a few reading system vendors are hostile to ebook designers, override the stylesheets that come with the ebooks, or otherwise make the designer’s life very difficult. I’ve never seen anything like the mess we have with ePub reading systems, even during the worst days of the browser wars.

But, if reading system vendors don’t accept that they need to follow the CSS spec’s basic rules on the cascade order, where the author declarations take precedence over both user agent and user normal declarations, then, in the immortal words of one of the marines in Aliens, it’s: “Game over, man. Game over!”

There’s no point in using CSS as a part of the base ePub spec if the implementors can’t agree on following one of its basic principles.

Because I can tell, already, what will happen if they follow this path. It’s a simple story, with a few horror overtones to some. It certainly isn’t anything the members of the IDPF will like, appreciate, or want.

It goes like this:

Reading system vendors keep the design capabilities of low-end ebooks limited while allowing advanced design capabilities only for those who go whole hog and use CSS Page Templates.

Because ebook developers and publishers care about their work, have a passion for it (nobody goes into publishing to get rich), they go through the effort of implementing Page Templates. Over time, a spec intended for the high-end becomes the standard for all ePubs, high or low, fiction or non-fiction—all of them.

Meanwhile Amazon iterates on KF8, focusing on keeping the format compatible with web standards and on making it easy for ‘low-end’ publishers to implement their designs with a lot less fuss and work than with ePub.

Their competitors begin to get a reputation for being overly complex and expensive to develop for. ePub becomes the expensive option because publishers won’t accept more limited design capabilities than the Kindle offers and ePub vendors offer no easy and cheap ways of achieving them.

Some of the smaller publishers begin to reconsider even distributing to ePub platforms. For some the added expense just isn’t worth it for a minority marketshare.

Then Amazon releases a simple and free GUI tool for styling reflowable epubs. Nothing fancy like iBooks Author or whatever Adobe is planning. It just gives them the ability to create really beautiful text-oriented ebooks. It imports ePub, doc, rtf, and HTML files. They can set the backgrounds, borders, and margins. Float some images here and there. Embed nice fonts. Add a movie or two. After that Amazon begins to add support for CSS font-feature-settings and updates the GUI tool to support it.

Most publishers of text-oriented books then face two choices:

  1. A ubiquitous platform that supports exactly the features they want (floated images, full-bleed page backgrounds and borders, embedded fonts, opentype font-features). Cheap to develop for. Cheap to use. Has a most of their customers. Supported on all major devices and OSes.
  2. A diverse set of heterogenous platforms that differ in a multitude of small ways (most of them non-technological, like B&N’s decision to override publisher stylesheets). A pain to test. Hell to develop for. Most of the tools will be either very expensive (Adobe’s) or proprietary to one platform (iBooks Author). The only way of getting the designs they want is to use a more complex spec that involves more work and isn’t supported by either web browsers or the Kindle. Together, these platforms have a minority of the market, but represent the majority of the publisher’s development costs.

A lot of publishers will just abandon ePub and it’ll be game over, the Kindle has won.

The following wasn’t a part of my email, just a few thoughts it prompted the day after.

There are only a few design features most fiction and text-oriented non-fiction publishers need from an ebook platform:

Things like SVG, video and audio, and something like well-integrated web view overlays, for those times when javascripted interactivity is needed, are nice bonuses but the above bullet points are the basic needs. These design bonuses, however, could let more simply designed ebooks compete with the flashy high-end books many vendors are currently focusing on, at a fraction of the cost. A common trend with disruptive innovations is that the low end iterates until it is good enough and drives the high end out of the market.

Complex layouts, intricate flow, and extensive design capabilities aren’t a big concern for the makers of the kinds of ebooks that are easily over ninety per cent of the ebook market today. Text-oriented ebooks are the current ebook market and they are being abandoned by ebook vendors because they think they are commodities that neither need nor deserve any differentiation.

The problem is that ‘content’ – books – resists commodification. You can’t exchange Twilight, the Harry Potter series, or J.A. Konrath’s books for a generic slush-filler ebook during a sale and not expect an uproar.

Prices are being pushed down; that’s because of competition and supply, not commodification. Volume is skyrocketing; because of easier distribution, not commodification. All of these books, good or bad, cheap or expensive, are clearly differentiated.

These books are barking mad, sometimes, and often quite incoherent, but undifferentiated commodities they are not.

Sure, the slush pile and the long tail of the market are generally a homogenous mass about as pleasant and tasty as puréed crap, but they are very much not interchangeable. Even the most puerile and inane self-published book is uniquely bad and unlike any other.

Any vendor who treats text-oriented ebooks as commodities will be surprised when the occasional title migrates from the ‘undifferentiated’ tale to the head and begins to get substantial sales. It’ll be an unpleasant surprise because most of those sales will be on their competitor’s website and not their own.

I’m now a lot less sceptical, somewhat optimistic even, of CSS Page Templates and I have a newfound appreciation for some of the complexities and issues involved in trying to standardise formats. Things inside of standards groups aren’t as clear cut as they seem to those of us on the outside. I have learned a lot from the discussions and exchanges I’ve had over the last couple of days.

And I have to add that I really do like a lot of the work IDPF has been doing, even though I gripe a lot. The ePub3 effort went a lot better than I expected and I very much like how the Fixed Layout spec is developing.

But I am now even more pessimistic than ever before about the ePub ecosystem’s ability to compete with Amazon. I don’t think many of the reading systems vendors understand what is happening or why Amazon has such a strong hold on the ebook market.

If you think that Amazon is winning just because they were early to the ebook game then I can guarantee you that Amazon will eat your lunch.

Response

Bill McCoy sent me this response:

“I’m now a lot less sceptical, somewhat optimistic even, of CSS Page Templates … And I have to add that I really do like a lot of the work IDPF has been doing, even though I gripe a lot. The ePub3 effort went a lot better than I expected and I very much like how the Fixed Layout spec is developing. But I am now even more pessimistic than ever before about the ePub ecosystem’s ability to compete with Amazon…”

Baldur, I appreciate the kind words about recent IDPF work.

But as far as the EPUB ecosystem competing with Amazon, as I’ve said before my optimism stems not from under-estimating Amazon (that would be a mistake!) but because it’s clear that digital publishing is on a convergence course with something even more potent… the Open Web. EPUB is just the reliable packaging of Web content. Amazon can’t hope to dam up the definition of what a digital book is into their subset proprietary fork of Web formats, any more than CompuServe, AOL, or even Microsoft could do so. Or Adobe with Flash. The Web just has too much momentum. And, Amazon already recognizes and accepts EPUB as the primary delivery channel for digital content from major publishers so KF8 wouldn’t really pose an acute danger even if it wasn’t so limited. Actually in the short term I’m more worried about other more capable proprietary formats based on HTML5 like Inkling S9ML and Apple .ibooks, although I feel confident we’ll find that there’s no need for proprietary (much less proprietary & secret) forks of HTML5 to deliver any of the UX polish that these platforms current provide.

I do fully agree with you though about the need for EPUB-based Reading Systems to get more capable ASAP. In that regard I’d like to underscore my previous email question to you: are you just going to keep griping and whining that it’s impossible to compete with Amazon, or are you going to saddle up and help bring digital publishing and the Open Web together and ensure we have a real global standard?? IDPF announced Readium Project less than a month ago and we already have integrated more than a dozen contributions from the open source community, with more coming in daily. We’d love your, and others, help in setting the bar high for a conformant EPUB 3 implementation.

–Bill