Friday, October 24th, 2008

This Week in HTML 5: Offline and Video

Category: HTML

<p>Hot off the presses is a fresh “What’s Week in HTML 5″, Episode 10, post from Mark Pilgrim:

The big news this week is offline caching. This has been in HTML 5 for a while, but this week Ian Hickson caught up with his email and integrated all outstanding feedback. He summarizes the changes:

  • Made the online whitelist be prefix-based instead of exact match. [r2337]
  • Removed opportunistic caching, leaving only the fallback behavior part. [r2338]
  • Made fallback URLs be prefix-based instead of only path-prefix based (we no longer ignore the query component). [r2343]
  • Made application caches scoped to their browsing context, and allowed iframes to start new scopes. By default the contents of an iframe are part of the appcache of the parent, but if you declare a manifest, you get your own cache. [r2344]
  • Made fallback pages have to be same-origin (security fix). [r2342]
  • Made the whole model treat redirects as errors to be more resilient in the face of captive portals when offline (it’s unclear what else would actually be useful and safe behavior anyway). [r2339]
  • Fixed a bunch of race conditions by redefining how application caches are created in the first place. [r2346]
  • Made 404 and 410 responses for application caches blow away the application cache. [r2348]
  • Made checking and downloading events fire on ApplicationCache objects that join an update process midway. [r2353]
  • Made the update algorithm check the manifest at the start and at the end and fail if the manifest changed in any way. [r2350]
  • Made errors on master and dynamic entries in the cache get handled in a non-fatal manner (and made 404 and 410 remove the entry). [r2348]
  • Changed the API from .length and .item() to .items and .hasItem(). [r2352]

Mr. Pilgrim then waxes poetic on video formats (see the original post for details), then details the new navigator.canPlayType() method:

r2332 adds a navigator.canPlayType() method. This is intended for scripts to query whether the client can play a certain type of video. There are two major problems with this: first, MIME types are not specific enough, as they will only describe the video container. Learning that the client “can play” MP4 files is useless without knowing what video codecs it supports inside the container, not to mention what profiles of that video codec it supports. The second problem is that, unless the browser itself ships with support for specific video and audio codecs (as Firefox 3.1 will do with Ogg Theora and Ogg Vorbis), it will need to rely on some multimedia library provided by the underlying operating system. Windows has DirectShow, Mac OS X has QuickTime, but neither of these libraries can actually tell you whether a codec is supported. The best you can do is try to play the video and notice if it fails. [WHATWG thread]

Mark then delves into the sticky area of video accessibility and HTML 5:

  • Ian Hickson kicked off another round of video accessibility discussion, with this philosophical statement:
    Fundamentally, I consider <video> and <audio> to be simply windows onto pre-existing content, much like <iframe>, but for media data instead of for “pages” or document data. Just as with <iframe>s, the principle I had in mind is that it should make sense for the user to take the content of the element and view it independent of its hosting page. You should be able to save the remote file locally and open it in a media player and you should be able to write a new page with a different media player interface, without losing any key aspect of the media. In particular, any accessibility features must not be lost when doing this. For example, if the video has subtitles or PiP hand language signing, or multiple audio tracks, or a transcript, or lyrics, or metadata, _all_ of this data should survive even if the video file is saved locally without the embedding page.

    In other words, video accessibility should be handled within the video container, not in the surrounding HTML markup. On the plus side, all modern video containers can handle subtitle tracks, secondary audio tracks, and so forth. Unfortunately, authors may be hesitant to add to their bandwidth costs by including tracks that must be downloaded by everyone but appreciated (or even noticed) by very few.

    [W3C discussion thread on video accessibility]

But wait, there’s more! There’s actually a bunch of more interesting new developments that Mark details for HTML 5, but you’ll have to click over to his post to see the rest.

Posted by Brad Neuberg at 6:00 am
Comment here

+++--
3.6 rating from 8 votes

Comments Here »

Comments feed TrackBack URI

Leave a comment

You must be logged in to post a comment.