The following text is taken from the WHATWG forum and was meant as a proposition for html5. It was written by myself, sadly it didn't receive much attention. I changed it a bit but kept the general structure of the post. I hope reposting it here might generate some more comments.
The basic idea is to create a system where browser families and versions could be targeted separately by css. Much in the same way we are using conditional comments today. Here goes:
1. What is the problem you are trying to solve?
Give people the chance to write proper css without having to consider all browsers first. Browsers are not capable and probably will never be capable of handling all css implementations correctly (css3 is “coming”). Bugs are a reality and at the present time no system exists within html/css to properly target these bugs. So-called css hacks are dirty and cause problems when new browser versions are released (see IE6 - IE7).
Browser specific bugs should be targeted and fixed for each browser specifically. This should have no impact (or as little as possible) on the way general css is written. When a bug is fixed in a certain browser version, it should be possible to remove fixes without hurting other browsers and worrying about compatibility.
2. What is the feature you are suggesting to help solve it?/span>
Microsoft came up with the idea of conditional comments. This allowed people to write (and include) a specific css file for their browser (or even browser version). The idea of including a separate css file for browsers that need css fixes for a certain project is extremely strong. Rather than standardizing conditional comments, a feature where a css file could be included for a specific browser (version) would be ideal.
Adding an attribute to the link tag sounds like a solid way to implement this feature, although I will make no suggestions on the name of the attribute, nor the structure of the value. Looking at IE's conditional comments implementation, it would be ideal to be able to target multiple browsers at once if wanted (all IE, lower than IE7, IE6 & IE5, …). I will make no suggestion on how to practically implement this, as I think this is better left to people with more care and expertise in the html(5) area. One suggestion I will make is to set the standard value of the attribute equal to “all browsers”.
3. What is the processing model for that feature, including error handling?
It behaves like a normal css file include (link tag). With the exception that only those browsers which are targeted will include the css file.
4. Why do you think browsers would implement this feature?
Because browser vendors are becoming more concerned about standards, and unsolvable bugs reflect badly on a browser. Giving developers a way to fix the bugs that are still apparent in their browsers satisfies them and will make them put more effort in optimizing a site for a specific browser (instead of ignoring them and leaving bugs unfixed because their market share is too small anyway).
css is a complex matter and will likely be plagued by many browser bugs to come. Acknowledging that is a good thing, it means a browser vendor is at least aware of the complexity and the reality of the situation.
5. Why do you think authors would use this feature?
Because it allows them to further develop their css skills. Exploration is often tempered by developing for the lowest common denominator. IE's conditional comment system made it possible to fix everything in an IE specific css file, meaning that the main css file got a lot cleaner and easier to maintain. When a browser (version) does not have to be supported anymore, it's as simple as dropping a css file, instead of being stuck with dirty legacy css.
Those who don't want to use it, don't have to use it. It does not bring extra complexity to those who don't want it. In the end, sites can be better supported cross browser while at the same time having a clean and finished css file. The rest is just bug fixes.
6. What evidence is there that this feature is desperately needed?
The main evidence is not very concrete, but it is seen almost everywhere. css files are often dirty and designed to work on FF/Opera/Safari. Every css bug left in these browsers influences a developer's way of working in his main css file. Those developers not familiar with the current conditional comment workaround use dirty css hacks instead, or just deliver buggy websites.
css2 has been around for a long time, but looking at css code, this is not very apparent. People are still hacking themselves through css, instead of learning to work with css and keeping a css file clean and maintainable. This feature will give them the chance if they want to improve themselves (and that is really desperately needed).
More concrete (but probably less desperately needed) are bugs that are unsolvable cross-browser. These are not very common but can be a nuisance to those who like to deliver quality websites. Opera has a background color problem which can be fixed but breaks Safari. A deadlock bug like this cannot be fixed at the moment.
7. Further Comments
I realize that targeting every browser bug in a separate css file can be an immense amount of work and is sometimes not possible within the constraints of a project. Still, this can be part of a step-by-step process where a developer can implement his often good ideas to use css without having to worry about complying to 5 (or more) browsers.
A little more caution is needed when making changes to the main css file (as fixes in browser specific css files should be considered too), but a little documentation can easily fix this.
In the end, I think the advantages surely outweigh the disadvantages or possible problems. Looking ahead and foreseeing problems is an important part of building a standard. css will be a problem for a long time to come, mainly caused by bugs in browsers. Devising a system where these bugs can be addressed without reverting to hacks and tricks and generally not writing good and maintainable css is important, and in my opinion desperately needed.