Feed Sign in with OpenID OpenID

Simon Willison’s Weblog

A feature request for CSS3

One of the niggles I have with CSS 2 is that I frequently have to define colours multiple times. Consider this blog: I use orange in several places (as a background to the header, a border around the sidebar and a background to the sidebar h3 elements). Should I decide to change the shade of orange, or change it to another colour, I would have to alter my stylesheet in several places.

A nice addition for CSS 3 would be the ability to define “constants” for colours (and maybe for other types as well, although I can’t think of any that need them off the top of my head). It would be extremely convenient to define a bunch of colour constants at the top of a stylesheet and then refer to them elsewhere. For example:


@define {
  colour_1: orange;
  colour_2: navy;
  colour_3: #f00;
}

/* later in the stylesheet ... */

h3 {
  background-color: &colour_1;
}

That way, changing the @define block at the top of the sheet would change the colour of any element referring to a constant. I’m sure there are much better alternatives for the syntax, but the above should at least make the concept clear.

Update: It has been pointed out in the comments that this has been discussed before on the www-style mailing list but rejected for a number of reasons (see this thread). Aah well.

Posted 22nd July 2003 at 6:09 pm

This is A feature request for CSS3 by Simon Willison, posted on 22nd July 2003.

View blog reactions

Next: BuyMusic, the latest sharecropper on the block

Previous: Scott Andrew on Typepad

