But while we’re excited to share this news, this article is not merely a press release. The decision of when and how to upgrade to EPUB 3 has been challenging for many in the publishing community, and it has been a long journey for O’Reilly as well. I’d like to talk more about why we chose to take this step now, what additional value we believe EPUB 3 provides to our customers, and the challenges and tradeoffs we’ve tackled in making our EPUBs backward compatible with EPUB 2 platforms.

EPUB 3: Why Now?

It’s been more than a year since the EPUB 3 specification was first approved by the IDPF (it was released in October of 2011). Which begs the question, “Why the one-year delay to adopt EPUB 3?” or less politely, “What took you so long?” The answer is that upgrading to EPUB 3 is not a trivial undertaking, nor is it one that can be reasonably taken unilaterally. To successfully produce and deliver EPUB 3 as part of a ebook program, there are two key prerequisites: having the necessary workflows and tools in place to create EPUB files compliant with the EPUB 3.0 specification, and having ereader platforms available that formally support the 3.0 format. As of early 2012, neither of these preconditions was met, but in the past year, there has been much progress on both fronts. Here are some key milestones:

• December 2011: Azardi launches one of the first desktop readers for EPUB 3
• February 2012: Launch of Readium project, an open source EPUB 3 reader for Google Chrome browser
• October 2012: Apple releases iBooks 3.0, with formal support for EPUB 3 and accompanying documentation
• December 2012: After beta updates throughout the year, Epubcheck 3.0 (validator for EPUB 3 content) is officially released

Over the past year and a half, O’Reilly has sponsored the DocBook project’s development of open source XSL stylesheets for transforming DocBook XML content to EPUB 3, which we’ve used to update our own toolchain to produce EPUB 3 output. With the release of iBooks 3.0 in late 2012, a critical mass of O’Reilly’s readers had devices that supported EPUB 3 content. We felt it was time to upgrade our content to EPUB 3 to provide people using 3.0-compliant platforms the best quality reading experience.

Additionally, we believed it was important to further throw our support behind the latest version of the EPUB standard to encourage vendors to upgrade their ereading platforms to support HTML5 and EPUB 3. Since 2011, there has been a chicken-or-egg attitude that’s pervaded much of the hand-wringing around EPUB 3, where publishers felt justified in holding back from producing EPUB 3 content until there was widespread ereader support, and ereader vendors felt no sense of urgency in adding EPUB 3 support to their products because there was no significant influx of EPUB 3 content from publishers. We’d like to think that by releasing our content in EPUB 3, we’re doing our part to help break this impasse and push the industry forward.

A Look Inside Our New and Improved EPUBs

Under the hood, EPUB 3 ebooks use HTML5 documents to represent the book content, whereas EPUB 2 documents use XHTML 1.1 documents, but this change in HTML version doesn’t inherently translate into a visually perceptible difference in how content is presented onscreen; that’s what CSS is for. The value in the upgrade to HTML5 lies both in the rich semantics it affords for marking up content and the multimedia/interactivity features it enables in ebook content.

Rich semantics in HTML5 and EPUB 3

The HTML5 specification adds a handful of new elements that are especially useful for marking up ebook content in a more semantic fashion. Notable new structural elements include <section>, <aside>, and <figure>, which can be used to tag sections, sidebars/footnotes/endnotes, and photos/illustrations, respectively. This helps decrease the need to rely heavily on <div>s with custom classes to block off content for styling. In addition to the new HTML5 structure elements, EPUB 3 introduces the epub:type attribute, which permits further inflection of HTML5 elements in line with book semantics:

<aside epub:type="sidebar">
<p>Fascinating digression on the history of the Web…</p>
</aside>

epub:type accepts a set of values defined in the EPUB 3 Structural Semantics Vocabulary (and can also accept custom values from other vocabularies through custom prefixes).

