[whatwg] Fallback behavior
Anne van Kesteren
annevk at opera.com
Tue Mar 13 04:21:14 PDT 2007
On Tue, 13 Mar 2007 11:28:36 +0100, Maciej Stachowiak <mjs at apple.com>
>>> As far as I can tell, the current spec does not adequately define how
>>> fallback behavior works. Specifically, what should be done with
>>> fallback content when not falling back?
>>> Presumably it should be parsed into the DOM, but should not render -
>>> that's the de facto behavior. But I don't think the spec says that
>>> anywhere. Then there are weirder cases, where some element has a side
>>> effect other than rendering.
>> Not render? That's really up to CSS, I'd say.
> I don't think CSS can define the rules for fallback, since it has no way
> to express the fact that an element is unable to present its primary
> contents for a wide variety of possible reasons. Though I could imagine
> this if there were some :fallback pseudo-class, and the HTML spec
> defines when it applies. That's clearly not how browsers work currently
Well, CSS defines how to display a replaced element and how to display
normal elements. An element becomes replaced once its fallback isn't shown
(for elements that can have fallback).
(Mozilla has something like :fallback implemented by the way.)
>>> - should scripts in fallback content execute?
>>> - should style elements in fallback content apply style?
>> Currently they apply, as far as I know. I'm not sure what should
>> happen. The case that bugs me most is something like
>> <object data=foo>
>> <object data=bar>
>> where foo and bar both start playing something, but you can't actually
>> see bar or turn it off...
> bar shouldn't start playing in that case, should it?
Not sure. Should
<img src=bar onload=alert('x')>
show a modal dialog?
Anne van Kesteren
More information about the whatwg