On Sun, 29 Nov 2009 06:21:45 +0100, Silvia Pfeiffer
<[email protected]> 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 <[email protected]>
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
