SuzyUK - 12:57 pm on Oct 2, 2008 (gmt 0)

I'm not against preprocessing, but it can already be handled by languages suited to the purpose, defintions/scope etc. I just don't see why we need to add that layer into CSS itself.

<rant>
The biggest arguments for this feature that I can see is theming, now to me that means these arguments are coming from utilitarian CSS users/programmers, the ones that just want to write a stylesheet once and believe that changing a color scheme is theming. It isn't that's templating with a choice of skin. Templating can be taken care of via other means, probably preprocessed or dynamically generated sheets and if you're going to template your pages you may as well put the presentation back in with content (add classes to everything!) and pull your constants/variables that way?

Theming is different and where CSS comes into its own, take out the utilitarianism and inject some creativity, design etc. and see how the constants would work then. Look at CSS ZenGarden and tell me that style of theming would've benefited from constants, I think the range of THEMES would not have been nearly so vast if the designers had been in "constant" mode

Cascading STYLE Sheets, just where would the style be in a series of constants? The stylesheet writers would be too busy concentrating on which elements could use constants instead of just grouping together their already given or classified selectors, a function already provided by CSS - The design and creativity (the purpose of stylesheets) of the designers would be stifled as they get pushed and prodded into a programmers 'box'
</rant>

To me that's what this feels like, it feels like the "automate everything to make life easier" crowd want to stifle the design creativity freedom that CSS has brought to the web... They don't understand CSS and want to package it up into a way they do understand

anyway personal feelings aside,
IMHO CSS, when used properly, can pretty much constant things for you, if that's what you want. As swa66 stated above just group the selectors that you want to have a constant color, font, background etc.

@Bert

I agree that 2 types of font is usually all you need. But, and this is a big but. Any substantial site will use these fonts in places where you cannot simply use them the way you depict them. You need things like: #name > ul > li > p > a { font-family: Arial, etc; }

with that I completely disagree, substantial site or not, you do not *need* things like that, and even say you do whichever way you do it you are simply looking to match that very specific selector to a font-family you've already used (made into a constant). Perhaps that's why programmer types (not saying that's you btw Bert.. just the feeling from reading some of the other articles out there too) feel the need for constants, it's what they understand, they maybe don't get CSS quite as good as they should - in my experience "regular" CSS inheritance would likely take care of something like that, but if it is indeed an anomaly to your regular "body" font that you only want anchors that are inside paragraphs that are inside a list inside that div#name then firstly there is very possibly no need for the child selectors (it would have to be a very extreme one-off case for something like that and if you think about it there's hardly a need to constant an anomaly?)

But for arguments sake lets say it was a real scenario, take a look at the comparison of how it can be now and how it might be under a constant scenario.

How it could be now, to use swa's example with your example added in:

h1, h2, h3, h4, h5, h6, #name ul p a {font-family: Verdana, Arial, Helvetica, sans}

as opposed to the "proposed" note: this syntax is only a theoretical sample and is lifted from another site with HeadingFont, and some h2, h3 constants added in by me

@variables { HeadingFont : Verdana, Arial, Helvetica, sans-serif; CorporateLogoColor : red; TitleColor : blue; TitleFontSize : 16px; SubTitleFontSize : 14px; SubSubTitleFontSize : 14px; LinkColor : green; } h1 { font-family: var(HeadingFont); font-size: var(TitleFontSize); color: var(TitleColor); } h2 { font-family: var(HeadingFont); font-size: var(SubTitleFontSize); } h3 { font-family: var(HeadingFont); font-size: var(SubSubTitleFontSize); } /* I'm missing out h4 to h6 but you get the idea.. */ #name > ul > li > p > a { font-family: var(HeadingFont); }

that is not easier, indeed because (and it was only as I was typing it I realised this) you have to name the constants so they make sense. I added an extra sub for each heading level down in order to follow the naming conventions the example (or my employer) laid down.

So tell me just what is the point in replacing the already semantic elements we already have.. and then when it comes to actually applying the constant to your nested link scenario var(HeadingFont) for a nested link :o - does that name now make sense? - is anyone seeing a naming convention problem yet ;)

and just for fun, the first and second method combined (just with font family again):

@variables { HeadingFont : Verdana, Arial, Helvetica, sans; CorporateLogoColor : red; TitleColor : blue; TitleFontSize : 16px; SubTitleFontSize : 14px; SubSubTitleFontSize : 14px; LinkColor : green; } h1, h2, h3, h4, h5, h6, #name > ul > li > p > a { font-family: var(HeadingFont); }

and as you can see if the grouping selectors were used in the second example it would be doubling up for very little gain

Yes you can go in and change the HeadingFont in one place, but what happens if you then don't want that nested link to change, only the headings? you have to make a new variable for the link and still go to stylesheet to ungroup it from the heading selectors to replace it's value.. that's all we have to do right now, except we use the properties existing value as the constant instead of adding in a new variable name

nah, I think I'd rather stick to the grouping of selectors we already have, if people would concentrate on using the proper markup, and then learn CSS properly instead of trying to make things unnecessarily complicated I think maintainability (as this is what this is all about isn't it?) would ease itself