- From: Philip Jägenstedt <philipj@opera.com>
- Date: Tue, 14 Jul 2009 13:15:13 +0200
On Tue, 14 Jul 2009 11:46:08 +0200, Boris Zbarsky <bzbarsky at mit.edu> wrote:
> Philip J?genstedt wrote:
>> Anything that can cause the element to switch back and forth between
>> displaying fallback and video is a no-go, that would cause a race
>> condition for if plugins/images in the fallback content. If they have
>> event handlers the results will get ugly fast:
>> <video>
>> <!-- network lag -->
>> <source>
>> <!-- network lag -->
>> <source>
>> <!-- network lag -->
>> <img src=foo onload="alert('how many times will you see this
>> message?')">
>> </video>
>
> The answer to the question in the alert is "once". This is true in the
> current fallback model, and would presumably be true in the new fallback
> model.
>
> For the current model, note that all the text says is "should not show
> this content to the user". While this is not defined anywhere, it
> doesn't seem to indicate that the content's DOM should not exist, for
> example. In Gecko, at least, the image in your example will be loaded
> and hence its onload will fire.
True, but you could easily have other things in the fallback content (like
mouse listeners) that are suddenly being triggered even though the
fallback content isn't going to be used. No switching back and forth,
please.
I've discussed the object fallback a bit with a knowledgeable colleague
who confirmed that we've had lots of problems with it. Uncertain state of
the fallback content from a scripts point of view is one issue. What to do
with nested objects (when to load/unload them) is another.
If we allow fallback people will certainly begin using nested video,
unless we want to another hack to prevent that.
Ian: can you make nested <video> elements non-conforming so that
validators will flag it? This would be helpful regardless of the fallback
discussion.
--
Philip J?genstedt
Core Developer
Opera Software
Received on Tuesday, 14 July 2009 04:15:13 UTC