- From: Alan Plum <alan@cologneweb.com>
- Date: Mon, 29 Mar 2004 18:06:18 -0500 (EST)
- To: www-style@w3.org
Dave Shea wrote: (snip) > I believe this is the crux of it. In a year or three I will no longer > need to support IE5. I'll be perfectly content at that point to serve > unstyled markup to it, the same as many of us do now with NN4.x: > > <style type="text/css"> > @import "filename.css"; > </style> > > Except that the mechanism to hide CSS from IE5 isn't quite so tidy as > the @import rule that worked in NN4.x. I'd have to go to ridiculous > lengths with the Box Model Hack to get it to work. Actually that isn't exactly tidy either. I prefer avoiding the @import statement as some browsers tend not to load ALL imported stylesheets every time they load a page (I had five non-embedded stylesheets specified via link elements and in some cases Firebird 0.7 would ignore one or more of them - might be an issue with other browsers too). Anyway. > And that's just IE5. What about Opera 5, Safari 0.85, Netscape 6, etc. > etc.? And what about browsers that we (the development community) don't > discover hacks for? > > Discouraging version-specific control is what has created a need for CSS > hacks in the first place; the reality is that developers deal with > flawed browsers. Of course this at-rule was not introduced in order to allow locking particular browsers out, but just because it was needed. However that's the whole problem. All hacks utilize flaws in browsers in order to lock them out from either the entire stylesheet or just portions of it. There is no "legal" mechanism that allows that, mostly because the whole action is considered counter-productive. > Simply: we need a way to gracefully degrade our style for flawed and > older browsers, so as not to hinder usability/accessibility for our end > users. > > I don't see anything in the official spec that provides an opportunity > to do this. I think that's a shame. I don't think there's any way an organisation that focusses on standards will come up with a way of serving browser dependant stylesheets. The entire mess we are facing in the real world (tm) is caused by manufacturerers shipping products with flawed implementations of these standards and claiming they support them. The theory of browser independant webdesign, graceful degradation and absolute accessibility is nice, but sadly the real world is far from a stage at which all of these can be adopted entirely. Browsers will claim they support things they don't and people will keep on designing for the most popular browser. This might fade a bit if Mozilla, Opera and the other browsers get a larger market share, but with the Internet Explorer and all its flaws dominating the market, the introduction of revolutionary new selectors and stylings is a bit unrealistic. What would be better would not be a language dependant and thus client-side check for compliance, but a way to check it on the server side. It has been and will always be the job of the web designer to check if the design works with that-and-that browser, but apart from designing with the tight restrictions browser independant layouts require, the only way to solve the problem is going server-side and delivering content (and stylesheets) the browser can understand. The user agent string is apparently no longer a safe way to identify a browser and thus assume its standards support, so someone might have to work out a better way, maybe via RDF, but that'll require a standard of its own anyway. The checks required for double-checking whether a browser actually understands the style rules you're feeding it require a whole scripting language, not just a static stylesheet. Unless we want to use javascript or add tons of scripting syntax to CSS, server side should be the way to go. -ap
Received on Wednesday, 31 March 2004 09:11:33 UTC