Were there any technical limitations within CSS that led to the decision of using `--` for vars?

Question

With the introduction of css vars, I would like to know the reasoning of of why -- would be chosen as a way of denoting a var.

Considering CSS has a semi capable calc function, I feel like the -- could easily be confused for a decrement operator in other languages.

I am curious if there is any historical significance or technical limitation that led to choosing --. The double in particular perplexes me, when CSS markers are generally singles (#, ., @, etc). Also using a symbol already being used by other things also is interesting (especially when its valid for a class name to begin with --).

Example:

@custom-media --lt-sm (width < 576px);
--grey300: #e0e0e0;

.navbarItem {
    display: inline-block;
    text-align: center;
    border-top: 1px solid var(--grey300);
    border-left: 1px solid var(--grey300);

    @media (--lt-sm) {
        flex-grow: 1;
    }

    &:last-child {
        border-right: 1px solid var(--grey300);
    }
}

Disclaimer

Some might argue the validity of this question, but understanding the why is a key technique to remembering a particular concept.

The only discussion I can find related to it:

In the telcon today, we resolved to use a "--" prefix to indicate custom properties and other custom things.

We discussed whether the prefix is maintained or dropped when referring to the custom property from a var() function, but didn't actually resolve. Discussion in the call leaned toward dropping the prefix, like I do currently with var-* properties, but some side discussion with Simon and Sylvain argued for using the full name, as there are confusing cases like "--0" or "----".

So, while I understand the potential confusion caused by authors possibly thinking that var() can take any property name as an argument, I think it's overruled by the confusion over what needs to be escaped in various circumstances. Escaping rules are always very confusing to authors, so I'm going to go with "use the custom property name literally as the var() argument".

Reference:

http://lists.w3.org/Archives/Public/www-style/2014Mar/0467.html

https://www.w3.org/TR/css-variables/#defining-variables

Answer 1

On top of avoiding clashing with vendor prefixes that begin with a single dash as mentioned by the other answers, keep in mind that the grammar for a CSS ident doesn't allow anything other than letters, numbers, dashes and underscores (see section 4.1.3 of CSS2). Were a custom property to be denoted by any other symbol, every existing CSS implementation would need to update or even rewrite its parser just to accommodate whichever symbol was being used for custom property names.¹

From the minutes of the telecon that's alluded to in the message, you can see that the hypothesis of avoiding clashing with vendor prefixes that begin with a single dash is true. The use of -- did require a minor parser change, because idents normally cannot start with double dashes (as klumme pointed out). I'm not sure exactly how existing implementations parse(d) declarations, but it's safe to assume that my reasoning still holds: since idents can start with one dash, consuming the first dash would not immediately result in a parse error, so a parser can determine if it's looking at a <property> or a <custom-property-name> (or then encounter a parse error if it doesn't support custom props) before deciding how it should proceed.

This change is also reflected in the css-variables spec, in section 2 (which I also cover here):

A custom property is any property whose name starts with two dashes (U+002D HYPHEN-MINUS), like --foo. The <custom-property-name> production corresponds to this: it’s defined as any valid identifier that starts with two dashes.

So dashes are used because they fit into the existing grammar with only minor parser changes, and double in particular to prevent clashing with vendor prefixes (note that dashes and underscores are interchangeable for vendor prefixes, so a single underscore wouldn't cut it either).

---

¹ _{As a matter of fact, I gave this very same reasoning in response to somebody else's question just a few weeks ago, although their question wasn't about the chosen prefix for custom prop names.}

Answer 2

I think that it was potentially related in some way to how vendors have their own prefix in which hyphen denoted attributes are ignored if they're not understood by the browser/parser. I think. It's also one way that wouldn't clash with any other CSS function or object that already exists.

For example preprocessors like LESS use the @ symbol whereas SASS uses the $ symbol. This was discussed over at the Software Engineering SE that has a pretty decent answer to go with it.

Essentially, it seems that it was for compatibility reasons above anything else. One could argue that it's also easy to denote what is a variable compared to other things like the & symbol and % symbol.

Here is some additional reading on the differences of CSS variables over on CSS Tricks which includes vanilla CSS, LESS and SASS etc.

Answer 3

My thinking is it has to do with backwards compatibility. When you add something to CSS, not only do you have to make sure the syntax can be parsed unambiguously, you have to make sure that the new feature will not affect how old browsers parse the parts of the stylesheet that they are actually able to understand.

As variables can be declared inside a rule set, one hyphen could cause confusion with vendor prefixes. And the class name in a class selector is actually not allowed to start with two hyphens, at least in the CSS 2.1 spec.