Posted by & filed under book design, css, ebooks, epub, ibisreader.

ePubs are being created with increasingly sophisticated designs and ebook devices are becoming increasingly powerful. This creates a real tension: ePub creators want to be able to develop nuanced ebook designs using CSS, the makers of ePub reading systems face an expanding range of screen sizes (from postage stamp to poster size), and some readers have become accustomed to being able to control every aspect of the setup of their reading environment. One of the great aspects of the design of the ePub specification is that it uses many of the same standards as the web. This means that publishers can turn to a web designer for CSS help rather than having to find someone more specialized and rare.

As folks who need to listen to the desires of ebook readers, help publishers understand how to get the best from ePub, and implement increasingly sophisticated ePub readers, we’ve gotten used to riding a fine line between enabling thoughtful design and ensuring a pleasant reading experience on a wide range of devices. Here are some pragmatic perspectives from our experience building reading systems that can help those coming from a web CSS background understand some of the tradeoffs in the ebook design world.

I’ll start with a simple example of the impact of CSS margin and width on an iPhone-sized screen:

A display of the impact of CSS margins on an iPhone-sized screen

This may look like a minor change, but the line lengths were reduced from 34 characters down to 27. Either one of those line lengths is already less than the typical “sweet-spot” from printed book design, so losing nearly 20% is actually quite significant. The real surprise from the margin example above is that it comes from Feedbook‘s tremendously reasonable CSS.

