W3C home > Mailing lists > Public > www-style@w3.org > December 2015

[css-variables] The variable syntax - How about not using var() ?

From: Praveen Puglia <praveenpuglia@gmail.com>
Date: Fri, 25 Dec 2015 00:41:35 -0500
Message-ID: <CANfatsr+zK04pdZ=1RZYPpaxEuxVKnUsnOiOb53=-PJroaq9zA@mail.gmail.com>
To: www-style list <www-style@w3.org>
I am not really fond of the var() syntax and I made a tweet about it. I was
glad to get a reply from @csswg to post my response here. A formatted
version is available here

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
pre-processors 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 officialrecommendation 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 -

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 /* 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! :)

Praveen ✧ praveenpuglia.com ✧ @praveenpuglia
Received on Friday, 25 December 2015 05:42:23 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:59 UTC