2 ms·
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 uncerta
by 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 agoI 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); }