The problem (from the perspective of a reading system) is this: readers need top-level margins to make the text digestible, but we can never unambiguously tell if the ebook designer has already included top-level margins in the design. Basic, top-level margins should be established by every reading system based on the device being used and designers should include margins in their CSS only when they are focused on a specific type of content like a blockquote or poem. Unfortunately, some early ePub reading systems failed to establish even basic margins for readability, so many ePubs are designed to compensate for that flaw. [If you'd like a future post explaining the history of how we got to this position, please let us know in the comments.]

Now we’re in a chicken-and-egg fight: if ebook designers would include more complex design elements (and eliminate unnecessary margins), the makers of ebook reading system would be more motivated to fix their margin bugs and add more CSS support. Today, the maker’s of ebook reading systems might honestly believe that these features aren’t requested because the designers are being understandably pragmatic about current capabilities in the wild. We’d like to encourage more deliberate ebook design, but also inform designers about some of the basic design elements that might be dropped on the floor by the reading system.

What do we do in Ibis Reader? Because of limitations in screen size, Ibis Reader tries to override the following CSS properties when used on an iPhone, iPod Touch, Droid, or Nexus One (as an installed app) at the chapter level:

Left and right padding and margin
We need to be able to limit the length of lines.
width
We need to be able to ensure that the user interface isn’t ever wider than the screen, so that scrolling isn’t required (except for code or other verbatim blocks).
font-size
Readers have a wide range of ability and sightedness, so we give them control of the base font size (but relative sizing still works as expected).
font-family
This one is a bummer. The current set of mobile devices don’t all support some of the newest techniques for including other fonts, so we’re limited to a tiny number of font families at this time.

Happily, the web version of Ibis Reader does not have these restrictions, especially when used on a big screen, so the design from the ePub is usually more faithfully preserved. However, we do still discourage ebook designers from using the following CSS properties:

That said, none of the above are hard and fast rules, and there may be occasions where any one of the above is entirely justified by the confident.

PS: A secret for ebook designers: While there are a lot of techniques the creator of a reading system can use to alter the CSS from an ePub, the most standards-compliant way you can make your voice heard is to use the !important declaration. Like any tool with great power, !important should be used sparingly and only in situations where you are confident that the clarity of the text will be compromised if a property is not honored.

Tags:

11 Responses to “ePub and CSS: a reading system perspective”

  1. Liz Castro

    Interesting!

    There were a whole bunch of implications in this sentence: “Ibis Reader tries to override the following CSS properties when used on an iPhone, iPod Touch, Droid, or Nexus One (as an installed app) at the chapter level:” that I’d love to have clarified:

    • Does Ibis Reader offer a different experience for all (of those) eReaders? And you didn’t mention iPad… what happens there?

    • What do you mean by chapter level? As opposed to individual pages?

    My personal opinion is that we need to all get to the same page really quickly… eReaders overcompensating for bad design practice reminds me a lot of Internet Explorer, which has taken years to shed that habit (and is still working on it).

    I want eBook designers to be able to follow the OPS spec and design a beautiful eBook and be confident that eReaders will display their books as designed. How we can avoid the sea of hacks and cross-compatibility issues that inevitably await otherwise?

    best,
    Liz
    (going to test !important)

  2. Liz Castro

    P.S. Yes, a history of how you got to “Basic, top-level margins should be established by every reading system based on the device being used and designers should include margins in their CSS only when they are focused on a specific type of content like a blockquote or poem.” would be much appreciated.

  3. Keith Fahlgren

    Does Ibis Reader offer a different experience for all (of those) eReaders? And you didn’t mention iPad… what happens there?

    Ibis Reader tries to look very consistent across all of the devices that can use the HTML5 mode, although there are some minor differences in how the individual browsers show the pages.

    We’re waiting till we have an iPad in our hands before we make specific design choices for that device, but I suspect it’ll get special treatment, as we don’t need to be quite so agressive in conserving screen real estate on that big of a device.

    What do you mean by chapter level? As opposed to individual pages?

    I’m just struggling for vocab here. I’m talking about CSS targeted at high-level selectors like body and @page to establish margins at the “page” level rather than something much more specific that is focused on the display of a single element.

    My personal opinion is that we need to all get to the same page really quickly…

    That’s our hope as well, and why we’re trying to be open and public about our choices. Some of them certainly will turn out to be wrong, so we’d like to encourage dialog and discover them early rather than playing things too close to the vest.

  4. Adam Witwer

    Glad to see this discussion happening.

    After a lot of testing with width, margins, percentages, etc., across several devices and reading systems, we finally settled on this CSS, which is used in most of the O’Reilly EPUBs:

    @page {
    margin-left: 8px;
    margin-right: 8px;
    }

    And then we zero out the margin and padding at the body level.

    I had a really hard time with percentages in some readers (particularly Stanza, which seemed to overcompensate) and so moved away from using them. And having no left margin at all makes the text smack up right up against window in ADE and other systems. In my testing anyway, 8 px seemed to be be the sweet spot, but that could change as the readers mature.

  5. bowerbird

    um, surely you let the end-user have the final say, not?

    so what does it matter what happens before that point?

    -bowerbird

  6. Liz Castro

    I’m pretty concerned that there will be a slew of different eReaders each with its own way of interpreting ePub styling. It’s browser wars all over again.

    It would be nice if there were the option of using the eBook designer’s styles as is. Is that a possibility you’ve considered?

    thanks,
    Liz

  7. TRS

    I would love to read more about width/margin chicken/egg. This is especially difficult in my books with code, tables, and nested content.

  8. Christoph Steinhof

    I sometimes depend on manipulate margins, if I need to create something like (automatic) paragraph or line counters. Therefore the “page” needs a lager left margin so that the numbers fit nicely besides the block of the paragraph.

    p {margin-left 2em; counter-increment: paragraph;}
    p:before {content: counter(paragraph);
    display: block; float: left; width: 2em; margin-left: -2em}


    The code above works great on the web version of Ibis Reader but not on the mobile one.

  9. Keith Fahlgren

    @Christoph: You raise an interesting use-case I hadn’t considered. I’ve emailed you privately to help understand the content in more detail.

Trackbacks/Pingbacks

  1.  iPad Links: Monday, March 22, 2010 « Mike Cane's iPad Test
  2.  Acronyms From XHTMLHELL | Ditchwalk