Using semantic HTML5 and epub:type inflections is more than just a best-practices exercise or a way to flex your geek cred (“I use <figcaption> and <hgroup> in my EPUBs; how about you?”). Rich tagging is a key component of making EPUB content as accessible as possible to people with visual disabilities or other reading impairments. Screen readers that encounter an <aside> tag can accurately convey to readers that the text within is tangential to the main book flow. But they will not be able to do the same if that same content is tagged as, say, <div class="rectangular_border">.

Ereading platforms are already taking advantage of EPUB 3 rich semantics to add features to their software for readers. As an example, Apple’s iBooks reader now keys special functionality to footnote markers inflected with epub:type="noteref" and corresponding footnote text with epub:type="footnote", and transforms them into pop-up footnotes for the reader. O’Reilly has implemented these semantics in its EPUB 3 files; see the screenshot below for an example from EPUB 3 Best Practices:

Pop-up footnote in iBooks Reader for iPad

Multimedia/Interactivity in HTML5 and EPUB 3

Because EPUB 3 supports the full HTML5 element set, it’s now possible to create fully valid EPUB content that includes <audio>, <video>, and <canvas> content, which opens the door to true interactive, multimedia experiences within ebook content. We’ve already begun to experiment with these possibilities in EPUB 3. Here’s a screenshot from HTML5 for Publishers, featuring a coloring book implemented using SVG and JavaScript:

Interactive SVG+JavaScript coloring book from HTML5 for Publishers

Backward Compatibility with EPUB 2 ereaders

While the iBooks reader fully supports EPUB 3 content, the same cannot be said most of the major EPUB ereaders on the market, and this poses a challenge for publishers. How do you deliver an EPUB 3 experience for iBooks, but also make your content available on EPUB 2 devices like the NOOK or Sony Reader? One option is to produce two versions of your EPUB content: an EPUB 3 version for devices that can support that spec, and an EPUB 2 version for all other platforms. Another choice is to make backward-compatible EPUB 3 files, which are compliant with the 3.0 spec but also meet EPUB 2 requirements and contain the necessary legacy EPUB 2 metadata to be processed and rendered properly on EPUB 2 platforms.

For the ebook bundles we sell on oreilly.com, we have taken the latter approach and are releasing one, backward-compatible EPUB 3 file in our ebook bundles for download,^* rather than offering both an EPUB 2 and an EPUB 3. We believe there’s real value in providing a “universal” file that can be used on all EPUB ereaders, both in terms of keeping things simple for customers (who shouldn’t have to concern themselves with whether their ereader is EPUB 3-compliant or not) and eliminating the hassle inherent in juggling two sets of EPUB files should folks want to load their ebooks to both their iPad and NOOK.

Developing “universal” EPUB 3 files is a more challenging undertaking for publishers, however. If you love working with EPUB metadata, you’re in luck: producing backward-compatible EPUB 3 basically means double the metadata and double the fun. Because the EPUB 3 standard modifies the spec requirements for some key metadata points, you’ll need to provide this metadata twice: once in EPUB 2 format and once in EPUB 3 format. For example, the EPUB 3 spec requires the metadata indicating the ebook cover image to be specified in the OPF file by putting properties="cover-image" on the corresponding manifest <item> like this:

<item id="cover-image" properties="cover-image" href="orm_front_cover.jpg" media-type="image/jpeg"/>

But many EPUB 2 ereaders are expecting the cover image to be specified as follows:

<meta name="cover" content="cover-image"/>

So to ensure that cover thumbnails appear properly on all virtual bookshelves across reading systems, you’ll need to include this metadata both ways.

If you were excited about upgrading to EPUB 3 but were heartbroken by the idea of abandoning the NCX Table of Contents, you’re also in luck, because you’ll need to continue including an NCX file in order to ensure the table of contents renders on EPUB 2 platforms. Since the EPUB 3 specification mandates a Navigation Document including a table of contents tagged in XHTML5 (using <nav> and <ol>/<li> markup), that means you need two separate TOCs in your backward-compatible EPUB 3s.

