[whatwg] Fallback behavior

On Tue, 13 Mar 2007 11:28:36 +0100, Maciej Stachowiak <mjs at apple.com>  
wrote:
>>> 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
<http://annevankesteren.nl/>
<http://www.opera.com/>

Received on Tuesday, 13 March 2007 04:21:14 UTC