CSS constants

Last week I was asked by one of my colleauges what I think of something that is referred to as CSS constants. So, let me start with a couple of example solutions:

Shaun Inman‘s CSS Server-Side Constants
The way this is made possible is through pre-processing the file on the server through PHP (and adjusting some server settings), which then replaces the refererence to the constants in the CSS file with their actual value.
Chris Heilmann‘s CSS Constants
Chris’ solution is also PHP-based, and pretty similar to Shaun’s.
Using ASP/ASP.NET
Above solutions could easily be written in an ASP as well. Another simple option is to just serve the page as a server-side page:


<link rel="stylesheet" type="text/css" href="css/my-css.aspx" />

and then write out the values in the CSS file like this:


div#container{
	background: <%= backgroundColor %>;
}

So, what’s my opinion then? I think it shouldn’t be done that way; I think it ruins the idea of CSS being stand-alone and not dependant on server-side languages or server settings.

When it comes to customers using a CMS, I heard a suggestion that the editors should be able to set such variables with colors etc through an admin interface. From my experience, most editors don’t have the feel for using colors and fonts, they don’t understand the importance of a web site being consistent, they’re usually not trained in what effects it will have on usability and accessibility.

Then, you would say, just give the editor some fixed options when it comes to setting these constants. My response to that would be: just deliver some different CSS-based skins to the customer with the suitable fonts, colors and so on, and then the editor will have the option to choose between tested skins, not single colors and their likes.

Some web developer arguments, and my reply to them:

It’s so much work having to change the same value in so many places
Use an editing tool that supports find and replace, if that’s your biggest gripe.
It gives a much easier manageability to edit all these values in one place
I aggree with that, and I think, as does Eric Meyer, that constants in CSS is a good idea and that they should’ve already been in it. But I don’t think it should be done by the cost of having to use a certain server-side solution or a specific server type.
And also, in most cases where people ask for this, they don’t have the necessary knowledge of CSS and fail when it comes to using its potential and full cascading possibilities, and then start screaming for server-side solutions to cover up for their lack of stylesheet skills.

 

So, go crazy if you think it rocks your world. But I’ll advise people not to use it, until it’s a feature in CSS.

Posted in CSS

4 Comments

  • I agree. I played around with it at first, but because of some (still unfixed) issues I rethought the idea and came to the conclusion there's hardly any real benefit πŸ™‚ Letting Apache handle the caching shit is so much handier anyway. So back to oldskool CSS for me :]

  • Robert Nyman says:

    Krijn,

    Good to hear that you share my stance. πŸ™‚

  • Henrik says:

    Tjena/Hi there

    First post in you blog :). The blog seems alright so far…

    I don't know why you call them constants, but variables in css could be useful if you want dynamic resizing of a page. You could have some sort of basic css template where you have variables written like or similar (databinding is better coding practise in ASP.Net). Width calculation is something you'd appreciate in css, so you could use variables for that.

    The css is still separated from the content, so it doesn't not really relevant to the client browser if you use dynamic css or not.

    I don't know who it is just like that, but some guy has today's weather as his blog header – it uses dynamic css – something that makes it smaller, saving bandwidth and decreasing downloading times. So there are times when you want to use it.

    An example would be to change the total width by changing a variable; cascading to the rest of the blocks.

  • Robert Nyman says:

    Henrik,

    Welcome here, I hope you'll like it. You're in good hands… πŸ™‚

    First, why I'd call them constants is because they can't be altered in the <acronym title="Cascading Style Sheets">CSS</acronym> file itself, <acronym title="Cascading Style Sheets">CSS</acronym> doesn't allow changing the value. That's why I'd regard them as constants as opposed to variables.

    The thing with dynamic values in the <acronym title="Cascading Style Sheets">CSS</acronym> file is that even if the <acronym title="Cascading Style Sheets">CSS</acronym> would be separated, it would still be dependant on the server-side generation; it would need a server round-trip to get its new values.

    When it comes to becoming smaller and saving bandwidth, that would really only apply to huge web sites or in cases where the <acronym title="Cascading Style Sheets">CSS</acronym> isn't optimally constructed using its cascading and inheritance power.

    Basically, I see no gain when it comes to the file size or dynamic updating of the values (in that case, an AJAX approach would be far better to have a real dynamic updating of <acronym title="Cascading Style Sheets">CSS</acronym> and other values in the page).

    The only benefit, if constants were natively built into <acronym title="Cascading Style Sheets">CSS</acronym>, would be an easer overview of values used in it. But if that takes dependancy on server-side processing and of certain server-side languages and other settings needed to be used, that rules it out for me.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.