[evolve2k]

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]

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); }