Skip to content

Instantly share code, notes, and snippets.

Embed
What would you like to do?

Thanks for replying to me! :)

I really didn't know about the recommendation process back then. It's pretty recent that I came to know about it. I am not sure if any of the suggestion helps at the moment since it's now a recommendation.

I am also sure that the working group must have thought about exhaustive scenarios so I may not even be making a point.

I know $ or @ couldn't be used since they were already getting used in preprocessors and @ specifically, I feel, wouldn't go with the existing syntax of CSS.

I met Chris Lilley few days ago and I came to know that $ could be used but it would create multiple problems.

  • Breaks existing preprocessor syntax. I would be okay with it as long as the working group released an official recommendation with that and Sass sort of stopped using it or came up with a feature flag to use either Sass variables or Native CSS variables.

  • Users would get confused about Sass variables and CSS variables.

What about not using var() at all?

As far as I can say( and that's not too far ) I don't see a problem in using --variableName in RHS and getting it's value evaluated. If it's on L.H.S it just assigns whatever is on the R.H.S.

Example -

:root {
    --primaryColor : blue; /* Assignment/Storage*/
}

a {
    color : --primaryColor; /* Evaluation */
}

Other cases are I think ruled out via this example - http://www.w3.org/TR/css-variables/#example-3ab19e31

Would the parsing lead to ambiguous situations? If so, can you please provide an example so I can understand it better. Again, I am a noob.

I don't see it being an issue with calc() either since you the operators inside require space around them. The following could work.

:root {
    --fakePadding : 10px;
}
li {
    width : calc(50px - --fakePadding);
}

With -- before variable name, it feels like it used an extra character which it shouldn't be. How about some other characters?( No idea if they impact CSS parsing.)

=foo /* It's a little weird too */
&foo 
/* OR A COMBINATION OF TWO THINGS?*/ 
--foo /* sets the variable and...*/ &foo /* get's it? */

I am really unaware of other usecases but would love to know where some of these can fail and why they are bad. That would be so much wisdom! :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment