Friday, September 21st, 2007

CSS 3 and where we could be

Category: CSS

Alex keeps it up by discussing how CSS 3 is a giant serving of fail. Alex believes that in 2007 you should be able to do things like this in CSS:

  1. .highlight {
  2.   color: red;
  3.   text-decoration: underline;
  4. }
  6. .updated {
  7.   @importRule '.highlight';
  8.   background-color: yellow;
  9. }
  11. .updatedByOthers {
  12.   @importRule '.updated';
  13.   color: #3f5070; /* a nice dark blue */
  14. }

and how we need variables:

  1. @define hlColor red;
  2. @define hlBgColor yellow;
  3. @define oUpdateColor #3f5070;
  5. .highlight {
  6.   color: {hlColor};
  7.   text-decoration: underline;
  8. }
  10. .updated {
  11.   @importRule '.highlight';
  12.   background-color: {hlBgColor};
  13. }
  15. .updatedByOthers {
  16.   @importRule '.updated';
  17.   color: {oUpdateColor}; /* a nice dark blue */
  18. }

The recent growth of CSS frameworks is starting to highlight some of the massive failures of CSS and its implementations, but it’s not clear how the web development community is going to shake itself awake and start asking for more than proper “:hover” support from IE. And given the pitiful state of CSS 3, it’s not clear that we should even ask the W3C for improvements anyway.

As well as the frameworks, we also see a lot of pre-processors such as server side CSS constants and other simple template hacks.

Posted by Dion Almaer at 6:36 am

4.5 rating from 45 votes


Comments feed TrackBack URI

I couldn’t agree more! I also think this is highly required to make otherwise nightmare layouts simple:

