W3C home > Mailing lists > Public > whatwg@whatwg.org > April 2010

[whatwg] Introduction of media accessibility features

From: Henri Sivonen <hsivonen@iki.fi>
Date: Fri, 16 Apr 2010 03:36:37 -0700 (PDT)
Message-ID: <34602187.9140.1271414197437.JavaMail.root@cm-mail03.mozilla.org>
"Philip J?genstedt" <philipj at opera.com> wrote:

> I actually quite like the general idea behind Silvia's  
> http://wiki.xiph.org/Timed_Divs_HTML
...
> <!doctype html>
> ...
> <timerange start="1" end="2">Hello</timerange>
> <timerange start="10" end="12">The End</timerange>
> ...
> 
> The default stylesheet would be something like this:
> 
> :before-timerange, :after-timerange {
>    display: none;
> }
> :in-timerange {
>    display: block;
> }

> Cons:
>   - Politics.
>   - New format for subtitle authors and tools.
>   - Not usable outside the web platform (i.e. outside of web
> browsers).
>   - <timerange> is a bit verbose, but that can be changed to whatever
> we  
> want.

Cons compared to timed innerHTML setting:
 - The DOM for all the captions for the entire video has to stay in RAM to be able to reuse existing DOM and CSS formatter code.
 - Since the DOM for the all captions is present and a pseudo-class changes, the same solution wouldn't work nicely when timed text is multiplexed into a long seekable video file. (Timed innerHTML setting would work nicely even if the HTML fragments were delivered as packets (granules?) inside Ogg instead of using a .srt-like container.) I think this is the most notable point in favor of timed innerHTML compared to time-sensitive CSS pseudo-classes.
 - Requires new time-sensitive pseudo-classes. (Probably not a big deal.)
 - Introduces a new HTML element that doesn't make sense in general-purpose HTML.
 - Need to define processing for timerange elements that aren't children of body and potentially other unexpected uses of timerange.

Pros compared to timed innerHTML setting:
 - The HTML parsing algorithm runs only once.
 - Reformatting layout after a pseudoclass change is likely to be slightly faster than running the HTML fragment parsing algorithm and replacing a DOM subtree, too.
 - No need to define an .srt-like container format.

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/
Received on Friday, 16 April 2010 03:36:37 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:22 UTC