While embedding this extra legacy EPUB 2 data will ensure that your metadata problems are solved, it won’t address a thornier problem, which is that most EPUB 2 ereaders don’t parse HTML5-specific markup. In other words, if you put a <section> tag in your EPUB file, ereaders like Adobe Digital Editions will just ignore it. This isn’t a catastrophic problem for HTML5 semantic tags like <section> and <aside>, as they don’t carry implicit formatting expectations in the same way that an <ol> does. However, it will introduce problems if you’re implementing cross-references to these HTML5 elements. For example, if you have a <section> as follows:

<section id="important_instructions">
<h2>Very Important Instructions</h2>
<-- And so on... -->

which you then intend to cross-reference later in your ebook like this:

<a href="#important_instructions">Click here to see Very Important Instructions</a>

then you’re in trouble on many EPUB 2 readers, because when they fail to parse <section>, they also fail to parse the id attribute on the tag, which means hyperlinks to it will not work.

To work around this limitation, you may find yourself having to modify the placement of your id attributes (e.g., putting them on the <h2> instead of the <section>) or compromise your semantic tagging (e.g., using <div> instead of <section>), both of which we have done in different circumstances, depending on the results of testing on different EPUB 3 and EPUB 2 readers.

Dealing with multimedia elements like <video> is another area that presents both challenges and tradeoffs. If you’re adding a <video> tag to your markup, the desired behavior is for a corresponding video to be embedded that the reader can watch. But for ereaders that don’t support <video>, you’ll need to provide adequate fallbacks to mitigate the degradation of the experience as much as possible. This may mean providing a poster image in place of the video, or a hyperlink to the same video content on the Web. Here’s an example of a <video> tag that falls back to a hyperlink:

<video id="asteroids_video_mp4" width="480" height="270" controls="controls">
<source src="examples/html5_asteroids.mp4" type="video/mp4"/>
<p><em style="color: red">Sorry, the &lt;video&gt; element is not 
supported in your ereader, so you will not be able to watch this video here.</em> 
If you have Web access, <a href="http://examples.oreilly.com/0636920022473/video/video.html">
click here</a> to try running it in your browser.</p>
</video>

And here’s a side-by-side comparison of how this video element renders on the iBooks reader (which supports embedded <video>), and Adobe Digital Editions 1.8, which does not.

Embedded displayed in the iBooks reader for iPad (left), and video fallback displayed on Adobe Digital Editions (right)

Conclusion

In the past year, we’ve seen much progress in the ebook landscape toward greater adoption of EPUB 3. Yet even so, in 2013 we’re still in the incipient stages of EPUB 3 support, which makes early adoption of the standard a challenge. We hope that the upcoming year will see more widespread adoption of the EPUB 3 standard by publishers and ereader vendors.

^* For now, O’Reilly is continuing to deliver EPUB 2 files to other digital retailers, as many ebook stores will not accept EPUB 3 files for sale, even if these files are backward compatible with EPUB 2 readers.

UPDATE: On a related note, be sure to read this follow-up article from my colleague Nellie McKesson on how we’re working to simplify and eliminate competing visual distractions for readers.

But while 2012 marks a huge leap forward toward the incorporation of modern Web standards into the Kindle platform, there is still much room for improvement in terms of multimedia/interactivity, content rendering, and ease of ebook development. Here is my humble^*** wish list of improvements for the Kindle platform for 2013:

1. Add support for embedded audio/video to Kindle Fire

When KF8 was introduced in early 2012, support for audio/video was not included in the format—even though MP3 audio and MP4 video were already supported in Kindle for iOS. Nearly 12 months later, the Kindle Publisher Guidelines still read, “Currently, only Kindle for IOS [sic] supports audio and/or video content. Kindle e Ink devices and Kindle Fire do not support Kindle Editions with Audio/Video.”

