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.

Back in 1974, when the Internet was a fraction of what it is now, the acorn to an oak, there were really only two applications,” said Shirky, “Telnet, and FTP.”

Surely he’s wrong, I thought.  Those protocols aren’t that old.

But I was wrong. FTP was invented in 1971, and telnet was developed in 1969.

(Telnet is a way to connect interactively with another computer. In practice it’s been replaced by the more secure ssh, but vestigial copies remain on all modern computers.)

What really threw me wasn’t that telnet was from 1969 as much as that it was RFC 15.  In the networked world, Requests for Comments are documents which define the standards that computers use when communicating with each other.  To understand how old RFC 15 is, consider that the venerable FTP is RFC 114,  while email as we know it is RFC 821 (1982), and HTTP is RFC 1945 (1996, although obviously it had been in use for years). The most recent RFC is 5382. RFC 15 is ancient history.

Because I am a nerd I spent some time browsing the early RFCs, and I was struck by how charmingly antique they are. RFC 16 says that M.I.T. should receive copies of RFCs. RFC 6 begins, “I talked with Bob Kahn at BB&N yesterday.” RFC 14 never existed.

RFC 7 (“Host-IMP Interface”) includes a prefatory note:

The original of RFC 7 was hand-written, and only partially illegible [sic]
copies exist.

Indeed, the actual RFC begins:

This paper is concerned with the preliminary software design of the
Host IMP interface. Its main purpose is on the one hand to define
functions that will be implemented, and on the other hand to provide
a base for discussions and …(unreadable).

I’m on the mailing list for users of the Text Encoding Initiative (TEI), an XML schema used primarily for encoding historical texts. The schema is equipped with tags for tracking everything about a document, including changes that occur over centuries of time. On the TEI list, people ask questions like, “How do I represent a medieval manuscript and also indicate which passages were underlined by an 18th century owner?” or “What tag should I use for a poem title that was handwritten vertically in the left margin?” (Promptly followed by vigorous scholarly debates over the “correct” answers.)

There’s something charming about how early internet history, just 40 years old, is almost as poorly documented and in need of careful archivists.

To expand the project in useful ways I’d like to be able to add:

1. Other content types besides novels, especially reference
2. Content from other document formats, such as DocBook
3. Native, highly-tagged TEI documents

Wikipedia and its cohorts are by far the largest source of public domain data on the web now, but they aren’t encoded in XML. Publishers are unlikely to use wiki formatting to mark up their content and thus developing a workflow to convert from wiki to TEI doesn’t seem productive.

XML data welcome!

Tale was challenging because of the way the “books” were organized (they’re called parts in threepress).  This book exposed a bug in the way I was handling chapter ordering, which I’ve fixed.

Cask is my only content with no chapters, as it’s a short story.  I could make that more transparent to the user than the current implementation (right now content is assigned to a pseudo-chapter called “Complete story”), but whether I do that will depend on which is the outlying case: books or single-chaptered works.  Right now it’s mostly books, so that feels like the natural way to organize the site.