- From: Ben Ward <benmward@gmail.com>
- Date: Wed, 12 Jan 2005 21:10:23 +0000
- To: www-style@w3.org
> I'm not sure I agree. If this does get implemented we will still run > into problems, as some browsers will, intentionally or not, mis-report > their own status. Combine this with a situtation similar to that of > HTML's button element--where one popular browser has implemented a > non-standard behavior, rendering the element nearly useless for its > inteded purpose. That is true, !required would not allow you to block styles based on browser bugs, only on unimplemented features. However, I would still encourage that this is useful enough for implementation (use-case in message #1: Konquorer 3.1.1 did not support *:hover but did support ">" selectors, preventing their use as a "CSS2 masking hack"). > I agree that some sort of support-based statement binding would be > lovely, but I'm wondering if this might be more reliably implemented > another way. As far as I can see, the only other way you might implement like this would be to base it on user agent (since bugs are ua specific). Specify a unique ID in CSS3 renderers and implement a syntax that would be ignored in all current (popular) CSS1/2 browsers. I think such a syntax is a very, very bad idea. In whatever way such renderer based filtering was implemented, it wouldn't work. If you specified exact versions of browsers then you'd have to update every time a new one was released, if you specified general browser names you'd exclude more recent versions with the CSS error fixed. Not to mention any future presence of new web browsers. There's no intuitive way to do that. At least !required is a timeless syntax that does not depend on the author. No, it doesn't solve any of the world's browser bugs but it does permit authors to push CSS uasge forward in browsers that support it, without worrying about which browsers those are. The only way I can possibly think about browser filtering being a 'good thing to do' is if we were to accept that the need to hack is inevitable and therefore provide a syntax for it so we can avoid messy comment hacks. E.g a "since we have to do it, just do it cleanly" attitude. Personally, I don't accept that hacking is inevitable and I don't think it's right for a standard to define that people should be allowed to get it wrong. -- http://www.ben-ward.co.uk
Received on Wednesday, 12 January 2005 21:10:29 UTC