W3C home > Mailing lists > Public > public-html-a11y@w3.org > July 2010

Re: Media--Technical Implications of Our User Requirements

From: Maciej Stachowiak <mjs@apple.com>
Date: Wed, 21 Jul 2010 02:06:03 -0700
Cc: Ian Hickson <ian@hixie.ch>, Philippe Le Hegaret <plh@w3.org>, Philip Jägenstedt <philipj@opera.com>, public-html-a11y@w3.org
Message-id: <8068322F-92B9-47AE-B381-A17899B69207@apple.com>
To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>

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.)

Received on Wednesday, 21 July 2010 09:06:37 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:05:12 UTC