Posted on by matt.garrish

EPUB 3.1 Update

The first editor’s draft of EPUB 3.1 was released last weekend, so it seemed like a good time to add a quick post on what is changing.

The revision so far has been about scaling back features and aligning with the web, so despite a lot of working going into the new drafts, there’s not a lot in the way of drastic changes. EPUB is going through a phase of better integration that will allow epub and html and reading systems and browsers to live together in better harmony moving forward.

The sixty-second recap of what’s happening goes something like this:

  • The really big exciting news is that the HTML syntax of HTML5 is now supported
  • CSS and scripting support have been clarified
  • EPUB extensions to HTML are being dropped:
    • content switching (epub:switch) is gone
    • declarative media playback (epub:trigger) is gone
    • scripted fallback documents for the object tag (bindings) is gone
  • A bunch of EPUB 2 compatibility features are being tossed:
    • the ncx, the EPUB 2 table of contents, is gone
    • the old EPUB 2 meta tag is gone (allowed an epub 2 cover to be identified)
    • the deprecated guide element has shuffled off this mortal coil

There’s a whole lot of other little things, too, of course: the core metadata in the package document is changing, some more font types are being added as core media types, and, near and dear to my heart, the specifications have undergone some significant reorganization, including the addition of a top-level EPUB 3.1 spec that is the new entry point. There are also a number of changes to come.

The key thing to note at this point is that none of these changes are final. The point of putting out an editor’s draft instead of a formal draft specification is to gauge community reaction to these changes.

If you want more detail about the proposed changes so far, jump on over to the EPUB 3.1 Changes from EPUB 3.0.1 document. You’ll also find links there to where you can provide feedback.

15 Replies to “EPUB 3.1 Update”

    1. Mostly unchanged. The required support as a linking mechanism in content documents is being dropped, but we’ve found no real evidence that authors were using it for linking between documents. The typical practice is to link to IDs, which is what the web supports.

      It’ll remain for internal reading system use and where interoperable referencing is required (e.g., the open annotation spec).

      Reply

      1. We don’t need to do anything to allow. As stated in the Content Documents spec:

        The [HTML5] track element is exempt from the Core Media Type usage rule [EPUB31]: Foreign Resources may be referenced from track without the provision of a Core Media Type fallback.

        If you’re getting an error from epubcheck, it needs to be reported there.

        Reply

        3. Hi Matt – Can you please clarify what ePub 3.1 spec has to say about the following: if (or ) element in some content document has a subelement and both media and track are located somewhere remotely, should track data item be included in the manifest at all? Thank you!

          Reply

          1. Just editing what has been eaten by your blog posting script:

            Hi Matt, Can you please clarify what ePub 3.1 spec has to say about the following: if < video > or < audio > element in some content document has a subelement < track > and both media and track are located somewhere remotely, should track data item be included in the manifest at all? Thank you very much!

          2. Technically the track element can’t be hosted remotely, only the audio or video. The only exemption for track is that it doesn’t have to reference a core media type.

            But even if it were allowed remotely, it would still have to be listed. Audio and video files (and as of 3.1 fonts and remote resources fetched by scripts) are included in the manifest with the full URL to them in the item’s href attribute.

    2. It’s looking like MP4/H.264 is widely supported enough now that it could be considered a core media type, but it’s a thorny issue to have a patent-encumbered CMT. I’ve noted the lack of a CMT again in an issue about clarifying what we mean by fallbacks, but I can’t say if there will be a resolution in this revision or not.

      Reply

Leave a Reply

Your email address will not be published. Required fields are marked *