CSS and ebook design

In this case I vented my spleen in response to what was a fairly ill-informed post on a major mistake Amazon is supposedly making with its new Kindle Format 8 (KF8 for short).

The problem being that the problems as outlined are problems only if you don’t understand the technologies underlying both KF8 and Epub31, namely, HTML5 and CSS3.

Now, in my usual fashion, I went way over the top in both language and tone. Calling all ebook designers who don’t know web development useless was offensive and for that I apologise without reservation. I also swore too much.

However…

Any ebook designer who doesn’t know web development, CSS specifically, will severely compromise their job security unless they do bone up on those skills before KF8 and epub3 gain traction in the marketplace. Not heeding that warning because of the tone of the message is foolish.

Let me start again from the beginning.

I made my first website (now blessedly disappeared into the ether) when Netscape Navigator 2.0 was only a few months from being released2. Anybody who knows how the next ten years went would know that the web browser landscape was dominated by a series of often wildly incompatible browsers, some of the more horrible of which simply refused to die. I still get a shiver at the thought of the work we had to put into supporting Netscape 4.0 the mere mention of Internet Explorer 6 to a web developer will prompt loud swearing, hissing, spitting, followed by a series of uncontrollable sobs.

CSS was developed in this landscape and over time has gained features specifically to tackle the issue of delivering designs to a variety of largely incompatible browsers that support wildly diverging features.

The way we dealt with Netscape 4, for example, was to use @import stylesheets, a feature all newer browsers supported, but Netscape 4 didn’t. Child syntax selectors (elem > elem) don’t work in Internet Explorer 5, 6, and 7 but can safely be used in other browers. Some of these solutions were unreliable hacks. Some of them are still legitimate ways of delivering CSS to specific browsers (like CSS conditional comments in Internet Explorer). But, generally speaking, newer browsers support a host of selectors that older browsers do not. Under the right circumstances a well chosen selector can be a reliable way of having your design degrade gracefully for those users who hate their computers and still insist on using insecure and buggy browsers that are a malware writer’s wet dream (people seriously endanger their computers by not updating, although that’s another post entirely).

CSS then standardised on a method for delivering stylesheet rules depending on things like screen resolution, screen DPI, device type, device orientation, browser mode, and more: The @media rule.

It works really well. It’s supported by all modern browsers, including the latest versions of Internet Explorer (both desktop and mobile). It solves a lot of problems that used to be very difficult or almost impossible.

Which brings me back to the post I was responding to. The original poster presented what he thought was an intractable problem. The older Kindle devices don’t support the CSS properties, selectors, and rules that KF8 offers and often need starkly different designs from what are appropriate for a KF8-supporting device. He didn’t see how an ebook developer could solve that problem and declared that Amazon had made a major mistake. Meanwhile, KF8 supports @media rules for “All” and “Screen”.

I hope you see why, in this specific instance, an ebook developer who doesn’t know web development is indeed fucking useless. He can’t solve a problem that is Web Design 101. He doesn’t see that Amazon is offering him a variety of capabilities and tools specifically designed to solve his problem and solve it with an elegance and grace that is rare in the tech world. Without web development skills, the ebook designer in this situation only has the option of remaining with the limited Mobi format or to abandon older Kindle devices.

Ebooks are facing explosive growth. They are being read on a multitude of divergent devices. Reading systems are being updated to support HTML5 and CSS3. There is no way to tackle an ecosystem this diverse, with all of the problems this variety presents, without using the tools offered by CSS. You can’t just learn CSS just as it relates to ebooks. KF8 and epub3 ebooks support the full CSS stack and are facing all the same problems CSS solves for web sites. Learning CSS in this context is learning web development. You can’t avoid properly and fully learning CSS. You simply can’t.

And to use those tools you absolutely have to understand CSS. You have to understand @media rules. You have to understand how the cascade works. You have to know how to solve specificity bugs. You should understand why using #id selectors in any other way than as a singleton increases the chance of intractable specificity problems.3 You should understand how pseudo class selectors affect specificity.4

If you don’t understand these (and many other) concepts you are going to run into problems you cannot solve.

A way of getting around this, often thrown at my head when I debate this, is for a designer to collaborate with a ‘coder’ – a term I that is sweeping, vague, inexact and dismissive.

I’ve done this myself in web development. I recently, for example, collaborated with the extremely skilled Kári Emil Helgason. It was both fun and rewarding and the reason why it worked as well as it did was that he knows CSS and understands web development.

Now, that isn’t to say that this wasn’t a true collaboration. As I implemented the design, I solved several problems he couldn’t have tackled without spending much more time and effort than I did. I implemented a Wordpress template in a fraction of the time it would have taken him at the time. He came up with really nice designs I couldn’t have (and I mean really nice). I implemented things much quicker than he could have, and solved problems that probably would have stumped him.

But the heart of the collaboration was in tackling both the intractable issues that arose (both technical and non-technical issues) and had to be worked around, and the feedback we got from those responsible for a lot of the content of the site and were responsible for supporting it. We exchanged ideas for solutions and tweaks, all bearing in mind what is and what isn’t possible in the browsers we were targeting. This wouldn’t have worked if he didn’t understand the cascade, how colour works in CSS, or the theories behind how CSS works.

The problem with presenting the designer/coder collaboration as a way of avoiding having to learn CSS is that in the real world HTML and CSS is the lingua franca of any such collaboration. The CSS coder is not going to know book design lingo, which doesn’t anyway reflect the concepts and models and issues of coding CSS. Even if the designers don’t have the confidence to write the code they need to understand it conceptually and once they do that they know CSS, they’re just a bit slower at it than someone more experienced.

Not learning CSS because it might get replaced is misguided because the only thing that’s going to replace CSS3 is CSS4. It’s been around for over 14 years and will easily be around for several more.

With KF8 and epub3, the web stack is the ebook stack. It has all of the same features. It suffers from all of the same problems. I don’t see any way out of fully dedicating yourself to understand HTML and CSS if you are intent on a longterm career in ebook development.

It’s not all bad, though. It looks like you can freely avoid javascript.