On Fri, Apr 16, 2010 at 8:36 PM, Henri Sivonen <hsivo...@iki.fi> wrote: > "Philip Jägenstedt" <phil...@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.
I think we are actually talking about two different things here. In my mind timed innerHTML is the right way in which to render a text cue into HTML. I don't think it needs any new elements - it simply is a HTML snippet that only exists while the cue is active. In contrast, "TDHT" is an actual storage format for such cues. It does require a "new" element which captures the start and end time (could be an extension of an existing one, but that would indeed be more confusing). When that file is parsed, the cues are place into the timed innerHTML segments. Cheers, Silvia.