Given that support for streaming multimedia content via Amazon Instant Video is such a highly touted feature of Kindle Fire, it’s rather surprising that Amazon has not been more assiduously pursuing support for embedded multimedia for Kindle Fire ebooks. As a result of this discrepancy—Kindle Fire supports KF8 but not audio/video, and Kindle for iOS supports audio/video but not KF8—there is no single Kindle platform that supports all the ebook features that Amazon offers. Those Kindle readers who opt to buy a Fire over an iPad are penalized by not being able to view embedded video in ebooks, and those who opt to instead read their ebooks on Kindle for iOS are penalized with a lower-quality reading experience, as embedded fonts and many key CSS features will not be supported. This should be rectified ASAP. Here’s hoping that by this time next year, embedded audio/video is supported on every Kindle tablet device, and that KF8 is supported on Kindle for iOS.

2. Add KF8 support for MathML

High-quality typesetting of mathematical equations is a challenge in most digital formats, and Kindle is no exception. Because Kindle’s KF8 format does not support MathML (a XML vocabulary for markup of math content that is part of the HTML5 specification and supported to varying degrees in different desktop and mobile Web browsers), the only viable typesetting option for including complex equations, matrices, etc., in ebooks is to embed the math content as images. However this approach is far from ideal, because when implemented as images, mathematical equations are not searchable or resizable by readers. Optimizing image size can also be challenging. See the Kindle Paperwhite screenshot below featuring two equation images scaled to the same size, which results in the longer equation (bottom) being more heavily “shrunk” than the shorter equation (top).

Two probability equation images rendered on Kindle Paperwhite, the bottom equation “shrunk” more than the top equation

Adding MathML support to KF8 would remove the burden for equation sizing and resolution from publishers and developers, and place it on the ereader’s rendering engine, where it belongs. As Adam Hyde notes in his TOC post on math typesetting, the current state of MathML support in browsers and on the Web is rather woeful, forcing reliance on third-party libraries like MathJAX to correct and normalize rendering. But this presents a huge opportunity for ereader vendors like Amazon. Adding robust MathML support may provide a competitive advantage in the likely-to-grow ebook marketplace for math and science textbooks. iBooks already provides limited MathML support via its WebKit engine; your move Amazon!

3. Add a Monospace Default Font to Kindle Paperwhite

The Kindle Paperwhite ereader contains six system fonts: Baskerville, Caecilia, Caecilia Condensed, Futura, Helvetica, and Palatino. None of these is a monospace font. Monospace fonts are critically important for technical-book publishers, because elements such as code listings and ASCII art must be formatted such that every character is of equal width, in order for them to render properly.

Because Paperwhite supports the KF8 format, Mobi developers can embed their own monospace font if their content requires it (O’Reilly embeds the Ubuntu Mono font family in its Mobis). However, by default, Kindle Paperwhite has Publisher fonts turned off, so readers must navigate to the Kindle font menu themselves and enable the Publisher Font option—which they may not know they need to do. Compare the rendering of the code block below on Kindle Paperwhite with Publisher Fonts turned on (left) and Publisher Fonts turned off (right):

The same code listing displayed on Kindle Paperwhite, with Publisher Fonts turned on (left) and Publisher Fonts turned off (right)

Kindle customers shouldn’t have to be educated to enable Publisher Fonts to ensure monospace content is displayed properly, and publishers shouldn’t be required to embed additional fonts (which bloat Mobi file size) to enable monospace functionality. Ereader vendors should provide a rich set of system fonts, optimized for their rendering engine, that meet the needs of publishers of fiction, technical reference books, or anything in between. Both legacy eInk Kindle devices and the Kindle Fire have monospace system fonts; please extend this support to Paperwhite as well.

4. Add more granularity to @media query support

One of the best CSS features added to KF8 was support for two specific @media queries: @amzn-kf8 and @amzn-mobi. These two queries allow Kindle developers to segregate their CSS so that styling that takes advantage of KF8 features (in an @amzn-kf8 block) is ignored on legacy Mobi7 Kindle ereaders, and fallback styling (in an @amzn-mobi block) will be used instead on the legacy devices.

