Re: Media--Technical Implications of Our User Requirements

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