Proposal: standardize “browser specific CSS include”

[nm]

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 XHTML/CSS to properly target these bugs. So-called CSS hacks are dirty and give 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 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?

Microsoft came up with the idea of conditional comments. This allowed people to write (and include) a specific CSS file for each 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 about 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 of 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 browsers 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 developers and will make developers 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. Aknowledging 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 bugfixes.

6. What evidence is there that this feature is desparately 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 currently.

7. Further Comments

I realize that targeting every browser bug in a separate CSS file can be an immense 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 forseeing 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 desparately needed.

Niels Matthijs,
feedback: here of course, or I can be contacted at niels@internetarchitects.be

[Hixie]

The problem is that most browser vendors would rather you _didn't_ target browsers, for two reasons:

* it disadvantages the browser you didn't test (e.g. if you tested in firefox, safari, and IE, then what about opera?)

* it makes it much harder to fix bugs, since browsers would end up with styles aimed at them that rely on bugs they no longer have

In general though, I recommend sending CSS-related suggestions to www-style@w3.org.

[nm]

In general though, I recommend sending CSS-related suggestions to www-style@w3.org.

Well, as the inclusion of files is purely an XHTML thing, I thought this would be at his place here. Wouldn't really know what to say to the CSS crowd. The only option I see there is extending the @import function, but I don't think that's a very sound option.

On both suggested issues, I don't really see your point :

* it disadvantages the browser you didn't test (e.g. if you tested in firefox, safari, and IE, then what about opera?)

I don't see how this function in particular disadvantages browsers you didn't test.

Let's say you're writing CSS and you're checking in FF, S and IE. Regardless of my proposition, if you're not checking Opera there are bound to be layout errors related to CSS. My proposition comes in handy when you do chose to check Opera.

When you test in Opera now and you encounter errors your options are very limited. Either you look for a solution that doesn't break other browsers. Experience thought me that this will kill you later on in the project, when the context of certain elements changes a bit, or they are used in a different context and suddenly that neat Opera fix kills your IE or FF. The other option you have is to rethink your CSS implementation, start all over again and usually write less intuitive and flexible CSS code.

I'm merely suggesting that when you do check a browser and you encounter errors, that you fix them in a seperate file not read by other browsers. This ensures that they won't be bothered by the fix.

Would you care to elaborate on how my proposition disadvantages other browsers in particular ?

* it makes it much harder to fix bugs, since browsers would end up with styles aimed at them that rely on bugs they no longer have

As is the case now. If you wish to fix a bug, you can either do so by adding CSS that is useless but fixes the targetted browser or you can try a CSS hack (in your main file) targetting a specific browser. In both cases, a newer version of that browser will be left with those style. Actually, all browsers are given that style.

For webdevvers, a new browser is not a big problem either. Image IE8 is just released. Your former IE stylesheet can still be served to IE6&7 (as is the case now) while IE8 gets served nothing. You open your site in IE8 and you check what bugs remain. In this case, newer versions don't even get the extra stylesheet.

As with the previous comment, could you care to elaborate who will have more problems solving bugs, and in what specific cases ?