This @media query support was a boon when Kindle Fire was the only device in the Kindle family that was KF8-enabled, because you could use @amzn-kf8 to specify not only KF8-specific features, but also four-color-specific styling for Fire tablets that would be ignored on the black-and-white devices. However, now that eInk readers like Kindle Paperwhite also support KF8, they also use the CSS specified under @amzn-kf8, which means it is not possible to target CSS for the tablet readers and provide graceful degradation for eInk. See the screenshots below, which show the same syntax-highlighted code example side-by-side on Kindle Fire (left) and Kindle Paperwhite (right).

Rendering of syntax-highlighted code listing on the four-color Kindle Fire tablet (left) and the eInk Kindle Paperwhite (right)

I’d love to see support added for @media queries such as @amzn-kindlefire, @amzn-kindlepaperwhite, and so on, so that Kindle developers are better able to tailor Mobi content to the unique capabilities of each ereader. (This would be an equally welcome feature for other ereader platforms that encompass both eInk and tablet devices—e.g., NOOK, Kobo.)

5. Add a “View Source” option to Kindle Previewer

Kindle Previewer is an excellent emulator that allows you to quickly review how a Mobi file will display on all major Kindle platforms (see screenshot below).

Kindle Previewer for Mac in Paperwhite Mode

But one thing you can’t do in Previewer is inspect the underlying HTML/CSS source code to debug any rendering oddities that may be present. There are tools available, such as mobiunpack, which you can use to crack open a Mobi file and see the source, but they are neither especially convenient nor user-friendly. Having “View Source” functionality built into Kindle Previewer would be a huge timesaver.

What features are on your 2013 Kindle developer wishlist? Hit the comments and share your requests.

^*** I’d love to have put “EPUB 3 support on Kindle” at the top of my wishlist, but sadly I don’t see that being a realistic request.

TOC NY 2013— The publishing industry will gather at the Tools of Change for Publishing Conference in New York City, February 12-14, to explore the forces and solutions that are transforming publishing.Save 15% on registration with the code COMM15

—Andrew Rafferty

Fixed-layout paragraph in iBooks with incorrectly justified last line
Image: Andrew Rafferty; The Stones Remain

A: When you load a standard EPUB file into iBooks, the application automatically paginates the HTML content based on screen size and settings set by the user (font and font size). Content flows from page to page, and if a paragraph spans a page break, text alignment will be consistent on both pages.

Fixed-layout EPUBs differ from standard EPUBs in that it is the ebook designer who sets the pagination of the book, not the iBooks application. Each XHTML document in a fixed-layout EPUB file corresponds to a distinct page in the book, and no content is flowed from one page to the next.

If you want to mimic a text flow from page to page in a fixed-layout EPUB, you’ll need to split the text between two separate HTML documents. This poses a challenge if you want your text to be justified, because the text-align: justify CSS property does not stretch the final line of a paragraph to the full text-column width.

The good news is that CSS3 offers a solution to this very problem: the text-align-last property, which allows you to indicate how the final line of a text block is aligned. text-align-last: justify specifies that the final line should be fully justified, and span the full text column width.

The bad news about this good news is that text-align-last is not yet fully honored across all major Web browsers. It is supported in Mozilla-based browsers (Firefox), but is not supported in the Webkit engine, which powers Safari, Chrome, and—sadly—the iBooks ereader. Neither text-align-last nor the WebKit-specific -webkit-text-align-last, nor the EPUB3-specific -epub-text-align-last will produce the desired effect in the iBooks reader.

But some more good news for the intrepid and patient is there’s a hack-y HTML/CSS workaround that can achieve the effect of text-align-last: justify in iBooks (your mileage may vary on other ereader platforms).

Tweak word spacing using CSS

