Proposal: standardize ?browser specific CSS include?

I've taken this proposal as I posted it on the WHATWG forum. Hence the 6 (7)

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 (almost) 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
maintaining 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

Received on Wednesday, 17 October 2007 13:14:06 UTC