5 ms·

Yeah, obviously they need to avoid conflicts but surely they could have found a single character to use as a prefix instead of "--", like "$" or "@". The "var(

by galvin 12y ago

Yeah, obviously they need to avoid conflicts but surely they could have found a single character to use as a prefix instead of "--", like "$" or "@". The "var()" function is just.. redundant. Or maybe I'm missing something?

colinramsay 12y ago
Here's the discussion where they changed from "var-" to "--": http://lists.w3.org/Archives/Public/www-style/2014Mar/0261.html http://lists.w3.org/Archives/Public/www-style/2014Mar/0261.h... And later on the justification for not using $ or @: http://lists.w3.org/Archives/Public/www-style/2014Mar/0400.html http://lists.w3.org/Archives/Public/www-style/2014Mar/0400.h... There's also the issue that this needs to be backwards compatible with parsers that don't support the syntax, and apparently because the variables cascade that makes it harder still. I agree it's ugly though.
- evolve2k 12y ago
  From the second link in parent: "> As far as I understand, the main reason of why Tab's original idea of using `$` has eventually been dropped was some uncertainty about its possible extensibility for being used in property _names_ besides property _values_. The reason it got dropped is that some people (including Tab) do believe we should reserve $ for mixins and other preprocessor-like operations which may potentially be added to the language at some point. e.g. futuristic things like: @define apply-2d-transform(initial-scale, initial-rotation, ...) { ... my-transform-scaling: $initial-scale; my-transform-rotation: $initial-rotation; ... transform: scale(get(my-transform-scaling)) rotate(get(my-transform-rotation)) translate(get(my-transform-translation)); will-change[]: transform; } .some-element { $apply-2d-transform(...); transition[]: transform 0.5s ease-in-out; } .some-element:hover { my-transform-scale: 1.1; } but this syntax was just made for this example, final milage may look completely different and/or offer different features)"
  - tyleregeto 12y ago
    I don't get that argument. Sass manages to avoid $ conflicts while using it for both variables and mixins. Its nice clean, consistent syntax. I don't see why we need different syntax for the two. Eg: $myColor: #fff; a { color: $myColor; } @mixin border-radius($radius) { -webkit-border-radius: $radius; -moz-border-radius: $radius; -ms-border-radius: $radius; border-radius: $radius; } .box { @include border-radius(10px); }
- riffraff 12y ago
  where is the discussion for using `var()` ? The rationale for the "--" sigil matches what I'd expected, but I don't understand: why not just `name: --value` ?
- IgorPartola 12y ago
  This is just stupid. Here are some sigils they could have easily used without much issue: #, *, +. They could have also used something like [var-name] or <var-name>. I am convinced that at this point CSS is a clusterfuck that should be killed with fire.
  - aquanext 12y ago
    And one thing we should kill it with is GSS. (http://gridstylesheets.org http://gridstylesheets.org) Watch the video!
- luikore 12y ago
  Variable is a BIG change in CSS. If a browser doesn't support variable, then new stylesheets are already broken in that browser. It makes little difference to make the syntax compatible. Once an easy-to-use syntax is published, toolchains that parse CSS will update as fast as they can! But "--"? Everybody will stick to the old standard and never want to upgrade.

by galvin 12y ago

colinramsay 12y ago

Here's the discussion where they changed from "var-" to "--": http://lists.w3.org/Archives/Public/www-style/2014Mar/0261.html http://lists.w3.org/Archives/Public/www-style/2014Mar/0261.h... And later on the justification for not using $ or @: http://lists.w3.org/Archives/Public/www-style/2014Mar/0400.html http://lists.w3.org/Archives/Public/www-style/2014Mar/0400.h... There's also the issue that this needs to be backwards compatible with parsers that don't support the syntax, and apparently because the variables cascade that makes it harder still. I agree it's ugly though.

evolve2k 12y ago
From the second link in parent: "> As far as I understand, the main reason of why Tab's original idea of using `$` has eventually been dropped was some uncertainty about its possible extensibility for being used in property _names_ besides property _values_. The reason it got dropped is that some people (including Tab) do believe we should reserve $ for mixins and other preprocessor-like operations which may potentially be added to the language at some point. e.g. futuristic things like: @define apply-2d-transform(initial-scale, initial-rotation, ...) { ... my-transform-scaling: $initial-scale; my-transform-rotation: $initial-rotation; ... transform: scale(get(my-transform-scaling)) rotate(get(my-transform-rotation)) translate(get(my-transform-translation)); will-change[]: transform; } .some-element { $apply-2d-transform(...); transition[]: transform 0.5s ease-in-out; } .some-element:hover { my-transform-scale: 1.1; } but this syntax was just made for this example, final milage may look completely different and/or offer different features)"
- tyleregeto 12y ago
  I don't get that argument. Sass manages to avoid $ conflicts while using it for both variables and mixins. Its nice clean, consistent syntax. I don't see why we need different syntax for the two. Eg: $myColor: #fff; a { color: $myColor; } @mixin border-radius($radius) { -webkit-border-radius: $radius; -moz-border-radius: $radius; -ms-border-radius: $radius; border-radius: $radius; } .box { @include border-radius(10px); }
riffraff 12y ago
where is the discussion for using `var()` ? The rationale for the "--" sigil matches what I'd expected, but I don't understand: why not just `name: --value` ?
IgorPartola 12y ago
This is just stupid. Here are some sigils they could have easily used without much issue: #, *, +. They could have also used something like [var-name] or <var-name>. I am convinced that at this point CSS is a clusterfuck that should be killed with fire.
- aquanext 12y ago
  And one thing we should kill it with is GSS. (http://gridstylesheets.org http://gridstylesheets.org) Watch the video!
luikore 12y ago
Variable is a BIG change in CSS. If a browser doesn't support variable, then new stylesheets are already broken in that browser. It makes little difference to make the syntax compatible. Once an easy-to-use syntax is published, toolchains that parse CSS will update as fast as they can! But "--"? Everybody will stick to the old standard and never want to upgrade.