The old-school (dating all the way back to CSS1) word-spacing property allows you to designate a specific amount of space to place in between words. The following example uses word-spacing: 7px to specify that the last seven words on the page should have seven pixels of whitespace between them:

<p>Everywhere there are mysteries. And the most ancient man-made wonders
of all are the stone monuments erected by our Neolithic and Early 
bronze Age ancestors between 4000 and 1500BC - or, if it is less difficult 
to visualize in this way, between 140 and 240 generations ago. Little 
England (and smaller Scotland and Wales) are rich in these megalithic 
structures. Archaeologists tell us that more than a thousand chambered 
tombs and some 700 stone circles have resisted the 
smoothing iron of wind and rain, the teeth of the plough, the 
<span style="word-spacing: 7px">grasping hands of wave 
upon wave of</span></p>

And here’s a screenshot illustrating how this text renders in iBooks.

Last line correctly justified in iBooks with word-spacing property
Image: Andrew Rafferty; The Stones Remain

The main benefit of this approach is that it gives you fine-grained control over the whitespace in a paragraph. The downside is that it can require a fair amount of trial and error to determine the proper word-spacing values to achieve the desired justification effect. If you do decide to use this method, and have a paid iTunes Connect ebooks account, I highly recommend using Apple’s Book Proofer tool, as it eliminates much of the hassle involved in syncing EPUB files between your computer and your iPad/iPhone/iPod.

Doing animations on the HTML5 Canvas is cool, but what’s even cooler is letting the user draw on the Canvas herself. With the advent of
touchscreen phones, tablets, and ereaders, this becomes even more
compelling, as the user can draw directly on the screen with her finger,
rather than using a mouse or trackpad. In this section, we’ll look at how
to implement a simple “finger painting” app in the Canvas, which would be
a nice fit for a children’s ebook—for example, a story that lets kids draw
their own illustrations to accompany the text, or a preschool textbook
that uses the finger painting to teach colors and shapes.

Here’s the HTML we’ll use to construct the Finger Painting page; the
<canvas> tag which will hold the drawing area is
highlighted in bold:

<!doctype html>
<html lang="en">
<head>
<title>Finger Painting</title>
<script src="modernizr-1.6.min.js"></script>
<script src="finger_painting.js"></script>
</head>
<body>
<div>
<canvas id="canvas" width="500" height="500">
 Your browser does not support the HTML 5 Canvas.
</canvas>
</div>
<div>
<h1>Finger Painting</h1>
<p>Click/tap a color below to select a color, and then drag/swipe on the
  canvas above to draw a picture.</p>
<p>Color selected: <span id="color_chosen">Black</span></p>
<p>
<input type="button" id="Red" style="background-color: red; width: 25px;
height: 25px;"/>
<input type="button" id="Orange" style="background-color: orange; width: 25px;
height: 25px;"/>
<input type="button" id="Yellow" style="background-color: yellow; width: 25px;
height: 25px;"/>
<input type="button" id="Green" style="background-color: green; width: 25px;
height: 25px;"/>
<input type="button" id="Blue" style="background-color: blue; width: 25px;
height: 25px;"/>
<input type="button" id="Purple" style="background-color: purple; width: 25px;
height: 25px;"/>
<input type="button" id="Brown" style="background-color: brown; width: 25px;
height: 25px;"/>
<input type="button" id="Black" style="background-color: black; width: 25px;
height: 25px;"/>
<input type="button" id="White" style="background-color: white; width: 25px;
height: 25px;"/>
</p>
<p><input type="button" id="reset_image" value="Reset Drawing"/></p>
</div>
</body>
</html>

Note that the color palette below the Canvas has been implemented
using <input> buttons, which are styled with CSS
to be the appropriate color and size. The image below displays the page in Chrome for
Mac.

Finger painting interface in Google Chrome (click to enlarge).

In order for the user to be able to draw on the screen, we’ll need
to be able to track his cursor motions and clicks within the Canvas. We
can do so by adding event listeners to the <canvas> element as follows:

