- From: Boris Zbarsky <bzbarsky@mit.edu>
- Date: Wed, 14 Sep 2005 10:37:18 -0500
- To: www-style <www-style@w3.org>
Kornel Lesinski wrote:
> Vendors could use that intentionally to help authors avoid known rendering
> bugs (iframe {z-index} could fail in Opera, div
> {background-attachment:fixed;} in IE, etc.)
This is _exactly_ where this scheme fails. It's not that IE/Win doesn't
implement "background-attachment: fixed". It does. It just does it wrong.
Therefore, if this block-based parsing happened, a block conditioned on
"supports background-attachment: fixed" would be parsed in IE.
This has been raised several times already, but people seem to keep dismissing
it as a concern for a reason I don't understand....
> Why would they lie? - to get their browsers render 'at least something' from
> @required rules.
From marketing's perspective, they want to be able to claim features. Which
means that the browser itself, when interrogated, should claim those same
features. No rendering involved in the reasoning here, just marketing press
releases.
> * Default level would be "appears to work" and could be used in simple
> situations where just basic functionality of property is needed.
I'm not sure what this means. Would IE/Win's impl of
background-attachment:fixed fall under this? If not, then what would? That is,
it's not clear what "basic functionality" really means...
> * Second level would be "good implementation" which should be recognized only
> when browser has full and relatively bugfree implementation of feature.
Defined by whom? "relatively bugfree" has a lot of wiggle room....
> I realize that even such solution is far from perfect and browsers will lie
> or will not recognize strict level despite good implementation, but still I
> thnik that's better than nothing.
I think it's worse than nothing, actually, since I'm not seeing anyone offering
up the resources to specify this and then get it implemented. Consider that:
1) The WG will have to spend a lot of effort to define this behavior instead of
doing useful things like the CSS2.1 test suite or getting some of the
existing CSS3 specs into shape.
2) UAs will either:
A) Ignore this completely and not even bother implementing it
B) Spend time on implementing this instead of fixing real issues
and in case 2B the implementation of this feature would be flawed as we have
already discussed. The net result is that authors have a badly flawed tool at
best (if they have it at all), and that a good amount of work that really should
have happened hasn't.
> @required can't cause much harm
It can, in preventing bugs from actually being fixed.
-Boris
Received on Wednesday, 14 September 2005 15:37:26 UTC