The abstraction is more likely to increase readability and comprehension.

Given that many styles (box-shadow, gradient backgrounds etc.) require multiple rules to render them reliably across browsers, we get faced with either repeating the same multiple rules for each selector that uses them (bloated & hard to maintain), adding additional mark-up (not a best practise and not always possible), or grouping all applicable selectors (less readable & loses context from other rules).

For those among us who don’t want the complexity (simplicity?) of learning to use constants/variables, then don’t use them. If it all gets a bit too much perhaps consider flipping burgers. I hear mctrolls are hiring.

I think it would be great to be able to write css like so.

@define style-sets { shadow: {…}, gradient: {..} }

nav { `shadow; `gradient; }
aside { `shadow }

Presumably “values” can be used in style-sets too?

@local {
$color1: #ccc;
$color2: #999;
}

@global {
$color1: green;
$color3: red;
}

Constants defined in @local would only have scope within the current file. Constants defined in @global would have scope in all stylesheets included in a web page.

Having some constants would make nobodys work harder but make it easier for many.

All that CSS really needs is just a rule concatenation mechanism (inside stylesheet). It would give a way more possibilities without introducing any new entities.

Say, one could simply define a regular rule:

.myTextColor{color:#000}

.roundCorners{border-radius:4px;}

and refer to it from other rules:

.myPage {background:pink}.myColor.roundCorners

And those rules would combine exactly the same way as if these styles were specified in html as:

Why doesn’t CSS just adopt XPath for selectors?

- Easy to learn
- Most CSS selectors have direct equivalents in XPath, making learning and conversion easy
- XPath includes many powerful features for advanced users

It wouldn’t exactly solve the constants debate, but it would make selectors powerful enough that the CSS authors who want to turn it into a programming language might at least feel that they have enough power with XPath that they might be willing to live without constants.

#define {TextColor1: #444; TextColor2: #777; TextColorBold: #111}
.MyBox {color: ?TextColor1}
.MyBox .ImportantStuff {color: ?TextColorBold}
.AnotherBox {inherit: MyBox; color: ?TextColor2}

This is equivalent to the following CSS -
.MyBox {color: #444}
.MyBox .ImportantStuff {color: #111}
.AnotherBox {color:#444; color: #777}
.AnotherBox .ImportantStuff {color: #111}

You will notice that the variables are simple macro-like substitutes and the “inherit: ClassName” syntax will bring in all attributes of the class along with any other rules that include that class. Small side effect – “#define” is taken so can’t use “define” as an html id.

More complex syntax could add more power, but this simple syntax was more than enough to meet the requirements we had.

Why do this in browser?
- Using the inherit syntax keeps CSS files smaller, processing on the server side ‘unfolds’ the inherits and we have larger files to send to the browser.
- Also if only some variables need to be changed (e.g. switching a theme) we could send a new CSS file down with a simple #define block with new variable values, rather than sending whole CSS down preprocessed with the new values.