theCanvas.addEventListener('mousedown', mouse_pressed_down, false);
theCanvas.addEventListener('mousemove', mouse_moved, false);
theCanvas.addEventListener('mouseup', mouse_released, false);

Now when a user presses down on the mouse within the
<canvas>, a mousemove event is
triggered in the browser, and our event listener calls the
mouse_pressed_down function. Similarly, when the mouse
is moved within the dimensions of the Canvas, the
mouse_moved function is called, and when the mouse
button is released, the mouse_released function is
called. Let’s take a look at these three functions:

    function mouse_pressed_down (ev) {
    begin_drawing = true;
    context.fillStyle = colorChosen.innerHTML;
}

function mouse_moved (ev) {
    var x, y;
    // Get the mouse position in the canvas
    x = ev.pageX;
    y = ev.pageY;

    if (begin_drawing) {
        context.beginPath();
        context.arc(x, y, 7, (Math.PI/180)*0, (Math.PI/180)*360, false);
        context.fill();
        context.closePath();
    }
}

function mouse_released (ev) {
   begin_drawing = false;
}

The mouse_pressed_down function serves to “turn
on” a drawing event on the canvas. It sets the variable
begin_drawing to true, and then sets
the fill color to be used to the current color selected from the color
palette.

Then when the mouse_moved function is called
(which occurs any time the mouse is moved somewhere within the Canvas), we
get the cursor’s coordinates using the
pageX/pageY properties. We check if
the begin_drawing variable is set to
true, which means that the user has the mouse button
pressed down, and if so, we draw a circle of the designated color with a
radius of 7 pixels at the cursor location.

As long as the mouse button is held down while the mouse is moved
over the Canvas, the mouse_moved function will be
called every single time the cursor location changes, which means that
circles will continue to be drawn as the mouse moves, resulting in an
effect quite similar to the Paintbrush tool in many image-editing
applications.

When the mouse button is released, the
begin_drawing variable is set back to
false, which “turns off” the drawing event. This
ensures that drawing occurs only when the mouse is held down, and not when
the mouse is moved over the Canvas without the button being
pressed.

The above code works great on desktop and laptop browsers, where a
mouse is used to interface with screen elements, but what about
touchscreen devices like the iPad? In general, touchscreen browsers do not
support
mousedown/mousemove/mouseup
events, as there is no mouse button or mouse cursor that they can track;
all those features are replaced with finger taps and swipes. However,
WebKit-based browsers support
a corresponding set of events for tracking finger motions in the browser:
touchstart/touchend/touchmove.
So we can implement the same drawing functionality as above using a
touchmove event listener:

theCanvas.addEventListener('touchmove', touch_move_gesture, false);

And the following touch_move_gesture
function:

function touch_move_gesture (ev) {
    // For touchscreen browsers/readers that support touchmove
    var x, y;
    context.beginPath();
    context.fillStyle = colorChosen.innerHTML;
    if(ev.touches.length == 1){
        var touch = ev.touches[0];
        x = touch.pageX;
        y = touch.pageY;
        context.arc(x, y, 7, (Math.PI/180)*0, (Math.PI/180)*360, false);
        context.fill();
    }
}

(Note: The touchmove handling for touchscreen devices
is actually much simpler than the mouse-based version, because we don’t
even need to track touchstart and
touchend events. When dealing with a mouse, we need
to keep track of whether the mouse button is pressed or not when it’s
being moved on the canvas. In the touch version, we know that if the
touchmove event has been triggered, the user has his
finger on the screen and is intending to draw.)

And that’s the meat of the finger painting code. All that’s left is
the code to initialize the event listeners, track color palette
selections, and implement the Reset Drawing button functionality. The example below shows the full JavaScript code for our
finger painting application. (The finger painting JavaScript code can be downloaded here.)

