Строго не возможно
См. документацию по переменным LESS. По сути, переменные LESS являются константами в области их создания. Они лениво загружаются и не могут быть "изменены" таким образом. Самое последнее определение будет использоваться для всех в этой области. В вашем случае произойдет ошибка, потому что переменные не могут ссылаться сами на себя.
Рассмотрим этот пример:
@counter: 1;
.someSelector("nameOfClass", @counter);
@counter: 2;
.someSelector("nameOfClass1", @counter);
.someSelector(@name; @count) {
@className: ~"@{name}";
.@{className} {
test: @count;
}
}
Вывод будет 2
для обоих:
.nameOfClass {
test: 2;
}
.nameOfClass1 {
test: 2;
}
Это связано с тем, что LESS определяет @counter
с последним определением переменной в этой области. Он не обращает внимания на порядок вызовов с использованием @counter
, а скорее действует так же, как CSS, и принимает во внимание "каскад" переменной.
Для дальнейшего обсуждения этого в LESS вы можете отслеживать обсуждение, происходящее в этом запросе функции LESS< /а>.
Решение находится в Recursive Call Setter для локальной переменной
Seven-phases-max связан с тем, что он считает ошибкой в LESS , но я так не думаю. Скорее, мне кажется, что это творческое использование рекурсивного сброса счетчика для получения желаемого эффекта. Это позволяет вам достичь того, чего вы хотите (используя мой пример кода):
// counter
.init() {
.inc-impl(1); // set initial value
} .init();
.inc-impl(@new) {
.redefine() {
@counter: @new;
}
}
.someSelector(@name) {
.redefine(); // this sets the value of counter for this call only
.inc-impl((@counter + 1)); // this sets the value of counter for the next call
@className: ~"@{name}";
.@{className} {
test: @counter;
}
}
.someSelector("nameOfClass");
.someSelector("nameOfClass1");
Вот вывод CSS:
.nameOfClass {
test: 1;
}
.nameOfClass1 {
test: 2;
}
ПРИМЕЧАНИЕ. Я полагаю, что здесь вы не строго меняете глобальное значение, а устанавливаете новое локальное значение при каждом вызове .someSelector
. Сомнительно, основано ли это на ошибочном поведении или нет, но если это так, это решение может исчезнуть в будущем. Чтобы получить дополнительные комментарии об ограничениях этого метода, см. обсуждение здесь.
person
ScottS
schedule
25.11.2013