.side_panel {
float: left;
width: 250px;

.main_panel {
float: left;
width: {100% – 250px};

Comment by Michael — September 21, 2007

I’m curious if there is work beeing done to incorporate suggestions like Alex mentioned. And if we could expect to see this in one of the mayor browsers in the future. Perhaps a donation like there is Tamarin on the javascript side?

It’s clear that W3C standards don’t take CSS into the right direction fast enough. If a solid contribution from the development side was to be picked up by a mayor browser, the W3C can do what they do best and standardize it.

Comment by Nick — September 21, 2007

i’m not sure, if that’s the right way to go. in my opinion CSS would get unnecessary complex and hard to read. however it’s good to start a discussion about CSS and there are good points in the comments of alex’ article. i think CSS should have inheritance / overloading features – to keep CSS simple, the inheritance should be defined somehow through the identifier.

Comment by Harald — September 21, 2007

Let’s see CSS get serious about web typography too, please.

Comment by johno — September 21, 2007

CSS is pretty serious about web typography. The problem with web typography is that you’re limited to the subset of platform-standard fonts, and of course that browsers don’t always fully implement the W3C standards as they should.

Comment by Ben Bodien — September 21, 2007

That is not variables, that is constants. Shaun Inman has a solution for CSS Server Side Constants readily available for some time now. Eric Meyer wrote about it in his blog too.

Comment by Gordon — September 21, 2007

I love the “importuRule” thing.. I always wanted to have something like this in my CSS files :)

Comment by netsuo — September 21, 2007

I’d love to be able to use import rules and constants. On my company’s Intranet, I’ve given users the ability to customize their applications’ color schemes. Right now I have ASP code littered throughout my CSS document to generate the code on the server-side. It would be much nicer to have one short dynamically generated section to define the background/text color classes and then a normal CSS file which would import those classes as needed.

Even taking away dynamic generation, constants would make changing site colors insanely easy. Instead of trying to find all instances of #F3C0B3 and replacing it with #F0A874 (to pick two RGB’s completely at random), you could just define your colors at the top. Then you would have one easy place to make your changes.

Comment by Jason Levine — September 21, 2007

Since I’m using SASS ( to generate CSS my life has changed. The insertion of Variables, clean syntax really ease the way you are developing web apps.

Comment by Donegarden — September 21, 2007

i understand that it would be cool too have the importrule thing, infact, i’d use it.

but isn’t that the same as giving an element 2 classes in the first place

blah blah

Comment by James Murray — September 21, 2007

oh my html didn’t show up

here it is


Comment by James Murray — September 21, 2007

damn nevermind, you all know

Comment by James Murray — September 21, 2007

I recall reading an article by, I believe, one of the people who made the initial CSS1 standard. He said they left out OO-like extension of classes because it would make CSS too complicated. He had some examples to show exactly why. The problem was mostly precedence: for example, if subClass extends parentClass, then which selector goes first: “div.parentClass” or “.subClass”? That would make a mess, eventually.

This importRule mechanism seems to solve those complexities. However, what does, a statement like importRule “div.class” refer to? Does it import all rules with pattern exactly equal to “div.class”, or does it import styles by cascading? Would it also import “.class” rules, for instance? That would make things messy, too, but as long as you refer to exactly one rule, it seems simple enough.

So my proposal would be to allow for “named rules”, or “rule templates”. For instance:

@template('big') {
font-size: 200%;

.class {
@importTemplate 'big';

.other {
@importTemplate 'big';
... more ...

That seeems cleaner, easier to use and easier to implement.

Comment by sb — September 21, 2007

Here you go:
(basic importRule implementation in javascript)

Comment by cedric — September 21, 2007

It is really important to have this articles and conversations. I am feeling that web standards are stagnating! Take HTML4 for example, its the same for many, too many years. And the implementation of the css3 standards are taking awfully long!

and yes, I would kill for css constants and this kind of import rules. And most of all I would kill to have M$ to respect all the standards and to have somekind of windows update to upadte 6.0 and 7.0 too!

Comment by Damir Secki — September 21, 2007

Let’s skip things that can be handled programatically and move on to other things…

Comment by Sam Hill — September 21, 2007

The @importRule thing is silly. Proposed code:

.highlight {
color: red;
text-decoration: underline;

.updated {
@importRule ‘.highlight’;
background-color: yellow;

.updatedByOthers {
@importRule ‘.updated’;
color: #3f5070; /* a nice dark blue */

Current CSS code that accomplishes the same thing:

.highlight, .updated, .updatedByOthers {
color: red;
text-decoration: underline;

.updated, .updatedByOthers {
background-color: yellow;

.updatedByOthers {
color: #3f5070;

Perhaps rather than wasting time inventing new things we can focus on learning how to use the CSS that is already available? However, I do agree that constants would certainly be useful, especially in large CSS sheets … but you can already do that with a server side language. CSS can be dynamically generated.

Comment by Marat Denenberg — September 21, 2007

What is being described is an excellent idea … for a PREPROCESSOR, not for the CSS standard.

What value is added by having the client figure out what a page building environment can precalculate?

Comment by Evan — September 21, 2007

Agree completely with what Alex highlighted here. It is needed. It is basic. Developers all want this, so why are they dragging their feet with the standard???

Comment by Mark Holton — September 21, 2007

If you wait for a standard, you may wait forever.

I think the pre-processor route is the way to go because it doesn’t rely on third-party support and ultimately there’s nothing wrong with CSS. CSS is fine, it works — but it would be nice if we could manage it more effectively.

No one expects the HTML spec to change to support all the functionality PHP, ASP, JSP, etc. provides, we shouldn’t expect the CSS spec to either. And we shouldn’t expect others to do it.

Many CSS authors have expressed interest in variables, constants, includes, rule nesting, and inheritance. Here’s 2 projects that have some of this functionality (I helped write Switch):

Switch CSS Pre-processor:

CSS Server-side Pre-processor:

If you are interested in this functionality, support these projects and others like them.

Comment by J Christopher Garcia — September 21, 2007

I could write a custom stylesheet and a script to dynamically generate styles in the time it takes to write a blog posting complaining about standards… The W3C has a lot of stakeholders asking for a lot of different things – and in a situation like that you can’t please everyone. The profession of building web pages has come a long way in the last 10 years, and I think the W3C is a big part of that.

Comment by Will Peavy — September 21, 2007

What is being described is an excellent idea … for a PREPROCESSOR, not for the CSS standard.

What value is added by having the client figure out what a page building environment can precalculate?

Exactly none. One of the things that makes CSS usable is that it can be parsed in exactly one pass, without having to perform lookups or substitutions, or actually do anything beyond actually just parsing, which means that the parser can start immediately, be done a short time after loading, and just apply the parsed rules. Adding substitions and constants (and xpath selectors, as other people have suggested to me in the past), would just end up in users seeing a lot more FOUC than they do now.

Comment by Arve Bersvendsen — September 22, 2007

speaking of Importing rules, right now you can’t use same RULE from different CSS files on a tag. For instance both my friend and me wrote a rule “header” with different attributes. If I am liking both .css files, both rules will get merged since I can’t refer rule from particular file on a particular tag for instance

Correct me if I am saying wrong?

Comment by Adnan Siddiqi — September 22, 2007

Umh…What CSS frameworks?

Comment by jonah — September 22, 2007

And another thing:

Why is CSS selector syntax so similar to — yet so different from — XPath?

Comment by Marty — September 24, 2007

Am I the only one whose stomach drops when imagining the potential mess of CSS this could cause? It is too easy for developers to blindly copy CSS without understanding the rules of specificity and not using the big C in CSS to their advantage. This is a real problem now.

Imagine debugging this gem spread across 5 or 6 styesheets …

.highlight { color: red; }
.sidebar a {
@importRule ‘.highlight’;
font-weight: bold !important;
#foot a { color: blue; }
#foot p.right a {
@importRule ‘.sidebar a’;
font-weight: normal;

I only see it getting worse from there.

We all have ideas of what would make our day-to-day work easier. I would like to see print/paged media concepts extended to the screen world so as to better separate unrelated content. Like …

@screen #foot {
.vcard { color: gray; }
.legal { color: white; }

I can see problems here too though because my main goal is to avoid typing it this way…

#foot .vcard { color: gray; }
#foot .legal { color: white; }

Namespacing in CSS 3.0 combined with XHTML 1.1 modularization offers solutions to many of our current “problems” that are more forward-thinking than mine above. I’d like to see more pressure on the browser makers and the W3C to get moving.

If you haven’t done it, look at Prince XML (the most up-to-date CSS engine I’ve used). If you don’t know this already, you’ll learn that CSS is for more than HTML and that Microsoft really does/did have the box model wrong. At the very last though, I can guarantee that you’ll want those selectors NOW.

I can’t imagine a Web 2.1 without CSS 3.0 and XHTML 1.1.

Comment by zack Frazier — September 25, 2007

I think we should also see support for multiple background images and positioning in a single element. Sure we can use multiple elements (aka tag soup) within other elements to produce the same effect, but NOT ALWAYS. For example, say I want to style a form button with the sliding doors method of design for stretchable element styling. I can’t insert a inside an input or button tag, that’s preposterous! But how will I ever achieve the capability to ever make my buttons look as sweet as Safari’s or Firefox’s otherwise? Exactly, I’m not.

I propose something like this:
input[type=button], input[type=submit], button {
background: {image1} {repeat} {attachment} {position} {z-index};
background: {image2} {repeat} {attachment} {position} {z-index};

Alternately, the “z-index” of each background image within the rule could be determined by the order it appears within the rule, such as: first is on the bottom, second is just above it, and the last image is the top-most image.

At the very least, let us apply multiple backgrounds to one element through the use of multiple classes. I know this goes against theory of web design (in that you can only apply one background image to an element), but we’re seriously limiting ourselves. The Web is a dynamic medium, and it’s “designability” should be dynamic as well.

I think laziness has overcome the w3c. It’s truly sad. Now that IE 7 is out, we’re gonna have to wait much longer to see any css3 support from IE at all, even if the w3c gets their act together and starts striding towards finalizing it.

Comment by Scott — September 26, 2007

This is a great idea. I can’t tell you how many times I could have used this technique in the past. So I made a little script that can easily allow the @define and @importRule functionality into your CSS files. I just released a basic version of it, and will be adding more options to it soon, so make some comments on my blog about what you’d like in it.

Comment by Justin — October 3, 2007

Leave a comment

You must be logged in to post a comment.