window.addEventListener('load', eventWindowLoaded, false);
function eventWindowLoaded() {
    canvasApp();
}

function canvasSupport () {
    return Modernizr.canvas;
}


function canvasApp(){
    if (!canvasSupport()) {
        return;
    }else{
        var theCanvas = document.getElementById('canvas');
        var context = theCanvas.getContext('2d');
        var redButton = document.getElementById("Red");
        var orangeButton = document.getElementById("Orange");
        var yellowButton = document.getElementById("Yellow");
        var greenButton = document.getElementById("Green");
        var blueButton = document.getElementById("Blue");
        var purpleButton = document.getElementById("Purple");
        var brownButton = document.getElementById("Brown");
        var blackButton = document.getElementById("Black");
        var whiteButton = document.getElementById("White");
        var colorChosen = document.getElementById("color_chosen");
        var resetButton = document.getElementById("reset_image");
        redButton.addEventListener('click', colorPressed, false);
        orangeButton.addEventListener('click', colorPressed, false);
        yellowButton.addEventListener('click', colorPressed, false);
        greenButton.addEventListener('click', colorPressed, false);
        blueButton.addEventListener('click', colorPressed, false);
        purpleButton.addEventListener('click', colorPressed, false);
        brownButton.addEventListener('click', colorPressed, false);
        blackButton.addEventListener('click', colorPressed, false);
        whiteButton.addEventListener('click', colorPressed, false);
        resetButton.addEventListener('click', resetPressed, false);
        drawScreen();
    }

    function drawScreen() {
        theCanvas.addEventListener('mousedown', mouse_pressed_down, false);
        theCanvas.addEventListener('mousemove', mouse_moved, false);
        theCanvas.addEventListener('mouseup', mouse_released, false);
        theCanvas.addEventListener('touchmove', touch_move_gesture, false);
        context.fillStyle = 'white';
        context.fillRect(0, 0, theCanvas.width, theCanvas.height);
        context.strokeStyle = '#000000';
        context.strokeRect(1,  1, theCanvas.width-2, theCanvas.height-2);
    }

    // For the mouse_moved event handler.
    var begin_drawing = false;

    function mouse_pressed_down (ev) {
        begin_drawing = true;
        context.fillStyle = colorChosen.innerHTML;
    }

    function mouse_moved (ev) {
        var x, y;
        // Get the mouse position in the canvas
        x = ev.pageX;
        y = ev.pageY;

        if (begin_drawing) {
            context.beginPath();
            context.arc(x, y, 7, (Math.PI/180)*0, (Math.PI/180)*360, false);
            context.fill();
            context.closePath();
        }
    }

    function mouse_released (ev) {
        begin_drawing = false;
    }

    function touch_move_gesture (ev) {
        // For touchscreen browsers/readers that support touchmove
        var x, y;
        context.beginPath();
        context.fillStyle = colorChosen.innerHTML;
        if(ev.touches.length == 1){
            var touch = ev.touches[0];
            x = touch.pageX;
            y = touch.pageY;
            context.arc(x, y, 7, (Math.PI/180)*0, (Math.PI/180)*360, false);
            context.fill();
        }
    }

    function colorPressed(e) {
        var color_button_selected = e.target;
        var color_id = color_button_selected.getAttribute('id');
        colorChosen.innerHTML = color_id;
    }

    function resetPressed(e) {
        theCanvas.width = theCanvas.width; // Reset grid
        drawScreen();
    }
}

You can experiment with the Finger Painting app on examples.oreilly.com. The image below shows a completed drawing in the Finger Painting app in the iBooks reader for iPad.

Pretty cool, right? Although maybe not as impressive as what you can do in some other touchscreen finger painting apps.

HTML5 for Publishers — This free ebook provides an overview of some of the most exciting features HTML5 provides to ebook content creators — audio/video, geolocation, and the Canvas — and shows how to put them in action.

Related:

• HTML5 for publishers (free ebook)
• What is HTML5?