[whatwg] <video><overlay> for captions/subtitles/etc

[Philip Jägenstedt]

On Sun, 29 Nov 2009 06:21:45 +0100, Silvia Pfeiffer  
<silviapfeiffer1 at gmail.com> wrote:

> Philip,
>
> It's great to see further specifications come up around captions. I do
> think we need these to make progress and come to a specification that
> we can all agree on.
>
> I just wanted to add a comment on your wiki page for clarification:
>
> My <itext> wasn't supposed to stay a JavaScript implementation. In
> fact, it had the exact same purpose as your <ovelay> proposal: to
> eventually be added into the HTML5 specification and be properly
> integrated, such that it didn't have to rely on the timeupdate.
> In fact, the <itextlist>/<itext> proposal, which was my second
> improvement, see
> https://wiki.mozilla.org/Accessibility/HTML5_captions_v2, doesn't look
> very different to what you have there.
>

Yes, that is very clear, I used it only as an example of what needs to be  
done to parse SRT with JavaScript. Go ahead and edit the wiki if there's  
anything that makes it sounds like <itext> is something it is not.

> I think you've taken the next step with proposing to add a wrapping
> <div> into the DOM - something I wasn't quite sure would be possible
> and I'm glad you've taken the step.
>
> Another comment on naming: whether we name the elements <itextlist>
> and <itext> or alternatively <overlay> and <source>, I'm not too
> fussed. In fact, I've discussed the renaming/reuse of <source> for
> <itext> in my recent blog post at
> http://blog.gingertech.net/2009/11/25/manifests-exposing-structure-of-a-composite-media-resource/
> . I think it may well make a lot of sense since we can reduce the key
> required attributes to the ones that already exist for the <source>
> element.
>

Indeed, my proposal is mainly a remix of <itext> and cue ranges. The main  
selling point, though, is a consistent markup and DOM for in-band,  
external and script-created subtitles and a hook to content into the  
fullscreen mode.

> I am a little hesitant about the user of "overlay": it is a name that
> implies a visual representation. I don't think we should prescribe how
> the <div> needs to be represented. In fact, for a textual audio
> description, I would prefer not to have a screen display and only have
> the screen reader aria-live activated. That is not a overlay any
> longer. I think in the past HTML has tried to separate structure from
> presentation where possible, with CSS being in control of presentation
> issues.
>

The name issue and using CSS is one track in the discussion on  
public-html-a11y, please do follow up on that.

> Anyway - I am sorry I haven't had the time to reply properly to the
> discussion in the W3C HTML accessibility taskforce yet - I promise
> I'll get to it.
>
> Incidentally, I think the W3C HTML accessibility taskforce has
> developed into something of a discussion centre for these captions
> issues. If you're a HTML5 member, you might want to join the taskforce
> and subscribe to http://lists.w3.org/Archives/Public/public-html-a11y/
> . Otherwise, I guess, we'll end up duplicating all the discussion
> there here again.
>

I assume "you" above is other WHATWG members, not me.

>
> On Sun, Nov 29, 2009 at 1:44 AM, Philip Jägenstedt <philipj at opera.com>  
> wrote:
>> As part of the work in the W3C HTML Accessibility Task Force I have  
>> proposed
>> a new <overlay> element to handle several use cases which are currently  
>> not
>> solved by HTML5 <video>.
>>
>> http://wiki.whatwg.org/wiki/Video_Overlay
>>
>> Certainly we shouldn't be adding this to HTML5 at this point, but I  
>> think
>> HTML6 and beyond is something the WHATWG should be involved with.
>>
>> --
>> Philip Jägenstedt
>> Core Developer
>> Opera Software
>>
>


-- 
Philip Jägenstedt
Core Developer
Opera Software