- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Wed, 21 Jul 2010 21:28:50 +1200
- 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. Regards, Silvia.
Received on Wednesday, 21 July 2010 09:29:43 UTC