[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  
> though.

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

   <object data=foo>
     <img src=bar onload=alert('x')>

show a modal dialog?

Anne van Kesteren

More information about the whatwg mailing list