The problem comes when someone doesn’t get the CMS, but wants to alter their CSS files, but they usually come back to me in those cases; so I haven’t had to address that need just yet.

I suppose I could simply put up a form on my site that could post to that web service. Just some food for thought.

Maybe when the project becomes more mature I will make it public.

It sounds like you’re saying we should be developing parsers on a per-language basis. But why not make it a pre-deployment step?

I have made my own custom solution, a quick ‘n dirty php script that parses and rewrites my css files en mass. Done locally of course, and the result is uploaded. No need to do any active parsing.

Just my 2 cents! Cheers!

I agree that we use lots of colors in the CSS today. The thing is, many of those can be abstracted away with alphatransparent PNG-images. If we only could get rid of IE6 they would be really usable.

Using CSS-constants like Anders suggests would be really useful, I agree!

Also – if you wanted to change the colour-scheme of a site (at least the ones I normally code) it wouldn’t require the change of one single colour. It would require changes to probably 5-10 different colours _and_ background-images so I’m not sure constants would help that much in that case.

I think the biggest benefit of constants is the one that Anders Ytterström mentions, to get rid of _all_ design-related stuff from the HTML. Classes like “box” or “self-clear” or anything that you put in there only because the current design requires it should be in the CSS – not the HTML.

Coloring is a perfect place where constants would be useful. If the client changes their mind concerning a color you just change that constant. No need for search/replace. And no need to write a Java-CSS wrapper…

They’re silly-easy to implement using _any_ server-side-language and the syntax in the CSS wouldn’t have to change from server-side-language to language at all so you could re-use your CSS from server to server without problem.

@Anders Ytterström – I like how you think and I had exactly the same ideas as you when I built my CSS constants PHP Class. To remove the need for classes altogether.

I’m curious to know where you think HTML-constants (or variables) would be useful?

With that, I mean the use of mutliple common classes to create a presentation of a block:
<div class="nav horisontal tabbed">...>

It would be nice to instead create the css-variables nav, horisontal and tabbed in the css file(s) and use them internal. Would spare some non-content markup in the HTML.

Is this a good reason, Emil, or have did I miss the whole real part of CSS variables?

Do you mean HTML character entities? Or are there some other kind of entity that I don’t know about? Another type of symbolic constant is the use of frames. It lets you divide your page into different parts and reuse them (Aside: Fun spec, found while googling).

Preprocessing can solve these issues, but if preprocessing is something you always want, no matter what language, why not work at including it in the spec?

And by the way, HTML already has such symbolic constants, they’re called entities. They can only be declared in the DOCTYPE, not in the page content, but they can still be usefull. Last time I used them, I made sure to evaluate them in a preprocessing step, though. Not in the browser.

And preprosessing can be useful for css as well. Plain old cpp or m4 is actually very useful, both for symbolic constants and for merging separate files to a single “end-user” file.

Personally, I prefer one file since I usually use inline find (CTRL+J) in Aptana to locate a given section of code. For those unfamiliar with inline find, it works the same as normal find but doesn’t cause a window to popup, so you can just start typing at any time. Firefox includes this as the default find behavior (when clicking CTRL+F).

On a side not, I abhor including separate IE stylesheets. It’s become commonplace now for sites to use conditional comments to include separate IE stylesheets, for instance:


<!--[if lte IE 5.5] -->
<!--[if IE 6]-->
<!--[if gte IE 7]-->


This method frustrates me because I need to open 4 separate stylesheets to see all of the rules that are affecting an element. Instead, I much prefer this:


<!--[if lte IE 5.5]-->
<!--[if IE 6]-->
<!--[if gte IE 7]-->
<!--[if !IE]-->

This allows me to write CSS rules all in the same stylesheet, like so:


#some-element {
color: red;
}
.ie #some-element {
color: blue;
}
.ie6 #some-element {
padding-top: 10px;
}
.ie7 #some-element {
line-height: 120%;
}