Scott Isaacs, one of the Microsoft web chaps, is complaining about CSS hacks. His proposed solution is to, instead of applying CSS hacks to make a browser do what you want, instead have details of the users browser inserted into the HTML element either by server-side or client-side script. So, if you visit a page using IE6.0, it would add class="ie m6 d0 win" to the HTML element; using Firefox 1.06 on Linux it would add class="firefox m1 d06 linux", and so on. Then, in your stylesheet, use these hooks to apply style for specific browsers.
I think that this is not a good idea, and here’s why.
Firstly, it requires absolutely that every page be server-parsed, since you can’t rely on client-side scripting being there. Well, unless you’re prepared to make your styling depend on JavaScript, which rather defeats the point of CSS. In some places it seems like the norm is to make all pages, even ones with plain HTML and no dynamic content at all, be server-parsed by making them ASP or PHP, but I don’t like to do that for pages that don’t need it. If you’re thinking “but every page needs a header and that’s normally dynamically included!“, think about automatically generated pages which are generated dynamically when required and then cached, like blog archives. Or think about mailing list archives, or pages where the header and footer are added by your web editing tool like Frontpage or Dreamweaver rather than by the server.
Secondly, it clutters the HTML a bit. Not much, but a bit. This isn’t much of an objection.
Thirdly, how do you establish the platform and short-name-for-a-browser and major and minor versions? Parse the userAgent string? That takes us back to the days of browscap.ini and The World’s Biggest List Of Browsers, which you have to rely on someone to maintain.
In short, I don’t like the idea. I’d be interested in hearing dissenting opinions, though.
(Incidentally, you may be thinking that this should have been a comment over at Scott’s rather than a post here: I agree with you, but to post there you need an MSN passport and I don’t want to get one.)
Yep I’d agree with you on this one.
CSS Hacks should be avoided that’s a given, but to have the server create custom code for each user-agent is not something I’d be likely to use.
What happens when new user-agents that aren’t accounted for are visiting a site based on this method? If they aren’t detected what do they get served?
I would also concur that dealing with hacks in Scott’s method does create issues on the server parsing front and I wouldn’t want to use this method as it would mean I couldn’t have completely static cached content!
Personally I find that the need to use hacks for FireFox/Opera etc. is becoming less and less and I’m mostly having to use hacks for IE. When that becomes necessary I use conditional comments to show those hacks to the IE versions I want to effect.
This means when IE7.0 comes along it won’t see the hacks I’ve got in place for IE 6.0 and below and I can simply leave it at that or create a new IE7hacks.css for IE7 assuming it will support conditional comments in the same way.
Even if I need to hack for other browsers then I would probably still look to using a separate file. That way it becomes clear and makes the site easier to maintain in future.
Before I even get to the point of doing the above I’ll check that my hack is required for an actual rendering bug and not one caused by the differences in default styles or bad coding! In the past I was guilty of the bad practise of hacking everything that wasn’t rendered the same between browsers. Now I reset the default styles with simple rules before I start.
Here’s a wacky idea – why don’t MS make IE properly CSS compliant, and avoid the need for hacks altogether!!
I know – never going to happen
There’s also a problem when you save the page for offline viewing and then view it in a different browser to the one you saved it in.
Also, also, a lot of business employ a web cache. What happens if the first in the busness person views your page in Opera? All others behind the proxy will see the opera version of your page irrespective of the browser they are using.
( Both these points were pointed out to me in the comments for my article on Server Side CSS Sniffing: http://richardathome.no-ip.com/index.php?article_id=106 )
Great points. I posted a short update to my blog entry that addresses a few of the points listed here.
Your proxy caching is a good point (and perhaps the best argument I have seen against any server-side implementation of this approach). I lean more towards using a client script (and added the server approach late without deep thought) because I prefer to leverage the client whenever possible. I am less concerned about scripting being disabled because we are building “applications“, not web pages (I will save my detailed thoughts on this for a future post).
I remember the browsercap days and I believe this approach is far from it. All we are doing is creating a classification scheme (it can be very specific or broad based on your requirements). This is no less offensive than leveraging css bugs (which is basically an obscure approach to browser caps).
For unrecognized user agents, remember you are creating a base stylesheet and only overriding for known issues. Any browser that you do not recognize gets the “standard” css sheet. This is the best case even when you use hacks (and arguably has an advantage because if you don’t recognize the user-agent how do you know how they will react to the “parsing” errors being leveraged in the css sheet). My problem with the hacks is they are not parsable by the average developer.
Scott: the point about applications versus sites is a good one. While I myself am an applications developer (much like you) there are a lot of website developers out there too, and they’re using CSS hacks. To be honest, most of the “web applications” out there depend on Internet Explorer and don’t work in anything else (although it’s great to see that MS themselves aren’t leading that trend, and start.com and so on are fine in Firefox too). Those web designers still need to offer good design cross-browser, and can’t rely on client-side scripting: does your proposal suggest that they should still use CSS hacks?
The point about unrecognised user agents is a good one, I think; code the base sheet to standards and then apply overrides of the base sheet for specific browsers that don’t comply with those standards; I was wrong to stress that so much.
mrben: no browser is entirely compliant with the standards. IE has fallen behind somewhat recently, although IE7b2 shows promise, we hope…
Scott: I shall be interested to see your points further in relation to your note that “I am less concerned about users that disable scripting – we are building applications, not web pages – and I view the argument that our applications should be able to run with scripting turned off as academic“. It’s not just “scripting turned off“; there’s also “doesn’t do scripting at all“, such as the browser in my Blackberry, the browser in my mobile phone, me grabbing pages quickly for parsing with an object like Python’s urllib or MSXML2.ServerXMLHTTP. Oh, and commandline browsers like lynx as well, obviously. I’m concerned that the approach here is “well, those user agents are obviously rubbish; if you want to get at good stuff on the web then you’d better use a computer or go out and buy an overpowered PDA that can handle it“…
sil: Devices are a different story (hence why I was deferring discussing how to handle no script support). For devices, you have a unique set of challenges (footprint, etc) so you typically apply an alternative strategy. (e.g., check out http://mobile.spaces.msn.com/). Arguably that “presentation” can also serve as the the “reach” or no-scripting case.
A thought, if I’m reading the html 4 dtd correctly the html element cannot have a class attribute so the code is not valid. Is this not a problem with this technique. I suppose you could apply the classes to the body…
That said I’m not so keen on the idea the css support in most browsers is coming on well, I generally only work around ie (mac and win) so I don’t see the need for this approach.
ie conditional comments do the css for ie and everybody else gets the standard css (no hacks). I use a hack for ie mac to import its css and I think that is fair enough since it is a dead browser.
Perhaps some declaritive analog of document.hasFeature would be good.
Simpler, perhaps there should be standardized way of doing conditional comments.
Nah, that’d just get buggy implementations as well. At least hacks for CSS parsers are known.
Nice blog.I like this.
Nick
http://www.yahoo.com
please send me acode and how it works in the client side hacker i will like to see it in action.
just to know how it works.
Hi
The power of CSS is amazing. I’ve seen a few sites like this one where i’ve been blown away by what you can do. Alot of DHTML and other funkiness can be avoided if your clever with your stylesheet.
I want to manage a stick up footer on the website for IE 5.0 +. with CSS As you can see 1 on bmw.co.uk
thanks
Imran
Hi! Who knows still sites similar to this?
There is a css hack that works for all versions of internet explorer, including ie7. You can read about it here:
http://www.ibloomstudios.com/article7/
[...] Original post by Brian Benzinger and software by Elliott Back [...]
[...] Original post by John Musser and software by Elliott Back [...]
[...] CSS Hacks and Server-Side Code – Stuart Langridge [...]
fr