21 comments

  1. Exactly! I've wished this sooo many times. You could do this by serving a dynamically generated stylesheet with php, but you shouldn't have to use a scripting language for something as simple as this.

    jonner - 22nd July 2003 18:27 - #

  2. Great thinking - why stop there?

    Let's have palette arrays, so that I can define actual color schemes rather than single colours.

    @palette desert { #FFFFFF; #B4A183; #D8CB9D; #3DAAD7; }

    /* referring to it later as: */

    h3 { color: &desert(1); background-color: &desert(2); }

    The advantage being the ability to define consistent colour schemes, and have more than one per .css file.

    (pardon the code ugliness - how in the world do you force code formatting with no <pre>?

    Dave S. - 22nd July 2003 18:28 - #

  3. Yeah, plenty of people are clamouring for that. I doubt we'll see it before CSS 4 though, it's a fairly big change in processing to go into CSS 3 at this stage.

    Jim Dabell - 22nd July 2003 18:29 - #

  4. It's been brought up a few times on www-style, but the powers that be don't like the idea, so I wouldn't hold my breath. There are definitely some strong opinions on the matter, and the latest go-round got downright ugly.

    kevin c smith - 22nd July 2003 18:38 - #

  5. It *is* a good idea. Something that we all could make good use of. But to take Dave's comment further, why stop at color? I mean, color *is* probably the most repeated property. But there are other properties which I find myself repeating quite a bit too. Anything from borders to backgrounds to font sizes. The whole idea of setting variables or constants in a style sheet, then being able to reference them later is something I've wanted for a long time.

    I've always wished I could somehow combine CSS with something like PHP. The ability to embed a server-side language directly into a style sheet, or be able to link to a .php file (instead of a .css file) and still have it parsed by the server. Then we'd have access to for loops, if statements, and everything else. I know the same thing could be done if the styles were embedded in the header of a normal PHP document, but that's obviously not efficient for styling a whole site, even if the styles came from one include.

    Douglas Bowman - 22nd July 2003 18:50 - #

  6. You can serve the file produced by PHP as text/css using header():

    header("Content-type: text/css");

    kevin c smith - 22nd July 2003 19:04 - #

  7. I've always wished I could somehow combine CSS with something like PHP.

    You can do this, but it takes some server config and/or planning.

    One way is to include style blocks in the page <head> rather than linking; all manner of scripting is then exposed, and there's the attendant benefit of self-contained pages. You'd lose alternate media attributes, but the @media construct can be applied within the style block. I don't know how well supported this is.

    Another method is to have your server process, say, .css files through the pHp interpreter. They can then contain pHp script and conditionally render declarations based on lots of variables.

    I've done this with ASP. Since I'm new to pHp (and don't code much anyhow) I've not given this a thorough shakedown — but I don't see why it wouldn't work. The browser sees what you send it. How you build what you send it is nobody's business, and there should be no bias toward static, linked stylesheets.

    Lou Quillio - 22nd July 2003 19:09 - #

  8. Yup, there's nothing to stop you from serving your CSS file up as a PHP script apart from force of habit. I prefer CSS files to be static, but there's no real logic behind keeping them static in a dynamic site apart from the fact that CSS files are usually cached quite heavily, so if you plan to make frequent changes to them you may run in to problems.

    Simon Willison - 22nd July 2003 19:11 - #

  9. Addendum: You can see why W3C avoids these proposals. This is scripting. A document contains or incorporates CSS via links, but the document is the unit. Ranging into global variables turns the browser into a programmatic interpreter in ways that it today is not, ways that begin to choke it off, that turns documents into scripts. A document is a document. It should render legibly in the simplest of clients.

    Lou Quillio - 22nd July 2003 19:24 - #

  10. Actually, it can be done - if you serve your page as xml - with character entities. Works in Mozilla and Opera. Example: http://home.hccnet.nl/m.wargers/test/charent.xml

    I've seen it mentioned before I think in the w3c css mailing list.

    martijnw@dolfijn.nl - 22nd July 2003 19:35 - #

  11. OK, I've read through the thread on www-style and there are a number of argumetns against aliases. One of these is that this functionality can already be had by using a preprocessor. I don't buy that at all, for one simple reason: using a preprocessor requires developers to switch from editing a single document to working with two - the "source" document and the "compiled" preprocessed one that must be uploaded. This is a pretty big change in workflow practises for the average web developer (it's less difficult for programmers used to working with source and compiled versions of programs).

    By far the best argument against aliases is that they break backwards compatibility with CSS 2. Imagine a document which uses aliases to define some colours - a CSS 2 browser would not know how to resolve the aliases, and would end up using default colours. At best this would make a site look unattractive, and at worst is could lead to unreadable colour combinations such as black text on a black background.

    The final argument is that introducing macros to CSS would add a great deal of complexity and change the fundamental nature of style sheets (as Lou said, "This is scripting"). I find this argument less compelling than the backwards compatibility one, but it is still a consideration.

    To summarise then: colour aliasing is unlikely to be added to CSS primarily because it breaks backwards compatibility with the current range of browsers.

    Simon Willison - 22nd July 2003 19:36 - #

  12. To summarise then: colour aliasing is unlikely to be added to CSS primarily because it breaks backwards compatibility with the current range of browsers.

    Of course I defer to Simon's greater understanding of these issues. Yes, backward compatibility is critical to the advance of this medium we're consuming right here, right now.

    Still, arresting the programmatic demands placed on user agents is critical to keeping clients thin. That may be a larger concern.

    Lou Quillio - 22nd July 2003 19:53 - #

  13. pardon the code ugliness - how in the world do you force code formatting with no <pre>?

    This way:

    <p style="font-family: monospace; white-space: pre;">code</p>

    Add "color: #xxx;", "margin-left: x", anything else. Be kind and use <br />s to keep things from getting too wide. Preview first.

    Lou Quillio - 22nd July 2003 20:28 - #

  14. One of these is that this functionality can already be had by using a preprocessor. I don't buy that at all, for one simple reason: using a preprocessor requires developers to switch from editing a single document to working with two - the "source" document and the "compiled" preprocessed one that must be uploaded. This is a pretty big change in workflow practises for the average web developer (it's less difficult for programmers used to working with source and compiled versions of programs).

    Unless you use a certain Hypertext Pre-processor. The caching problem could be solved by conditional GET or something similar, couldn't it?

    anode - 22nd July 2003 20:40 - #

  15. I use a different technique to avoid redundant colour declarations - group the selectors that share the same color:

    h1, h2, a:hover { color: orange; }

    h1 { font-size: 180%; }

    h2 { font-size: 150%; }

    a:hover { underline; }

    but ofcourse, this sucks in many other ways - your declarations gets scattered all over the stylesheet.

    Kristian Hogsberg - 23rd July 2003 00:03 - #

  16. About 6 months ago, I came up with a mini-scripting language within PHP to handle aliases for colours, sizes and anything else. Sizes is particularly useful for creating CSS layouts. It also had more advanced features for doing recursion relations of header sizes ("make hn-1 x% smaller than hn"-style, although it was done using maths). If anyone is interested in creating a better, solid, common scripting language for these purposes, I'd be very interested in collaborating. Let me know.

    Gary F - 23rd July 2003 16:17 - #

  17. For the really masochistic, you could do this using server side includes.

    eric scheid - 24th July 2003 05:38 - #

  18. For one of my static sites I have a Python script that runs my CSS as a Cheetah template. That allows me to do things like: #set $green = "rgb(0,128,0)" #set $light_green = "rgb(64,128,64)" a:active { color: $green; background-color: transparent; } a:hover { color: $light_green; background-color: transparent; text-decoration: none; } Not a great example, but you get the idea. The only thing I want to add is a macro-tized box model hack to work around IE problems.

    joe - 24th July 2003 17:09 - #

  19. See http://www.w3.org/TR/NOTE-CSS-potential#id05684046 681

    Daniel Glazman - 27th July 2003 13:17 - #

  20. The very wonderful Topstyle does exactly this. There is a pallette selector which lists all the colours in a style sheet, wherever they occur, and lets you change them, either in all properties, or in background/foreground only. It is one of the best reasons in the world for using windows.

    Andrew Brown - 27th July 2003 14:01 - #

  21. Coming in on this discussion only a little bit late, but have a read of Dave Shea's explanation of what he calls "cascading". One of the ramifications, as I understand it, is that you can essentially create single-purpose constants. eg, if you're using a particular color for backgrounds, set up a class that just specifies background-color:orange; Then, in your html, add this class to the classes used by the various elements that will all have that same background-color. You can do the same for fore-grounds, widths, whatever. Although it means you are initially fiddling around a bit with the html, the stuff you are adding in fact describes a relationship between elements anyway, which seems quite useful. I haven't tried the technique yet, but food for thought...

    Joseph - 6th March 2004 06:26 - #

Comments are closed.

Previously hosted at http://simon.incutio.com/archive/2003/07/22/featureRequest

A django site