"Philip Jägenstedt" <[email protected]> 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 [email protected] http://hsivonen.iki.fi/
