- From: Maciej Stachowiak <mjs@apple.com>
- Date: Wed, 21 Jul 2010 02:06:03 -0700
- To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Cc: Ian Hickson <ian@hixie.ch>, Philippe Le Hegaret <plh@w3.org>, Philip Jägenstedt <philipj@opera.com>, public-html-a11y@w3.org
On Jul 21, 2010, at 1:57 AM, Silvia Pfeiffer wrote: > On Tue, Jul 20, 2010 at 6:07 PM, Ian Hickson <ian@hixie.ch> wrote: >> On Mon, 19 Jul 2010, Maciej Stachowiak wrote: >>>> >>>> But youtube, for example, does have annotations with hyperlinks in >>>> them. They're not captions, but they're still timed text content that >>>> contain hyperlinks. >>> >>> Do we need YouTube-style annotation to be a built-in feature of the >>> <video> element? Or would it be sufficient to make the <video> element >>> capable enough that YouTube or other sites could build similar features >>> themselves out of the primitives provided >> >> Indeed it seems unlikely that YouTube would want to use a built-in >> feature for the presentational aspects of this, since doing so would limit >> what they could do in the future to whatever we supported in the spec. >> This is the kind of things for which I think it would make more sense to >> provide hooks to allow Web page authors to do whatever they want with the >> <video> timing model merely being used as infrastructure. > > > I would agree with this statement if we restricted what is possible in > a caption cue. However, I don't see a need for this. If we, instead, > simply allow what is possible in a HTML div, I don't see this as an > issue - it would not limit what can be done in a cue and it would be > easy to implement by browsers since it would just be parsed as > innerHTML, for which all parsing functionality is already available. Would you suggest allowing literally everything, including scripts and inline event handlers? If so, then we have a challenging security design problem to overcome. If not, then we likely can't actually handle all advanced use cases. I still think a wise for advanced use cases like YouTube annotations is to expose enough primitives to let such features be built in JavaScript on the client side. This has the following benefits: - Reduces the complexity of what we have to spec, thereby increasing the likelihood that HTML5 will get done in a reasonable time frame. - Doesn't make too many assumptions about what clients with advanced or rare uses cases will need, until after we have had a chance to see those features built. If you assume too much about what clients need, you run the risk of building functionality that will not be wanted in practice. - Doesn't force UAs to implement significant additional complexity to handle edge cases. I suggest that it would be useful to go over the requirements document and classify which requirements need to be served by built-in features of the media elements, and which could be served for now just by exposing the right primitives (such as hooks into the timing model, or the ability to have a "metadata" track that lets the Web app do all the processing.) Regards, Maciej
Received on Wednesday, 21 July 2010 09:06:37 UTC