Were there any technical limitations in CSS that led to the decision to use `-` for vars?

Question

With the introduction of css vars, I would like to know why the argument -- was chosen as a way of noting var.

Given that CSS has a semi-special function calc , it seems to me that -- can be easily confused for the decrement operator in other languages.

I am curious if there is any historical significance or technical limitations that led to the choice. The double, in particular, puzzles me when CSS markers are usually singles (#,., @ Etc). It is also useful to use a character already used by other things (especially when its value for the class name begins 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); } } 

Renouncement

Some may argue the truth of this question, but understanding why is a key method of remembering a specific concept.

The only discussion I can find is related to it:

At telcon today, we decided to use the "-" prefix to indicate custom properties and other custom things.

We discussed whether the prefix is ​​supported or not when referencing a custom property from the var () function, but does not actually solve it. The discussion in the call leaned toward a prefix, as it is currently with var- * properties, but on some sides the discussion with Simon and Sylvanas claimed that they used the full name because there are confusing cases, such as "-0" or "- - "

So, although I understand the potential confusion caused by the authors perhaps by thinking that var () can accept any property name as an argument, I think this reversed the confusion that one needs to escape in various circumstances. Escape rules are always very confusing for the authors, so I'm going to go with "use the regular property name literally as the var () argument.

Link:

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

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

Answer 1

Instead of avoiding collisions with vendor prefixes that start with a single dash, as mentioned by other answers, keep in mind that the grammar for the CSS identifier allows nothing but letters, numbers, dashes, and underscores (see section 4.1.3 in CSS2). If a custom property were denoted by some other character, every existing CSS implementation would have to update or even rewrite its parser just to accommodate any character used for custom property names. ¹

From the minutes of the newsgroup referenced by the message, you can see that the hypothesis of avoiding collisions with vendor prefixes that start with a single dash is true. Usage -- required a lower parser change because idents usually cannot start with double dashes (as klumme pointed out). I'm not sure exactly how existing implementations analyze (d) declarations, but I can safely assume that my reasoning is still valid: since idents can start with a single dash, using the first dash will not immediately lead to a parsing error, so the parser may determine if he is looking at <property> or <custom-property-name> (or then encounters a parsing error if he does not support his own details) before deciding how he should act.

This change is also reflected in the css-variables specification, in section 2 (which also covers here ):

A custom property is any property whose name begins with two dashes (U + 002D HYPHEN-MINUS), for example --foo . <custom-property-name> this matches: it is defined as any valid identifier starting with two dashes.

Thus, dashes are used because they fit into the existing grammar with minor parser changes and, in particular, are doubled to prevent collision with provider prefixes (note that dashes and underscores are interchangeable for provider prefixes, so one underscore will not cut it is too).

---

¹ _{Actually, I gave this very argument in response to some other question just a few weeks ago, although their question did not concern the selected prefix for custom names prop.}

Answer 2

I think that this was somehow related to the way providers have their own prefix in which hyphenated attributes are ignored if they are not understood by the browser / parser. I think. This is also one of the ways that would not contradict any other CSS function or object that already exists.

For example, preprocessors such as LESS use the @ character, while SASS uses the $ character. This was discussed in Software Engineering SE , which has a pretty decent response to go with it.

In essence, it seems that this was, for compatibility reasons, above everything else . It can be argued that it is also easy to indicate what a variable is compared to other things, such as the & symbol and the % symbol.

Below is an additional reading on the differences between CSS variables in CSS tricks, which include vanilla CSS, LESS and SASS, etc.

Answer 3

I think this is due to backward compatibility. When you add something to CSS, you not only need to make sure that the syntax can be parsed unambiguously, you need to make sure that the new function will not affect the way older browsers parse parts of the stylesheet that they really can understand.

Because variables can be declared within a rule set, a single hyphen can cause confusion with vendor prefixes. And the class name in the class selector is actually not allowed to start with two hyphens, at least in the CSS 2.1 specification .