Less.js: Запрос функции: поиск свойств (также известные как свойства — это переменные)

Каков ваш вариант использования? В текущем less.js вы можете поместить значение foo в переменную и добиться чего-то подобного.

Этот:

.test {
  <strong i="7">@foo</strong>: 200;
  foo: @foo;
  bar: <strong i="8">@foo</strong> / 2;
  .child {
    baz: @foo;
  }
}

компилируется в:

.test {
  foo: 200;
  bar: 100;
}
.test .child {
  baz: 200;
}

Если у вас есть случай, когда такой рефакторинг невозможен, было бы полезно, если бы вы разместили его здесь. Вообще говоря, less.js добавляет новые функции, когда какой-то вариант использования невозможен или слишком громоздок. Вариант использования поможет нам решить, насколько необходима такая функция (или мы могли бы найти другой способ добиться того, чего вы хотите).

Вариант использования будет заключаться в том, что вы можете создавать семантические контексты, например:

@gutter-width: 30px;
.row {
  margin-left: -(@gutter-width / 2);
  margin-right: -(@gutter-width / 2);

  .col-half {
    width: 50%;
    float: left;
    padding-left: -$margin-left;
    padding-right: -$margin-right;
  }
}

Поскольку в бутстрапе поля зависят от заполнения и наоборот, почему бы не соединить их напрямую, а не использовать одну и ту же переменную?

Вы бы удалили несколько ссылок на переменные и создали более связный модуль, который полагается на свой контекст, а не только на переменные. Ребята из Stylus, очевидно, видят в этом возможность использования, иначе они бы объявили это реликтом.

Другим примером могут быть окна предупреждений:

.alert {
  color: #f00;
  background: lighten($color, 25%);
}

Я думаю, что это не _необходимо_, а _приятно иметь_. Переменные могут выполнять эту работу, но прямые ссылки на свойства более удобочитаемы.

Конечно, совсем не обязательно. Мы работали с переменными годами, и это здорово. Особенно ленивая загрузка, которой не хватает любому другому препроцессору. Тем не менее, я хотел опубликовать это для рассмотрения.

Я согласен, что что-то вроде этого было бы интуитивно. Часто у меня есть начальное значение, установленное для свойства, и если я хочу использовать это значение в другом месте, оно должно быть реорганизовано в переменную, а затем повторно добавлено к свойству. Это предложение было бы проще для авторов.

Были похожие просьбы о том, чтобы части непосредственного дерева Less были доступны в виде структурированных данных, поэтому я за то, чтобы иметь больше «доступов» к тому, что вы уже написали.

Я вижу стремление слишком сильно раздуть язык, чтобы он больше не считался «гладким».

Относится к # 76 и # 6 - хотя этот подход проще. Это избавляет от бесполезного присвоения кода переменной и последующего чтения из нее.

Читая № 76, я обнаружил некоторые сходства, которые можно объединить, например, если вы background-color: lighten([color], 25%); , он будет искать текущее дерево предков. Однако, если вы напишете background-color: lighten(#mySpecialSelector[color], 25%); , вместо этого будет использоваться дерево предков селектора.

Это было бы действительно полезно и открывает совершенно новый уровень возможностей.

@lukeapage Как вы думаете, какое влияние окажет код? Если бы локальные (текущее дерево) свойства можно было изменить так, чтобы они вели себя аналогично локальным переменным, кажется, что это было бы не так уж важно (но вы бы знали лучше). Это могло бы придать языку определенную элегантность, поскольку люди могли делать:

.rectangle {
  width: 200px;
  height: ([width]/2);
}

Вместо:

.rectangle {
  <strong i="10">@width</strong>: 200px;
  width: @width;
  height: (@width/2);
}

Первый пример кажется более легким для чтения и ближе к замыслу автора. Лично я много раз писал код, подобный второму примеру, так что мне нравится эта идея.

Я думаю, что для локального поиска стоимость небольшая. Добавление селекторов может
привести к большей сложности синтаксического анализа. Столбцы css не используют квадратные скобки в
значения?

Нет, не столбцы css, надо будет подумать, где я это видел.

В значениях атрибутов используются квадратные скобки, поэтому, если мы включаем селекторы в поиск свойств, квадратные скобки не будут работать, потому что это допустимый селектор:

#mySpecialSelector[color] {
}
// matches:
<div id="mySpecialSelector" color></div>

Квадратные скобки соответствуют элементу с атрибутом «цвет». Мы могли бы быть более явными, используя что-то вроде prop().

.rectangle {
  width: 200px;
  height: (prop(width)/2);
}

Однако я знаю, что в прошлом мы пытались избежать ада вложенных скобок, так что... что, если мы объединим $ с нашим синтаксисом интерполированных переменных?

.rectangle {
  width: 200px;
  height: (${width}/2);
}
.example {
  background-color: lighten(${color}, 25%); 
  background-color: lighten(${color, #mySpecialSelector}, 25%);
}

Что-то такое? Таким образом, селекторы атрибутов действительны:

.parent[id] {
  height: 50%;
  .child {
    height: (${height, .parent[id]} / 2);
  }
}

Что вы ребята думаете?

Мне нравится ${color} .

На самом деле, если бы мы рассматривали ${} или любой другой синтаксис как «ссылку на дерево», мы могли бы решать такие проблемы, как #1075, с тем же синтаксисом:

.table .row .cell {
    ${.row}.editing  {}  // .table .row.editing .cell {}
}

... но я не хочу путать вещи. Просто идея.

Для нелокального поиска он напрямую связан с # 1848 (я думаю, сложная часть заключается только в создании согласованного синтаксиса, внутренне в дереве переменные и свойства обрабатываются почти идентично, поэтому все, что реализовано для первого, довольно легко расширяется для работы со вторым наоборот).

Однако, если вы пишете background-color: lighten(#mySpecialSelector[color], 25%); вместо этого он будет использовать дерево предков селектора.

Таким образом, у #mySpecialSelector не может быть предков (потому что если они есть, то на них нужно ссылаться с помощью *ancestor(s) #mySpecialSelector . Т.е. просто #mySpecialSelector может соответствовать только селектору верхнего уровня в глобальном область видимости (и/или опционально элемент с таким именем где-то выше текущей области видимости).Но опять же, я думаю, что часть пространства имен лучше обсудить в #1848 (различия между переменными и свойствами там должны быть только в синтаксисе (например, selector[@variable] и selector[property] ) _если_ это реализовано).

Кстати, есть идеи кроме $ и [] ?

Я думал о пространстве имен, когда обдумывал это. Технически это отличается, потому что мы (в настоящее время) говорим о поддержке ссылок в локальном дереве. Мы могли бы изначально отказаться от поиска селекторов и, как вы сказали, относиться к ним как к переменным. Если свойство не существует локально, перейдите к следующему родительскому блоку и так далее. На самом деле мы могли бы просто представить, что свойства являются переменными, хотя на них нужно ссылаться по-другому. Итак, если мы не поддерживаем ссылки на переменные пространства имен, то я думаю, что мы изначально не будем поддерживать свойства пространства имен. Но мы могли бы поддерживать импортированные свойства через миксин, так как это было бы то же самое, что и переменные. На самом деле... разве мы уже не делаем это, поскольку более поздние свойства переопределяют предыдущие?

Я хотел бы также ссылаться на переменные/свойства в пространстве имен. Это было бы потрясающе. И, как и в #1075, мы можем быть близки к синтаксису, достаточно гибкому, чтобы указывать на любое значение в любом месте AST. Но нам не пришлось бы реализовывать все это сразу.

Что касается специальных селекторов, я знаю, что мы пытались избежать введения дополнительных символов в этих проблемах, но я чувствую, что мы прыгали через обручи в # 1075 и # 1848, чтобы этого не делать. Например, в #1848 в конце я упоминаю такой синтаксис:

.box:after {
  content: "@{#ns > @content}";
}

Но, конечно, дополнительные @ в начале имеют смысл только в том случае, если я ссылаюсь на переменную в пространстве имен. Однако семантически он не преобразуется в ссылку на свойство, в то время как дополнительный символ, который является «поиском», является более гибким:

// property
.box:after {
  content: "${#ns > content}";
}
// or a variable
.box:after {
  content: "${#ns > @content}";
}

Итак, возможно, мы могли бы убить двух (возможно, 3) зайцев одним выстрелом и разбить задачи следующим образом:

• Шаг 1: Поддержите свойства как «vars» (с возможными исключениями)
• Шаг 2. Обратитесь ко второму примеру @krnlde , просто поддерживая ссылки на пространство имен, а не «локальные» селекторы: ${#mySpecialSelector > color}

Что касается альтернатив $ , я думаю, что мы должны ограничиться клавишей Shift и числовым рядом. Мы не можем использовать ! , @ , # , & , * , ~ , `` , as it either conflicts with CSS or Less. That leaves $ , % , ^ . I suppose there's a few more symbols on the keyboard, but if we're going to add one, $` был бы моим первым выбором.

А как насчет § , / и \ ?

\ используется для символов Unicode. Остальное должно быть хорошо. Доступно ли § на английской клавиатуре? У меня нет одного, чтобы проверить банкомат.

Доступна ли § на английской клавиатуре? У меня нет одного, чтобы проверить банкомат.

Э, нет. Понятия не имею, что это такое.

Это знак абзаца в (немецком) законе

Ах, верно, я думаю, что я видел это тогда. В любом случае, это не на клавиатуре.

Хорошо. Как я понял, повозившись, / не только громоздкий, но и непригодный для использования, так как это оператор деления в less, так что padding-top: /height//line-height; в любом случае не сработает. Так что, я думаю, мы пока придерживаемся $ ? Как padding-top: $height/$line-height; . Выглядит хорошо

Дох, боюсь, я бы тоже проголосовал за $ , потому что он кажется самым чистым и наименее конфликтным (хотя, честно говоря, я его очень ненавижу (без особой причины) и из-за этого каждый раз чувствую боль Мне нужно что-то написать на PHP :)

@seven-phases-max - Ха-ха, у меня была такая же внутренняя реакция, когда я впервые заговорил об этом, по тем же причинам. Однако в последнее время я стал более прагматичным и искажаю существующие символы, чтобы они обозначали больше вещей (как мы играли с @ и & ), чтобы избежать добавления новых. , или для того, чтобы ограничить себя набором символов CSS, может быть ненужной гимнастикой и не обязательно самым простым для понимания решением. Я думаю, что пользователю легче понять символы, если они имеют более четкое поведение. И у CSS нет определенного поведения, которое мы представляем, поэтому в некоторых случаях может быть неразумно кооптировать/переназначать символы CSS. Это, вероятно, противоречит многому из того, что я говорил в прошлом, но, как я уже сказал, я не уверен, что такая строгость всегда была необходима.

А также, относительно вашей точки зрения, если мы расширим существующее определение символа, мы можем загнать себя в угол, если захотим еще больше расширить использование.

Тем не менее, _поскольку_ это может быть новый метод символа / ссылки, я думаю, что стоит получить много входных данных / консенсуса для него.

Я понимаю, что в состоянии сделать это:

.rectangle {
  width: 200px;
  height: ${width} / 2;
}

может быть красиво, но это:

.example {
 color: lighten(${color, #mySpecialSelector}, 25%);
}

бесполезно сложно читать и управлять. Если бы кто-то дал мне такой фрагмент кода для работы, было бы очень утомительно и сложно выяснить, какой фактический цвет должен быть lighten .
Для меня это более или менее похоже на javascript, устанавливающий свойство узла DOM следующим образом:

var el1 = document.createElement('div');
var el2 = document.createElement('div');
el1.className = document.querySelector('mySpecialSelector').id + '25percent';
el1.className = document.querySelector('mySpecialSelector').id + '10percent';

вместо:

var CLASS_NAME = 'my-color-class';
var el1 = document.createElement('div');
var el2 = document.createElement('div');
el1.className = CLASS_NAME + '25percent';
el1.className = CLASS_NAME + '10percent';

Не знаю, дал ли я представление о том, что имею в виду. Но я думаю, что все это странно, по крайней мере для меня, и я бы не стал его использовать. В целом, я думаю, что переменные — это хорошая и надежная абстракция, которая уже покрывает все эти случаи. Усложнение языка не делает его более мощным. И сделать его менее читаемым тоже не поможет.
мой2с

это:

.example {
 color: lighten(${color, #mySpecialSelector}, 25%);
}

бесполезно сложно читать и управлять.

Я согласен. Вот почему я думаю, что эта часть, вероятно, достойна перемещения в ветку ссылок на пространство имен (# 1848), как предложил @seven-phases-max, и в любом случае ссылаться в формате пространства имен. Для этого конкретного потока единственной вещью в таблице должны быть ссылки на значения свойств.

@kuus , @matthew-dean согласился с этим. Может быть, слишком много.

Как насчет миксинов? Должны ли они искать _своего_ ближайшего родителя или то дерево, в котором они будут размещены? Не могу привести пример банкомата, я с мобильного - приведу позже, если нужно.

@kuus Mixins сначала ищет переменные в своих родителях. Если поиск не найден, поиск продолжается там, где он находится. Я думаю, что свойства должны работать одинаково: сначала искать определение примеси, а затем вызывающий.

:+1:

Итак, подытоживая текущее состояние дискуссии:

• Мы согласились использовать синтаксис интерполяции со знаком $: ${width} , хотя $width был бы короче, а первый не имеет преимуществ (может потребоваться дальнейшее обсуждение по мере продвижения).
• Мы позволяем свойствам искать только текущую область вверх. Селекторы, подобные следующим, не разрешены : height: ${width, .my-selector} или height: .my-selector${width} .
• Мы договорились, что ссылки на свойства в примесях будут сначала искать в дереве примесей, а затем — в случае неудачи — в дереве, в котором они размещены.

А как насчет любимой «ленивой загрузки» Less-variables? Какое влияние оказывает это знание на свойства?

@krnlde

На данный момент я бы ограничил список только: $width — относится к свойству width , ищущему из текущей области вверх.

(Пространство имен и синтаксис ${...} требуют дальнейшего обсуждения).

На данный момент я бы ограничил список только: $width - относится к свойству ширины, ищущему от текущей области видимости вверх.

Согласованный. Я поддерживаю использование обоих синтаксисов, поэтому логично начать с более «ограниченного» варианта, а затем прибить ${} .

Кстати, @krnlde , теперь я поддерживаю версию с пространством имен _вместо_ поиска селектора «внутри дерева», так как это кажется более гибким, но давайте начнем с $property и пойдем оттуда.

Все идет нормально. Как мы поступим?

Что ж, похоже, у нас есть достаточная поддержка со стороны участников, поэтому я чувствую, что мы можем пометить его как готовый к реализации, если только не возникнет веских возражений.

5 февраля 2015 г., в 12:20, Кай Доршнер (Kai Dorschner ) из [email protected] написал:

Все идет нормально. Как мы поступим?

—
Ответьте на это письмо напрямую или просмотрите его на GitHub.

Почему & не на столе? Насколько я знаю, Less не использует & , кроме как в селекторах. И плюс, я думаю, & лучше стоять для справки.

AFAIK, Less не использует & кроме селекторов.

Да пока. Но мы не должны красть символы из других возможных признаков (даже если они слишком далеко).

В настоящее время & является оператором конкатенации для селекторов и не используется для поиска. Эта проблема касается ссылок на свойства и обращения с ними как со ссылками на переменные, поэтому на данный момент концепции довольно далеки друг от друга.

& используется в качестве ссылки в некоторых языках программирования, таких как C++. Я больше согласен с мнением Макса о том, что мы могли бы использовать его, как Sass сейчас, в будущем:

.foo.bar .baz.bang, .bip.qux {
  $selector: &;
}

@ Seven-Phases-Max Я думаю, что мы должны с самого начала сделать так, чтобы область поиска примесей была первой. Язык легче изучать и читать, если он ведет себя последовательно. Меньший охват уже имеет слишком много правил, которые нужно помнить (imo), добавление нового специального правила не облегчит его.

Проще сказать, что «есть область видимости, и область видимости работает так», чем иметь немного разные области видимости для каждой функции (отдельный набор правил, свойства, переменные, поиск примесей). Изменить область видимости позже сложнее, чем сделать ее такой же, как уже существующая с самого начала.

Я думаю, что это:

#namespace() {
   padding-right: 2;
  .miniPadding() {
     padding-left: $padding-right - 1;
  }
}

.big-table {
   padding-right: 5;
  .sub-table {
    #namespace() > .miniPadding();
  }
}

должен скомпилироваться в:

.big-table {
   padding-right: 5;
}
.big-table .sub-table {
   padding-left: 1;
}

скомпилировать его следующим образом было бы просто запутанно/неожиданно и выглядело бы как ошибка:

.big-table {
   padding-right: 5;
}
.big-table .sub-table {
   padding-left: 4;
}

Кроме того, если переменные и область действия свойств ведут себя одинаково, то мы можем использовать точно такие же структуры и код для их обработки — и большинство ошибок в одном будет исправлено и в другом. Две разные области видимости (или три, если учитывать различия в отдельных наборах правил) означают поддержку двух похожих, но несколько разных алгоритмов, что сложнее.

Вы описываете нормальное поведение закрытия. Имеет смысл для меня.

@Соммери

Я думаю, что мы должны с самого начала сделать так, чтобы область поиска миксина была первой.

Но я написал точно так же :) ( Upd:. Эээ , я имел в виду "я имел в виду, что правила поиска свойств должны быть точно такими же, как и у переменных", (более того, я знаю, что они уже _являются_ одинаковыми в компиляторе, потому что это тот же код, который обрабатывает переменные и свойства (с несколькими второстепенными if s)).

поиск от текущей области вверх.

является точной цитатой из Variables > Lazy-Loading .

Если говорить о вашем примере, то он довольно несчастлив. Потому что тот же пример с переменными переходит в #1316 и результат padding-left: 4; . Я понимаю, почему вы использовали там #namespace() , но со всеми проблемами «параметрического пространства имен» это может быть довольно запутанным. Нам нужен какой-то другой пример (потому что именно в вашем лучше использовать переменные вместо свойств).

PS Странное дело: за последние три дня выскочило четыре вопроса, напрямую связанных с №1316 (№2435, №2350, №2436 и теперь ваш пример) Это какой-то заговор? :)

@ Seven-Phases-Max Я неправильно тебя понял и забыл о # 1316. Извините за обоих :).

Все эти четыре проблемы являются одной и той же основной проблемой? Как вы думаете, легко/сложно это исправить? Я пока не хочу вносить серьезные изменения в less.js (слишком мало знаю о его масштабах), но я ищу что-то легкое или среднее, что можно исправить.

Мне одному кажется, что все это дело ненужное и делает язык более сложным и менее читабельным? Какую именно выгоду вы ищете?
Когда я читаю объявление стиля, я не хочу сходить с ума, чтобы понять, откуда берется значение свойства. Как и сейчас, это должно быть обычное значение или переменная, или максимум встроенный расчет, использующий переменные. Вот и все. Это делает использование препроцессоров css приятным. То, что вы предлагаете, - это своего рода динамический способ определения переменных, что просто странно. Я не понимаю, как разработчики javascript не могут согласиться с тем, что это странно.

Определенно я согласен с @SomMeri, когда он говорит

Меньший охват уже имеет слишком много правил, которые нужно помнить (imo)».

И я думаю, что его пример кода https://github.com/less/less.js/issues/2433#issuecomment -73202522 независимо от того, во что он компилируется, он слишком запутан.

Определение от Stylus :

Поиск недвижимости

Еще одна интересная функция, уникальная для Stylus, — это возможность ссылаться на определенные свойства, не присваивая их значения переменным. Отличным примером этого является логика, необходимая для вертикального и горизонтального центрирования элемента (обычно это делается с использованием процентов и отрицательных полей, как показано ниже): ...

Таким образом, чтобы зафиксировать вариант использования, который я описал ранее, вы можете сократить определения, сохранив переменные, плюс это более лаконично, поскольку вы связываете свойства напрямую, а не через переменные:

.mySquare {
  width: 200px;
  height: $width;
}
.myRectangle {
  width: 500px;
  height: $width / 2;
}

Просто прочитав height: $width; , все точно знают, что там происходит - это квадрат, несмотря ни на что.

Обсуждение вложенности и необходимость поиска всех родительских селекторов следует обсуждать в другом месте (#1848).

@kuus

Ну, мое участие ограничивается только болтанием и криком, если какой-то предложенный синтаксис/поведение выходит из-под контроля :) На самом деле я ни за, ни против этого (я не буду возражать, потому что это летало с самых ранних Меньше дней (это было даже (частично?) реализовано в начальной версии Ruby), и я знаю, что это не должно обременять компилятор, если мы не начнем изобретать безумные синтаксические конструкции... Также я знаю, что тот факт, что функция получает свое «ReadyForImplementation», не означает это на самом деле будет реализовано в ближайшее время... ;)

@Соммери

Все эти четыре проблемы являются одной и той же основной проблемой? Как вы думаете, легко/сложно это исправить?

Да, это одна и та же основная проблема, но в большинстве случаев она больше связана с разными ожиданиями того, как эти вещи должны работать (как должна работать область видимости и как она работает на самом деле), а не с кодом, который страдает от #1316 . Мы обсудили возможные способы исправить сам #1316 вокруг https://github.com/less/less.js/issues/2212#issuecomment -57281241 (не так просто, но, вероятно, возможно), но эти проблемы (half-issues/half-feature -requests), о которых я упоминал (кроме вашего примера выше, конечно), на самом деле просят исправить это противоположным образом или предоставить для этого бэкдор (таким образом нарушая текущее поведение Less, хороший пример — # 2435).

@krnlde извините за неправильное упоминание...

Когда я читаю объявление стиля, я не хочу сходить с ума, чтобы понять, откуда берется значение свойства. Как и сейчас, это должно быть обычное значение или переменная, или максимум встроенный расчет, использующий переменные. Вот и все. Это делает использование препроцессоров css приятным. То, что вы предлагаете, - это своего рода динамический способ определения переменных, что просто странно. Я не понимаю, как разработчики javascript не могут согласиться с тем, что это странно.

Я думаю, вы, вероятно, неправильно понимаете. Здесь не предлагается ничего, что было бы динамическим способом определения переменных. На самом деле это кажется очень интуитивным шагом по нескольким причинам.

Переменные в Less возникли непосредственно (или были вдохновлены) поведением свойств. В некоторых препроцессорах, если вы присваиваете переменную, а затем читаете ее, затем присваиваете, а затем читаете, и все это в одной и той же области, вы получите другой результат. В Less поведение похоже на свойства CSS: выигрывает последнее объявление в области видимости. Итак, прямо сейчас переменные и свойства во многом пересекаются. Если вы вызываете миксин, вы получаете не только его свойства, но и его переменные. И вы действительно можете делать такие вещи, как добавлять свойства вместе (или, скорее, добавлять их значения) с синтаксисом property+: и property+_: . Единственное, что вы пока не можете сделать, это сослаться на свойство.

Таким образом, переменные должны вести себя как свойства, а свойства эволюционировали, чтобы вести себя во многом как переменные. В конце концов, вы присваиваете значение ключу. У нас есть способ сослаться на значение для одного типа ключа, и то, что предлагается здесь, — это просто способ сослаться на значение для другого типа ключа.

Меньше области охвата уже имеет слишком много правил, которые нужно помнить (imo)

Не было бы никаких дополнительных правил области видимости, которые нужно помнить. Эти два блока станут функционально эквивалентными с точки зрения области видимости.

.block {
  <strong i="15">@height</strong>: 10px;
  width: <strong i="16">@height</strong> / 2;
}
.block {
  height: 10px;
  width: $height / 2;
}

Разница в том, что высота выводится как свойство во втором блоке. Но масштаб не меняется.

Или, как это можно сказать в TL;DR: свойства в Less, по большому счету, уже действуют как переменные, но вы не можете ссылаться на них. Эта функция позволит ссылаться на свойства.

Другой способ продемонстрировать вышеизложенное:

//Less
.block {
  <strong i="7">@height</strong>: 10px;
  width: <strong i="8">@height</strong> / 2;
  <strong i="9">@height</strong>: 20px;
}
// output
.block {
  width: 10px;
}
//Less w/ property reference
.block {
  height: 10px;
  width: $height / 2;
  height: 20px;
}
//output
.block {
  width: 10px;
  height: 20px;
}

Пример @krnlde вдохновил на создание другой демонстрации:

.square(@width) {
  height: @width;
}
<strong i="7">@row</strong>: 100px;
.column-2 {
  width: <strong i="8">@row</strong> / 2;
  .square($width);
}
.column-4 {
  width: <strong i="9">@row</strong> / 4;
  .square($width);
}


// output
.column-2 {
  width: 50px;
  height: 50px;
}
.column-4 {
  width: 25px;
  height: 25px;
}

Это полезная функция, в моем случае мне нужно было расширить только некоторые определенные свойства из другого класса (этот класс определен во внешней таблице стилей, поэтому для использования переменных мне пришлось бы изменять эту таблицу стилей в каждой новой версии, которую они публикуют)

С этим новым синтаксисом я мог бы сделать это так:

Таблица стилей.less предоставлена ​​из другого источника:

.divheader{
   height:50px;
   color: red;
   line-height: 1.5;
   width: 100px;
}

Моя таблица стилей.less:

.mydivheader{
   .divheader.height; //invented syntax
   .divheader.line-height; //invented syntax
   color: black;
}
//output
.mydivheader{
   height:50px; //inherited
   line-height: 1.5; //inherited
   color: black;
}

Так что я наследую только свойства высоты и высоты строки класса divheader...

@ase69s ase69s В вашем случае нам нужно будет обратиться к ссылочным переменным в наборах правил. См. № 1848. По сути, эта функция заставит присваивание свойств вести себя (несколько) как присваивание переменных (хотя и с другим синтаксисом ссылок), поэтому ваш случай не произойдет до того, как будет рассмотрен # 1848.

Если / когда будет реализовано, я бы увидел, что синтаксис немного ближе к этому:

.divheader{
   height: 50px;
   color: red;
   line-height: 1.5;
   width: 100px;
}
.mydivheader {
  height: ${.divheader > height};
  line-height: ${.divheader > line-height};
  color: black;
}

Однако, поскольку вы ничего не рассчитываете, прямо сейчас вам доступно несколько других вариантов, например:

<strong i="11">@divheader</strong>: {
  height: 50px;
  line-height: 1.5;
};
.divheader{
  @divheader();
   color: red;
   width: 100px;
}
.mydivheader {
  @divheader();
  color: black;
}

Вы также можете иметь миксин, который устанавливает свойства, или использовать :extend в общем наборе правил. Таким образом, вместо того, чтобы напрямую ссылаться на другой класс, вы можете иметь два элемента div, ссылающихся на другой отдельный набор правил или миксин.

+1 Я полностью согласен с Юстинео :
«_Я думаю, что это не обязательно, но приятно иметь. Переменные могут выполнять эту работу, но прямые ссылки на свойства более читабельны._»

Я бы сказал, что это более чем приятно иметь. У меня есть сайт, который позволяет вам создавать скины, выбирая цвет отделки, который управляет кнопками, ссылками и другими элементами. Это хранится в базе данных и загружается на страницу с помощью тега <style> в заголовке как класс «обрезка». Но поскольку это значение жестко закодировано, у меня нет простого способа сослаться на него, чтобы делать такие вещи, как создание выцветших версий того же цвета по запросу, и я бы предпочел не использовать JS для стилизации...

В нынешнем виде мне придется вручную выбирать варианты цвета отделки не в тени и также назначать их классам, но даже в этом случае у меня нет очень простого контроля над тем, КАКИЕ свойства будут применены к выцветшему цвету отделки. (например, границы), внутренний фон и т. д.

@jlem Уже идет PR (над которым я работал - https://github.com/less/less.js/pull/2654), и в основном работает, но есть несколько небольших проблем, которые нужно сгладить. Интересный вариант использования, но здесь он неприменим, так как другие стили не будут доступны для Less.

Эта проблема была автоматически помечена как устаревшая, поскольку в последнее время с ней не было никаких действий. Он будет закрыт, если никакой дальнейшей активности не произойдет. Спасибо за ваш вклад.

Обратите внимание, что простая ссылка на свойство ( $prop ) реализована, но не задокументирована (AFAIK).