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

[whatwg] Introduction of media accessibility features

From: Richard Watts <rrw@kynesim.co.uk>
Date: Fri, 16 Apr 2010 13:08:25 +0100
Message-ID: <4BC85339.4030400@kynesim.co.uk>
Henri Sivonen wrote:
> "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.

  Apologies for jumping in - the thread got rather long and I'm horribly
busy so haven't had time to read all of it - but the consensus in
broadcast (OCAP, HbbTV, DVB) is that the Right Way to do this is
to fire Javascript events from events in the input stream - one of
them being timecode, so something like:

  video.request_events(video.EVENT_TYPE_TIMED, { from: 10.0, to: 20.0},
    myfunc)

  And myfunc then gets called whenever you go into or out of that time
range. Obviously there's horribleness around the edges for requesting
periodic events, etc.

  This should let you write your SRT viewer in Javascript, should you
feel that way perverted^Winclined.

  This has the major advantage that it copes with trickplay naturally
and synchronises video or animation startup with DOM manipulation;
it's not otherwise obvious what the timebase for dynamically generated
DIVs would be (it's actually not obvious whether the event above
should fire if you start it in 10.0 to 20.0, and it's far from obvious
when that is in any sort of stream anyway, but at least you can be
consistently confused).

  Another advantage of having callback events fired into the DOM is
that it makes it possible to build interactive TV apps triggered by
metadata tables or user-defined blocks in the incoming stream. The
alternatives for synchronising e.g. HTML ads to product placement in
video streams in the presence of trickplay are truly horrid.



R
Received on Friday, 16 April 2010 05:08:25 UTC

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