CSS: Selector Variables

Jens Meiert, February 7, 2008 / February 22, 2008.

This entry is filed under Web Development.

Especially complex projects suffer from higher cost of selector changes, and long sequences of simple selectors do impact the understandability and efficiency of style sheets. One solution might be selector variables or “synonyms”, a concept I proposed to the CSS Working Group yesterday, again if you want since Carmelo Capinpin did mention a similar idea in 2006.

The ongoing discussion brought up a few questions concerning definition and behavior (David Baron) and use cases (Elika Etemad) and “indirectly” revealed quite a few open issues concerning the specification and implementation of these variables, but I think it’s useful to publish the proposal in this place nonetheless, quoting the essential parts:

The basic idea is to syntactically allow definitions like
E = F;
… so that rules matching E would match F as well (and the other way around), while variable (or synonym) declarations could probably be located at the beginning of a style sheet or within a certain @-rule.

A more advanced step allowing for even more benefits is to allow selector grouping and a specific placeholder syntax as well, as in
E = F, G;
@H = I;
… where @H wouldn’t mean a “regular” selector but a “placeholder” only viable in style sheets and requiring a “regular” selector equivalent.

While current selector grouping already covers some use cases of these variables, there are a few specific benefits to them (omitting “when used right” and cutting examples):

Improved maintainability and “refactorability”:

Currently, the wish or need for ID and class name changes can only be addressed when both markup and style sheets are changed. Selector variables could not only offer faster changes and better maintainability by allowing “change CSS now, HTML later” cases, they could also mean a helpful precaution, for example, when IDs/classes are changed “anywhere” but authors are not or can not be sure if relicts are still around, or when they need to tolerate delayed changes on partner sites using the same CSS files. (Talking complex projects, this is.)

Example: .old = .new;

Improved style sheet clarity:

Extensive use of contextual selectors and/or long ID and class names usually resulting in less clear style sheets might be avoided by selector variables.

Example: @foo = #navigation li a;

Improved CSS efficiency:

Not talking about possible compression tools, style sheet size might easily be decreased by “compressing” long selectors through variables – without style sheets necessarily getting less readable or understandable.

Elika’s question for use cases and the problems the suggestion tries to solve lead me to additional reasoning:

The main problem the suggestion attempts to solve is the cost of selector changes. Currently, selector changes (above all referring to ID and class names) require changes in both HTML and CSS, “of course”. There are cases, however, where especially complex sites cannot guarantee all HTML to be changed, at least not in a timely fashion, while in these cases, selector grouping reduces maintainability (after all, the selectors in question should be changed, not extended) and bears a larger risk of getting overlooked later. Thus, improvements are either delayed or even dropped, and both cost and risk of changes are relatively high.

Selector variables could offer low-cost, instant changes without any risk of formatting and “compatibility” problems, via .old = .new; or @foo = .old, .new;, for example.

Another use case I see is the effect the (by all means desirable) way to use sequences of simple selectors has on CSS understandability and efficiency, meaning that “contextual selectors” are elegant but tend to be longer thus less understandable than simple selectors (referring to more complex style sheets again).

Example (HTML 4):
<ul id="nav">
  <li><strong>Home</strong>
  <li><a href="/exit">Exit</a>
  
</ul>
#nav strong {}
Assuming that the default li/strong element styling is not desired and the author wants to style indicators of “active” pages differently, the selector #nav strong appears to be an appropriate choice. However, a simple selector like #on would be shorter – but it’s certainly not elegant HTML:
<ul id="nav">
  <li><strong id="on">Home</strong>
  <li><a href="/exit">Exit</a>
  
</ul>
#on {}
Although there are even less characters used in the second example, it hopefully doesn’t mean too much abstraction to project that on cases where the selector in question is used more than once, and that exactly is the other problem: How can style sheets get more compact while at the same time preventing unneeded HTML changes and staying readable?

As for the example above and given that our selector is used five times, selector variables/placeholders could make
@on = #nav strong; /* user agent just replacing ”@on” by ”#nav-strong” */
@on {}
@on, .foo {}
@on, .bar {}
@on, .baz {}
@on, .qux {}
out of
#nav strong {}
#nav strong, .foo {}
#nav strong, .bar {}
#nav strong, .baz {}
#nav strong, .qux {}

Currently I’m curious about the next valuable feedback from Working Group and list members, even though it doesn’t necessarily mean an easy time learning to really “talk spec” and even though there might be certain issues that prevent this suggestion of getting through. This doesn’t even mean quite specific problems like handling of @foo, E = .bar, #baz; E@foo {}, test cases, and the like, no, it just boils down to articulating true arguments.

Wondering if my English skills do not suffice here I also ask you: Can you disprove or approve arguments for these variables? Do you spot any unmentioned problems or benefits?

Enjoy the most popular posts, probably including:

Comments

What’s your point of view? Comment.

Jens Meiert

CSS: Selector Variables

Read More

Comments

Leave a Comment