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

Re: Media--Technical Implications of Our User Requirements

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Wed, 21 Jul 2010 21:28:50 +1200
Message-ID: <AANLkTimVVMv7wQyFPU6wNxZXiM4GD3orOoliWXXA2w9C@mail.gmail.com>
To: Maciej Stachowiak <mjs@apple.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 Wed, Jul 21, 2010 at 9:06 PM, Maciej Stachowiak <mjs@apple.com> wrote:
> 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.

Firstly, I am not sure if we really need javascript - possibly not.

Secondly, and more importantly, I would suggest to deal with caption
cues by rendering them into an iframe-like frame. This was originally
suggested by Henri Sivonen and I agree that this is the easiest way to
get a handle on the security issues, that we will likely have to deal
with anyway.

Received on Wednesday, 21 July 2010 09:29:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:55:41 UTC