How do I implement browser specific styles?
The main reason for doing this is to hide certain styles from browsers that do not implement them properly (if at all).
The most common form of browser-specific styles is hiding styling from Netscape Navigator 4. Its CSS support is abominable, so hiding specific styles is essential for a website to display in that browser.
The @import technique
<style type="text/css"> @import(style.css); </style>
This hides the styles in style.css from Netscape 4 and some other CSS browsers (such as WebTV).
The media attribute technique
<link rel="stylesheet" type="text/css" href="style.css" media="screen, projector" />
Again, this hides the stylesheet from Netscape 4, but not WebTV.
Server-side methods
A different way of hiding styles is by dynamically generating the stylesheet based on information obtained through the HTTP Request. GreyTower.net has an excellent article on this. And some comments on the technique:
The experiment has left me with mixed feelings, to be honest. On one hand we are using the HTTP User-Agent header for the intended purpose, even to the degree as mentioned in the RFC of sending different content only for UAs explicitly known to have difficulty, and the main - correctly coded content for everything else. The problem with this is of course browsers which masquerade as something else - but we have a very, very good agent parsing library.
On the other hand it is a mess to maintain, even though we have a quite incomplex pre-processing solution using Wmake in place to actually generate the CSS files. Basically we have one 'master' copy of the file, which is split, manipulated, and re-saved as 15 different bugfixed copies, plus the main file and a copy of the HTML 4 'typical rendering' stylesheet from W3C (The latter is for NS 4).
Still - it is a mess to maintain, and it does place a horrible amount of focus on the purely visual. As I mentioned earlier we have two different files for Mozilla (0.9.7 and 0.9.8) where the only difference is a position changed from '42' to '44'. It becomes hysterical very quickly.
On yet another hand, it does allow for external designers (whom we do not employ) to manipulate stylesheets without ever touching the code, but that is an effect of the separation into XHTML/CSS, and not our slightly over-the-top separation of the CSS.
And, again, it does allow use to make allowances for a great deal of buggy CSS implementation. It started out, after all, as a way to make IE deal with our choice of using fixed positioning. This is yet another debate worth making, though. We've had the great fortune of being able to run a user test with a few people using tools for disabled access. They agreed upon - among others - three details considering the right hand fixed menu:
- It was good to have it on the right hand, as it didn't clutter up the LEFT hand side where they started reading. The less there were of unecessary artifacts on a page, the more positive their experience seemed to be.
- It was a good idea to have it fixed, as that meant they always had it there as a reference. When magnifying, it seemed to me that setting a virtual, memory-based, 'anchor' (ie. remembering where one was) in a page to pop down or up to the menu became an obstacle.
- It was a good idea to be able to hide it, again to reduce the clutter on the page when reading. When you magnify to that extent, it seemed that the main methodology was to scan quickly from left to right, and the menu then became an distraction every time they reached the right hand side.
It should be noted that the disabilities in question were low eyesight, and that screen magnifiers were used, and - of course - that mileage may and will vary.
I don't know how to evaluate it all yet, but the CSS solution does not feel like something we'd recommend to a client - not unless the thumbscrews where brought out first.