From: "Christian Heilmann" <[EMAIL PROTECTED]> > > 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.
Respect what you say Christian - very much my thinking for I already build using no-hack no-JS cross-browser sites. However, once I saw a recent post (forget where) that remarked on dynamically separating styles by modifying the <html> tag according to browser type, all this caught my interest. I can see this method being useful for large or dynamic sites that must meet accessibility validation and in strongly structured sites. I've lost all hope of browser manufacturers playing the standards game so by placing a file on my servers and providing an API to it within my developments I can keep an easier track of browsers and their CSS quirks. In theory it offers quite a lot for portable, teletext and other devices too. So I thought I'd play and see if the theory meets fact - and remove a lot of need for addressing browser CSS foibles. It seems to assist with getting rid of unnecessary JS too (I find CSS horizontal menus that require JS severely distasteful). Also, I had a thought that by "globalising" browser issues in one place/file I could more easily knock off CSS issues as future browsers resolve them without turning my two brain cells to dust. Well - that's the theory! So, still coding for browser abilities and the future but experimenting too! Mike A. ______________________________________________________________________ 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/
