> All I'm playing around with here is a method of removing the need for CSS > hacks by implementing different classes according to sniffed browser - in > this case by calling a PHP sniffer at the top of the page. I'm particularly > keen to see it's use in various accessibility scenarios.
Woohoo another one! http://rafael.adm.br/css_browser_selector/ Ok, some of my very personal and most probably arrogant and assumptuous (is that a word?) thoughts about this (based on 9 years of experience): 1) If you hack for browsers instead of browser abilities you hack for the past, not the future 2) A web site that looks and works the same on every conceivable browser is most likely neither clean code, nor maintainable, nor accessible 3) CSS has an in-built mechanism for browser support: Selectors and their support. #content>div is not a hack, it is perfectly valid CSS, and it does block out MSIE 6 (the same applies to html>body). 4) Did I mention that you have no chance whatsoever to test what the browser _settings_ and the users _abilities_ are? If not, you don't and just testing for a browser is just no data to base anything on. 5) Progressive enhancement means you build to what the browser can do. If it fails to implement something as easy as a box model: Don't give it a stylesheet. If it displays some whitespace because of linebreaks in the markup: Will your site still be usable or will hell break lose? 6) Web pages are: Content, Structure, Presentation and Behaviour. If we start concentrating a lot more on the first two and stop spending 90% on the 3rd and 5% on the last one we could actually build web sites for users, and not for browsers. ______________________________________________________________________ css-discuss [EMAIL PROTECTED] http://www.css-discuss.org/mailman/listinfo/css-d IE7b2 testing hub -- http://css-discuss.incutio.com/?page=IE7 List wiki/FAQ -- http://css-discuss.incutio.com/ Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
