Here’s a tweak to the XHTML of a chapter and the CSS used for h1s that I did quickly without having to make a new EPUB or use iTunes:

The key to this hack technique is the free (as in beer) iPhone Explorer application, which exposes the contents of your iPad like a USB drive (including resources for Apps). It has both a Mac and Windows version, but I’ve only tested these instructions on a Mac. Before starting, connect your iPad to your computer and iTunes. You should not be using automatic syncing (“Sync Books” is not checked).

To get started playing with a particular EPUB, sync the file onto your iPad, open the book once in iBooks, then close iBooks. Now you’re ready to start moving the files back and forth (iPhone Explorer is all drag and drop).

1. Open iBooks to your Library (not a book).
2. Open iPhone Explorer (or hit Refresh if it was open, but this is occasionally flaky).
3. Expand [Your] iPad->Media->Books.
4. Find the [XXXX].epub you’re interested in and expand it until you find your XHTML content or CSS.
5. Drag the XHTML file or CSS you want to experiment with somewhere on your computer (perhaps your Desktop in the Finder) to edit.
6. Edit the file using something you like.
7. Drag the XHTML or CSS file back from your computer to the same location in iPhone Explorer.
8. Say “OK” to the “Overwrite?” dialog.
9. Open the book in iBooks to see the changes.

Now you’re ready to use steps 5–9 (closing the book in iBooks in between) to continue experimenting with the EPUB’s design or content.

It can occasionally be non-obvious which filename iBooks has assigned to your EPUB. Curious folks will want to play around with some of the other resources exposed in addition to the exploded EPUBs (check out Books.plist).

I took some content from Cooking with Booze by James Bridle (a.k.a. George Harvey Bone). It’s released under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 license, which means that this derivative work is as well.

I took one recipe and marked it up in EPUB:

I added some slightly useless annotations and illustrative images from Flickr (also under an Attribution license). I then added some JavaScript-based event handlers. If you tap on the hyperlinked items in the recipe, the annotation will fade in as a popup. Tap on the annotation to dismiss it.

There are two kinds of annotations available: image popups and textual notes. Here’s a text note:

The JavaScript here is extremely simple, though I needed to use webkitTransform rather than normal positioning code because iBooks does not recognize position: absolute and the like:

function popup() {
  var p = document.getElementById(this.id + '-popup');
  var top_of_el = this.offsetTop;
  p.style.opacity = 1;
  var new_y = p.offsetTop - top_of_el - 30;
  p.style.webkitTransform = 'translateY(-' + new_y + 'px) translateX(' + this.offsetLeft + 'px)';
}
function dismiss() {
  this.style.opacity = 0;
  var el = this;
  setTimeout(function () {
    el.style.webkitTransform = null;
  }, 1000);
}
/* Register the events */
var terms = document.getElementsByClassName('term');
for (var i=0; i < terms.length; i++) {
  terms[i].addEventListener('click', popup);
}
var popups = document.getElementsByClassName('popup');
for (var i=0; i < popups.length; i++) {
  popups[i].addEventListener('click', dismiss);
}

Here’s a sample of the XHTML:

1 wild <a class="term" id="turkey">turkey</a> breast

Some other nerdy details:

1. The fade-in effect uses CSS3. I think the iBooks implementation may not be hardware-accelerated like Mobile Safari — it’s less smooth than the transitions on Ibis Reader, for example.
2. Inline script blocks do not work, which is not a bad thing.
3. Scripts are disallowed from accessing remote URLs. This means that ebooks that interact with remote data, like the geo-aware ebook, do not work. Interestingly, this is one of the restrictions that Baldur Bjarnason suggested might allow for safe JavaScript use in ebooks in a recent comment on our post Practical Interactivity and Shaping the Future of EPUB.
4. iBooks caching is really annoying isn’t it?
5. I haven’t tried this on iBooks for iPhone.
6. I have no idea if JavaScript is allowed in the iBookstore…
7. …not that you need Apple’s permission to sell a DRM-free enhanced EPUB that users could load into iBooks themselves.

Download the sample EPUB book. All content in the book is licensed under a Creative Commons license of some kind; the whole bundle should be considered Creative Commons Attribution-Noncommercial-Share Alike 3.0.

That said, I encourage commercial publishers to explore interactivity in EPUB, and it goes without saying that we’d love to help, whether it’s to provide glosses and annotations like those shown here, or interactive quizzes, or animation, or…

Here’s the executive summary of the talk:

• You can add interactivity to an EPUB book using either the <object> or <script> elements.
• Currently object has the best support, especially using Flash in Adobe Digital Editions.
• The script element is specifically discouraged (though not disallowed) in EPUB 2.0.1, and no major reading system supports it. However, all browsers do!
• The primary advantage of interactivity using script is that the content creator has the ability to manipulate every part of the ebook: all of the text, its layout, even potentially the user interface of the reading system itself. With object you can apply interactivity to just an arbitrary rectangle.
• There is a great deal of interesting animation and even interactivity possible using CSS3, which is allowed in EPUB 2.0.1 and is supported by iBooks and other WebKit-based ereaders.
• Interactivity is also possible using JavaScript combined with the HTML5 canvas element, though canvas is not part of EPUB 2.0.1.
• With access to JavaScript on mobile devices, ebooks can potentially gain access to information about the reading device itself, such as the location of the reader in the physical world, or the device’s orientation, or even add photos and video from the device’s camera.
• Any ereader that allows JavaScript provides the ability for ebooks to access live data on the web.
• The primary blocker for extremely rich interactive ebooks is ereader support, but by embedding browser-based reading systems like Monocle, content creators can distribute such ebooks today.
• It remains to be worked out how to handle JavaScript in larger ereading systems both safely and with proper fallbacks to non-interactive content.

