On Wed, 25 Nov 2009 22:49:40 +0100, Eric Carlson <eric.carlson@apple.com>
wrote:
>
> On Nov 25, 2009, at 12:02 PM, Philip Jägenstedt wrote:
>
>> On Wed, 25 Nov 2009 18:43:39 +0100, Eric Carlson <eric.carlson@apple.com
>> > wrote:
>>
>>>
>>> I think <overlay> should be used for internal subtitle and/or closed
>>> caption tracks as well. Further, I think that we will want them to
>>> "just work" so a UA should create an <overlay> element if the markup
>>> doesn't have one and it finds that a file has internal
>>> captions/subtitles:
>>>
>>> <video src='my-captioned-movie'> </video>
>>>
>>
>> Yes, that sounds good. One issue is how to style such an implicit
>> <overlay>. Should one actually include an <overlay> in the markup and
>> somehow indicate that it can/should be used to render in-band subtitles
>> from the resource?
>>
>> <video src="my-captioned-movie">
>> <caption style="font-weight:bold" magic-attribute></caption>
>> </video>
>>
>> Not awesome. Perhaps a new CSS pseudo-selector could be used? Other
>> ideas?
>>
> Actually I was imagining that *all* subtitles and captions, in-band
> and external alike, would be rendered into an <overlay>. If the markup
> doesn't includes an <overlay> element the UA would actually insert one
> into the DOM, as is done now for other missing elements (eg. tbody,
> etc). This way the default style could be specified in the user agent
> style sheet and the author could override as they wish.
>
Right, all subtitles/captions should be rendered in <overlay> regardless
of origin. If the parser automatically inserts an <overlay> element when
there is none, what about the case where there is an <overlay> used to
show custom controls? I imagined the need for a magic attribute/CSS
selector/something to point out the correct <overlay> in cases like this.
Possibly a magic src attribute? In any case, these are small issues that
I'm sure could be sorted out if <overlay> is implemented.
> Speaking of author overrides, another issue we need to deal with is
> authors that wish to handle captions themselves. Posting an event when a
> new caption needs to be displayed seems logical enough, but how do we
> provide access to the caption data in JavaScript?
>
Here I think we should do something similar to cue ranges as has been
discussed before in various places. A new event type would allow us to add
some data, e.g.
interface CueRangeEvent : Event {
readonly attribute double startTime;
readonly attribute double endTime;
readonly attribute DOMString text;
};
We would need to bring back addCueRange with some modifications.
v.addCueRange(10 /* start */, 12 /* end */, "Hello");
v.addEventListener('cuerangeenter', function(e) {
e.target.querySelector('overlay').textContent = e.text; }, false);
v.addEventListener('cuerangeleave', function(e) {
e.target.querySelector('overlay').textContent = ''; }, false);
You get the idea even if the above doesn't have the perfect
interface/method/event names. Something along these lines should make it
possible to handle in-band, external and script-created captions in a
quite uniform fashion, as well as provide for whatever use cases the old
cue range API had.
--
Philip Jägenstedt
Core Developer
Opera Software