4 ms·

That new syntax is astonishingly ugly and bizarre. I'm sure it'll be a real joy to use that for anyone who's been using Sass or Less (and who doesn't, these da

That new syntax is astonishingly ugly and bizarre. I'm sure it'll be a real joy to use that for anyone who's been using Sass or Less (and who doesn't, these days...).

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.
ibotty 12y ago
`--` is a comment in many languages (sql, haskell, ..).
- bshimmin 12y ago
  And of course it's a decrement operator in many others! It doesn't seem at all intuitive as a sigil to use for this purpose.

That new syntax is astonishingly ugly and bizarre. I'm sure it'll be a real joy to use that for anyone who's been using Sass or Less (and who doesn't, these days...).

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.

ibotty 12y ago

`--` is a comment in many languages (sql, haskell, ..).

bshimmin 12y ago
And of course it's a decrement operator in many others! It doesn't seem at all intuitive as a sigil to use for this purpose.