On Tue, 13 Mar 2007 11:28:36 +0100, Maciej Stachowiak <[EMAIL PROTECTED]>
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/>