I’ll also be posting some of the example files used in the tutorial in a forthcoming post.

To try to shed some light on some complicated work, I’ve pieced together a very incomplete introduction to some of the new things that HTML5 and related specifications might bring (remember: they aren’t finished or implemented everywhere).

Seven concrete areas of opportunity:

New semantics

HTML5 adds a bunch of new elements that might help publishers represent their content more clearly.

• section, article, header, and aside should be very useful wrappers for real-world content.
• Older web browsers will safely ignore unknown tags, but some ereaders that aren’t based on browsers may exhibit unexpected behavior. Also, typically, semantic tagging alone won’t drive a lot of sales.

Drawing

HTML5 adds a canvas element, which allows for (really snazzy) complex drawing and animation. Mark Pilgrim’s chapter in Dive into HTML5 offers not only the hairy details but also an example of how embedded HTML5 can change instructional materials (view it in Safari).

• This might replace some of what we think about when we say ‘Flash’ casually. It might allow for more interactive elements to be included in content.
• There are no easy-to-use tools that generate canvases — they must be coded by hand (Although it sounds like some basic tools are close).

Video

HTML5 adds a video element, which offers the first standards-based way to embed video in a web page. Similarly, an audio element has been added.

• Seamlessly embedable video may offer new ways of assembling and delivering multimedia content.
• Licensing for the actual encodings of the video content (the way that they’re compressed and stored) is unbelievably messed up and getting worse.

CSS3

A related set of updates to the Cascading Stylesheets specifications, CSS3, is often discussed alongside HTML5.

• CSS3 may bring a range of delightful updates for content creators, from better support for font-faces on the web to animations and transitions that may (along with canvas) allow alternatives to Flash for flashy stuff.
• Licensing solutions for fonts on the web are still in-progress. Authoring tools non-existent; support not complete across browsers.

Geolocation

Updates to a JavaScript API alongside HTML5 allow for users to reveal their physical location.

• There are probably a lot of opportunities to connect reading, readers, booksellers, and where people actually are.
• Very little support on desktops or more basic phones.

Offline Applications

A set of specifications related to HTML5 make it possible to create web applications that run without an active internet connection.

• Offline web applications can offer many of the features that standalone iPhone and Android Apps have and do not have to go through any App Store. They may also be more portable, as they don’t
  have to have a separate set of software for each platform. [Explicitly: This is the part of HTML5 that allows Ibis Reader to behave just like a normal App on iPhones, iPads, and Android phones.]
• Offline web applications are typically slower than standalone apps, although this will become less important as faster devices like the iPad become more common. Support on platforms is not uniform. Firefox doesn’t seem interested in supporting the current database specification.

Microdata

Another related specification that provides way of adding machine-readable annotations to content.

• One use of microdata might be to embed content licensing and other details inside pages.
• Yawn. Some of these features have been around in microformats for years and haven’t really taken off, although this could be very important for specialized content with regularly-structured content (cookbooks would be an easy example).

Sadly, HTML5 support (on any of the above) in Internet Explorer (even the unreleased IE9) is woefully incomplete and IE is still the most ubiquitous browser. Look at the number of red Xs in the right-hand columns of this support chart: http://www.findmebyip.com/litmus/

Does the above inspire you to try out some of these new opportunities now that you can pierce some of the HTML5 hype? Please let us know, as we’re actively seeking publishers and authors interested in innovating and experimenting with actual content to develop short- or long-form examples that take avantage of these new possibilities for enthralling, educating, and entertaining readers.

Want to explore in more detail? Both http://html5doctor.com & http://diveintohtml5.org have great details on the state of the above technologies.

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:

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:

• Left/right padding and margins (only when applied too broadly)
• width, mid-width, and max-width (percentage-based more permissible)
• background-image (and friends), which happen to be excluded from the OPS CSS subset
• Inline with the OPS spec, the use of the CSS position property values to achieve absolute positioning (i.e. absolute and fixed) is strongly discouraged.

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.

My idea was that I’d make the viewport as wide as a single column but force at least 2 columns, and let the user swipe or tap to slide the viewport right and left across all the pages. When I implemented it, it appeared to work great. There was just one problem.

WebKit CSS3 columns are actually broken.

The problem is that elements that are flowed into columns don’t report their position properly. They report their position as if they weren’t in the column at all, but instead had just flowed normally.

This is pretty much a deal-breaker if you want to be able to know what text is on the current “page”, for example, to sync your position across devices.

Here’s a test case that exhibits the problem. I’m requesting the horizontal position of an element that falls in the second column. It should report a value that’s greater than the width of the first column. Instead it reports a tiny value, as if that text were actually positioned up against the left margin.

Chrome, Safari, Mobile Safari, Android

Ironically, Firefox, which lags behind WebKit in its HTML5 support, does the correct thing:

You can download the test case here and run it in any browser.

Unfortunately for us, this meant we had to implement pagination entirely in JavaScript. I’ve done this a few times before (such as in the ePub Zen Garden), but that wasn’t with arbitrary HTML. We worked really, really hard to get JS-based pagination to be as accurate and efficient as possible, but it’s still one of the most resource-intensive parts of the app, and a primary reason why it’s not as fast as a native app.

I’ve been told that this bug is fixed in the WebKit source, but since we’re at the mercy of the deployed versions on mobile devices we never further investigated. The moment this fix lands in a consumer browser we’ll switch to supporting it, which should be a huge performance boost.

Update March 8, 2010: Confirmed fixed in WebKit nightly, so eventually this fix should filter down to the mobile browsers.