Less.js: Как заниматься математикой

Я не думаю, что мы хотим что-то кардинально менять или возвращаться к чертежной доске

Да, я предложил начать это только потому, что _ если_ нам нужна «стандартная» строгая математика в 3.0, нам придется изобрести что-то менее тяжелое, чем текущее (и возможность исправить все проблемы, не вводя никаких новых --alt-strict-math Вариант font -подобным решением жесткого кодирования ...).

Я не понимал, что он растет

https://developer.mozilla.org/en-US/docs/Web/CSS/border-radius

:(

Я думаю, что на данный момент я за то, чтобы изначально расширить strictMaths, чтобы

• Выключенный
• Разделение
• На

а затем для 2.0.0 установка по умолчанию на Division

Так..

Медиа-запросы - если выключено, переключиться в разделение на подузлы
Шрифт - если выключен, перейти в разделение для подузла
calc (- если выключено или деление, включить для подузлов

https://developer.mozilla.org/en-US/docs/Web/CSS/border-radius

Да, я думаю, они хотят разрешить "сокращенные значения" (например, x/y ) в _any_ "сокращенных свойствах" ...

связанные: https://github.com/less/less.js/issues/1480

Другой вариант ... обрабатывать вызовы calc, но только там, где это возможно, например,
расчет (1% + 2%) => 3%
calc (100% - 10 пикселей) => без изменений

Это исправит calc но не исправит # 1627 и подобные вещи.
Я имею в виду, что да, calc(100% - 10 px) => unchanged может быть решением для calc но это не отменяет необходимости в решении less-heavy-than-parens-everywhere .

Если строгая математика пересматривается, я хотел бы предложить, чтобы функции Less, такие как percentage() не требовали дополнительных скобок внутри них. При строгой математике вам придется дважды обернуть аргумент. Это значительно снизит вероятность путаницы и ошибок, которые трудно найти, поскольку будут действительны как percentage(16 / 17) и percentage((16 / 17)) .

@calvinjuarez V2 предоставляет подсистему плагинов, в которой плагин может добавлять произвольное количество функций в среду, и в этом смысле ядро ​​не сможет решить, ожидает ли такая встроенная функция единственное значение или выражение, т.е. разрешено принимать 16/17 , а затем оценивать 16/17 _before_ перед передачей функции было бы некорректно (ну, грубо говоря - это немного сложнее, чем внутренне).

В этом контексте изменение ./ кажется моим любимым, хотя я понимаю, что это было бы очень драматическое изменение (по сравнению с (/) , не считая этого, также требуется пробел перед . , например, 16 ./17 а не 16./17 , хм).

Еще одна вещь, где в настоящее время меньше работает действительный css, - это сокращение фона:

background: url(image.png) 50%/300px no-repeat;

Я думаю, что на данный момент я за то, чтобы изначально расширить strictMaths, чтобы

Выключенный
Разделение
На
а затем для 2.0.0 установка по умолчанию на Division

Извините, я не ответил на это до выпуска 2.0. Я думаю, это хороший инстинкт. Операторы голого деления просто конфликтуют со слишком большим количеством CSS и будут конфликтовать все больше и больше по мере того, как люди будут использовать все больше функций CSS3. И я понимаю, что люди возражают против того, чтобы не требовать паренсы для всей математики, поскольку во многих случаях это не требуется.

@ семь фаз-макс

разрешено принять 16/17, а затем оценка 16/17 перед передачей в функцию будет неправильной

Собственно говоря, да, это абсолютно правильно. Это не должно оцениваться ДО того, как оно достигнет функции, особенно для пользовательской. Однако я думаю, что было бы разумно разрешить функциям обрабатывать такие аргументы, если это имеет смысл. Итак, процент получит 16/17 в качестве текстового аргумента, а затем процентная функция может вызвать некоторую вспомогательную функцию, чтобы узнать, является ли текст математическим. В случае с процентами аргумент не является двусмысленным. Объявление CSS3 здесь недействительно. Таким образом, другие определяемые пользователем функции могут работать таким же образом: выбрать оценку аргументов для правильных математических уравнений. Следовательно, в данном случае не всегда верно, что строгая математика «заставляет» заключать двойные скобки. Я думаю, это вызывает некоторое сопротивление идее строгой математики, что она должна, по необходимости, быть многословной во всех случаях.

Наши параметры --math могут быть больше похожи на:

• Всегда
• Деление (по умолчанию)
• Строгий

Итак, мы могли бы отказаться от --strict-math = true и сделать его псевдонимом для --math = strict

Однако я думаю, что было бы разумно разрешить функциям обрабатывать такие аргументы, если это имеет смысл.

Они уже разрешены (просто проверьте, как percentage(16 / 17) и percentage((16 / 17)) работают с --strict-math=on ).
Хотя ни одна из функций не использует:

а затем процентная функция может вызвать некоторую вспомогательную функцию, чтобы узнать, является ли текст математическим.

просто потому, что в этом случае каждая функция должна иметь эти ~ 20 дополнительных строк этого extra-helpers-conversion-arg-verify-smart-arg-handle-stuff, в то время как собственный код функции в большинстве случаев представляет собой всего одну (!) строку.

У каждой функции должно быть 20 лишних строк? Как ты рассчитываешь?

Если проценты уже работают с одинарными круглыми скобками, в которых используется строгая математика, то я не понимаю проблемы @calvinjuarez . Вы, кажется, имели в виду в своем ответе, что одинарные скобки недостижимы.

У каждой функции должно быть 20 лишних строк? Как ты рассчитываешь?

Это просто типичное преувеличение: может быть, 5, может быть, 10, может быть 20 ... Кого волнуют точные числа, если соотношение реальный код / ​​вспомогательный код -> 0 . (Принимая прагматичный подход, я бы остановился на percentage(16 / 17) просто выдав ошибку вместо создания NaN% (как сейчас) и не пытаясь выполнить какое-либо преобразование ... Хотя даже в этом случае это все еще 4 лишних строчки кода - ну, я думаю, менее или более приемлемо :)

Мой первоначальный ответ подразумевал, что он предполагает, что это преобразование 16/17 -> (16/17) должно выполняться неявно самим компилятором (а не функцией).

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

Я просто подумал, что это будет что-то вроде:

percentage: function(...) {
  Helper.convertMath(arguments);  // a function that doesn't need it doesn't call it
  // ... the rest
} 

Кстати о вариантах. В идеальном мире я бы мечтал, что для этого не будет вообще никаких вариантов

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

Helper.convertMath(arguments);

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

some: function(a, b, c) { 
    a = convert2number(a, "Error message when fails"); 
    // b is not a number for example
    c = convert2number(c, "Error message when fails"); 
} 

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

Да, я тебя понимаю.

percentage(16 / 17) просто выдает ошибку

было бы улучшением, конечно. (Я не могу придумать, чтобы NaN% был полезным выводом.)

Что касается того, какие функции будут пытаться продумать свои аргументы, нет причин пытаться все предвидеть. Вспомогательная функция, как предлагает @ matthew-dean, могла бы быть реализована довольно просто, поскольку запросы функций делаются и обсуждаются, чтобы конкретные функции были умнее.

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

Изменить: На самом деле, всякий раз, когда математической функции передается только один аргумент.

Какой статус по этому поводу? Мы получаем жалобы на то, что LESS пытается анализировать недопустимые свойства CSS как математические. например, lost-column: 1/3; ломается.

Также кажется, что http://www.w3.org/TR/css-grid-1/#grid -template-rowcol не будет работать с LESS.

Может ли кто-нибудь исправить это, чтобы, если кто-то явно хочет использовать LESS для деления свойства, ему нужно обернуть его в скобки или что-то в этом роде?

@corysimmons Разве вы не спросили об этом на # 2769 и получили ответ? о_О

Одна вещь, которую мы не обсуждали, когда это произошло в первый раз. Кажется, что единственный настоящий математический конфликт - это разделение. И разделение - это, по сути, проблема, потому что мы, по сути, «перепрофилируем» символ «разделения» CSS.

Вместо того, чтобы пытаться «обернуть» деление любым количеством способов или обернуть всю математику (как наше первое решение этой проблемы), мне интересно, почему мы никогда не говорили об очевидном: _не переделывать существующий оператор в первую очередь_, особенно когда он так ясно: а) делает код Less двусмысленным, б) вызывает конфликт.

После того, как у нас было время переварить это, заключая математику в круглые скобки, даже если это всего лишь деление, _ по-прежнему_ вызывает двусмысленность в тех случаях, когда математика уже заключена в круглые скобки. (Что также могло означать, что круглые скобки были неправильным выбором «математической оболочки».)

Так почему бы не отказаться от / как оператора деления? Я знаю, что это общий символ деления, но есть и другие синтаксические компромиссы, которые Less сделал для расширения CSS. И теперь мне ясно, что мы в основном пытаемся обойти проблему, созданную Less, в первую очередь, с помощью одинарной косой черты. Мы создаем двусмысленность, а затем пытаемся ее устранить.

Честно говоря, все остальные математические символы перепрофилированы в других частях CSS, просто их использование в математике не вызывает двусмысленности.

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

Знак деления также математически эквивалентен символу соотношения, обычно обозначаемому двоеточием (:) и читается как «is to». Таким образом, для любого действительного числа x и любого ненулевого действительного числа y выполняется это уравнение:

х ÷ у = х: у

Другими словами:

lost-column: 1/3;   //  value
lost-column: 1:3;   // division 

Я знаю, что для использования двоеточия в математике потребуется небольшая настройка парсера, но, по-видимому, это _is_ математически корректно. Я не могу придумать другие символы, которые могли бы лучше заменить. Может быть, | в качестве второго варианта? Хотя это было бы более произвольно.

Мысли?

_Alternatively_, мы могли бы по-прежнему поддерживать символ деления в круглых и / или квадратных скобках, как в:

lost-column: 1/3;   //  value
lost-column: 1:3;   // division 
lost-column: (1/3);
lost-column: [1/3];

Да, именно поэтому изначально я начал с ./ (вдохновленный оператором Matlab vector-div, это два символа, но визуально он, вероятно, наименее тяжелый из-за легкой точки, хотя в контексте Меньше испортить точку не блестящая идея).
: - Это еще раз подтолкнет маргаритки, этот символ используется слишком во многих контекстах CSS. Фактически уже существует противоречивый синтаксис:

.foo(<strong i="9">@a</strong>: 1, <strong i="10">@b</strong>: 2) {
  result: <strong i="11">@a</strong> @b;  
}

bar {
    <strong i="12">@b</strong>: 4;
    .foo(<strong i="13">@b</strong>:3); // would mean both @second-parameter:3 and 4/3
}

@ семь фаз-макс. Ах да, блин. ЕСЛИ ТОЛЬКО КЛАВИАТУРЫ БЫЛИ БОЛЬШЕ. Да, двухзначная последовательность для деления кажется неизбежной. Прошло много времени с тех пор, как я прочитал всю ветку, поэтому я забыл об этом. ./ Это действительно неплохо. Если вы и @lukeapage согласны , это будет неплохим компромиссом. Может быть, мы перейдем к стадии предложения и посмотрим, есть ли возражения?

Возвращаясь к этому моменту:

не считая этого, также требуется пробел перед . , например 16 ./17 а не 16./17

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

Идеального варианта не будет, но я думаю, что это лучше, чем а) ​​использовать / для деления по умолчанию, б) всегда требовать скобки. (Несмотря на мои позиции в прошлом, я также пришел к выводу, что да, это немного раздражает, особенно в других скобках. И особенно потому, что это требуется только из-за разделения, насколько мне известно. Да?)

Я думаю, как бы вы это ни писали, без пробелов или без, он должен делиться 16 на 17.

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

И особенно потому, что, насколько мне известно, это требуется только из-за разделения. Да?)

Да, точно. Не считая кода внутри calc - но для этого, я думаю, решение, предложенное @lukepage, должно помочь.

(Технически, в будущем может возникнуть дополнительная двусмысленность для +, -, * если они останутся в своем синтаксисе функций манипулирования цветом CSS - но это не должно быть слишком драматичным, поскольку значения там имеют форму * 20% (таким образом они явно могут быть обнаружены как некое не менее оцененное выражение). После всех этих забав все равно потребуются некоторые изменения синтаксического анализа, поскольку текущие значения, такие как (* 20%) вызывают ошибку синтаксического анализа).

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

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

Пример calc(100% - 10px) является наиболее очевидным. Нет расчетов Less, которые могут / должны выполняться, если мы не отливаем блоки, и я согласен, что Less должен прекратить делать это по умолчанию. ¹

Давайте посмотрим на свойство сокращения шрифта, используемое в качестве примера.

font: italic small-caps normal 13px/150% Arial, Helvetica, sans-serif;
font: italic bold 12px/30px Georgia, serif;

Текущий обходной путь для этого - превратить strict-math: on в свойство font. Но ... зачем Мессе вообще делать какие-либо расчеты? Конечно, 13px/150% - верное математическое утверждение, но разумно ли считать его действительным в Less? 12px/30px вы _ можете_ рассматривать как допустимое математическое выражение, но должны ли вы? ²

То есть: в Less математические операции с юнитами должны выполняться _integer_ и _floats_, а не юнитами. Мы рассматриваем их как действительные математические утверждения, как если бы люди действительно записывали свои математические данные таким образом. Но я не понимаю, как это возможно.

То есть разумно потребовать от кого-то написать 13px/150% как 13px/1.5 . И даже игнорируя тот факт, что 12px/30px не имеет смысла в качестве математической операции, нам не нужно знать, что это не так, и нам не нужно заносить в белый список font . Если бы автор Less выполнял математическую операцию, он разумно написал бы это 12px/30 . Мало того, что это было бы разумно, это чрезвычайно высокая вероятность того, что они пишут это в первую очередь.

Для меня обычное дело - писать миксин или даже использовать что-то подобное в одном блоке:

width: <strong i="5">@size</strong> / 2;
height: <strong i="6">@size</strong> / 2;

Зачем мне так писать? _Кто-нибудь_ пишет это так?

width: <strong i="10">@size</strong> / 2px;
height: <strong i="11">@size</strong> / 2px;

Операция _sort of_ имеет смысл, если @size является единицей px , но, несмотря на это, в области LESS / CSS не имеет смысла пытаться выполнять математические вычисления в последнем случае, когда делитель это значение с единицей измерения. Второй не похож на математику. Похоже на значение CSS.

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

<strong i="18">@pad</strong>: 2px;
width: 10px + @pad; 

Но при добавлении / вычитании одного значения с единицей измерения к другому с другой единицей Less следует оставить это значение в покое.

<strong i="22">@val1</strong>: 100%;
<strong i="23">@val2</strong>: 10px;
width: calc(<strong i="24">@val1</strong> - @val2);

// output
width: calc(100% - 10px);

Требование соответствия единиц для сложения / вычитания (или целого числа / числа с плавающей запятой) и требование целых чисел / чисел с плавающей запятой в математических операциях с единицами измерения (без единиц, умноженных / разделенных на единицы) решило бы 99% неоднозначностей и по-прежнему допускало бы допустимые математические операции без каких-либо новых символов .

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

background: no-repeat 10px 10px/80% url("../img/image.png");

% - это единица CSS. px - это другая единица CSS. Следовательно, без математики. Особое исключение - ноль.

background: no-repeat 0 0/80% url("../img/image.png");

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

Граница-радиус, тоже самое:

border-radius: 30% / 20%;

Меньше пропустил бы это. Если кто-то намеревается заниматься математикой, его можно записать следующим образом:

border-radius: 30% / 0.2;

Приятно то, что, проводя эти различия, должно быть очевидно, что математическая операция _ не может быть значением CSS, поскольку, как и в примере border-radius , допустимое значение CSS потребует единиц измерения с обеих сторон. Не было бы дублирования / двусмысленности.

За исключением одного случая, о котором я могу думать, могут быть и другие:

font: 10px/1.5;

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

Итак, строгая математика по-прежнему используется, но я думаю, что с этими изменениями это не так и, возможно, не понадобится в качестве опции в будущем.

Приветствую отзывы / комментарии галереи.

¹ _Я понял, что должен прояснить, что комментарии @lukeapage и ссылка @ seven-
² _Как я понял, глядя на примеры, включение строгой математики для шрифта может быть неизбежным решением, но я думаю, что остальная логика применима.

Просто для исторического контекста важно отметить, что приведение модулей при первом выпуске Less.js не было такой большой проблемой. calc() не было реализовано, а background и border-radius не имели косых черт в качестве допустимых значений. Я думаю, что font было единственным местом, где что-то споткнулось (что, по иронии судьбы, все еще может иметь место).

Меня беспокоит только сторона реализации, например: для calc(4px + 2rem + 20%) (фактические единицы не имеют значения) первое добавление приводит к не-числовому результату, поэтому второй обработчик сложения не может отличить свой ввод от любой оператор not-a-number + 20% котором он должен выдать ошибку. Вероятно, небольшая проблема (решаемая путем добавления дополнительных флагов типа / типа), но все же требует некоторого исследования.

А другая проблема - эээ, не уверен, "редабильность"? Т.е. если для явных чисел результат выглядит кристально чистым, для переменных он начинает выглядеть довольно неоднозначно, например: border-radius: 10px <strong i="8">@a</strong> / <strong i="9">@b</strong> 30px; - вы никогда не узнаете, что это должно означать, пока не увидите @a и @b определения.

И да, font все еще остается проблемой (вероятно, другие сокращенные свойства, похоже, используют единицы с обеих сторон, но опять же, мы никогда не знаем, что они придумают дальше (также считая такие вещи, как # 2769) ... A еще несколько вкусностей, таких как font и он снова начнет выглядеть сломанным).

PS Еще одна проблема (возможно, небольшая регрессия). Существуют такие значения, как:

border-radius: 10px / auto;
border-radius: 1px inherit / 2px;
background: ... center / 80% ...;
// etc.

То есть, чтобы все это работало, нам придется отключить все текущие ошибки несовместимости-операнда-операнда, чтобы любые foo/bar , 1x/bar и foo/1x могли пройти без ошибка.

Меня беспокоит только реализация, например: для calc (4px + 2rem + 20%) (фактические единицы не имеют значения)

Вот что я говорю. Фактические единицы должны иметь значение. В любом случае Less следует оставить это в покое. 4px + 2rem имеет значение в браузере, но не имеет смысла в Less. Нет причин пытаться добавить его, если это не имеет смысла и вызывает эти дополнительные проблемы.

например: border-radius: 10px <strong i="10">@a</strong> / <strong i="11">@b</strong> 30px ; - вы никогда не узнаете, что это должно означать, пока не увидите определения @a и @b .

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

С помощью этих математических правил, которые я предлагаю, подумайте:
calc(4px + 2rem - 2px)

Менее мог / мог бы вычислить это как calc(2px + 2rem) , что на самом деле совершенно нормально и на самом деле является правильным выводом значения. Сейчас Less рассчитывает это как calc(4px) , что не является правильным или полезным ответом. (Да, сейчас правильно, если мы отбрасываем единицы, но единицы не бессмысленны и, за исключением нескольких случаев, не совместимы.) Less вычисляет 2px + 100% как 102px , как если бы в тот результат, когда никто, возможно, не захотел бы этого в результате.

чтобы все это работало, нам нужно отключить все текущие ошибки несовместимости-операнда-операнда, чтобы любые foo / bar, 1x / bar и foo / 1x могли проходить без ошибки.

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

Менее мог / мог бы рассчитать это как calc (2px + 2rem)

Боюсь, что этого никогда не произойдет, поскольку для этого потребуется совершенно новый обработчик оптимизирующих выражений, который будет излишним (в основном 4px + 2rem - 2px хранится в дереве как (4px + 2rem) - 2px чтобы получить 2px + 2rem это должен быть механизм переупорядочения, чтобы опробовать все допустимые перетасовки (тривиально в данном конкретном случае, но становится довольно сложным для большего количества операндов / операторов). Но неважно, оставить 4px + 2rem - 2px как есть (после все если делать 4px - 2px + 2rem оптимизировано).

Но на самом деле я имел в виду следующее:

так что любые foo / bar, 1x / bar и foo / 1x могут проходить без ошибок.

Т.е. (4px + 2rem) - 2px для expr.evaluator будет похож на foo + 2px , поэтому для работы он не должен генерировать ошибок и для подобных вещей.
На самом деле, я тестировал foo/bar, 1x/bar, foo/1x и они уже передают без ошибок (странно, я думал, что они бросают), но другие операторы приводят к всевозможным странным вещам (хотя ничего действительно критического, просто вопрос исправления каждого случая по одному).

Боюсь, что этого никогда не произойдет, поскольку для этого потребуется совершенно новый обработчик оптимизирующих выражений, который будет излишним (в основном 4px + 2rem - 2px хранится в дереве как (4px + 2rem) - 2px, чтобы получить 2px + 2rem, он имеет чтобы быть механизмом переупорядочения, чтобы попробовать все допустимые перетасовки (тривиально в этом конкретном случае, но становится довольно сложным для большего количества операндов / операторов).

Зачем тасовать? Вы сглаживаете операторы с одним и тем же уровнем приоритета (так что дерево имеет вид Sum(4px, 2rem, -2px) ), собираете термины с совместимыми единицами (возможно, предварительно нормализуя единицы) и упрощаете каждую часть. Это символическая алгебра, где единицы рассматриваются как независимые переменные.

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

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

Вы сглаживаете операторы с одинаковым уровнем приоритета (так что дерево имеет вид Sum (4px, 2rem, -2px)),

И что именно заставляет код думать, что какое-то дерево выражений вообще может быть уплощено? (Так что мой "суффлинг" здесь не о каком-то конкретном алгоритме дедукции, а о ярлыке для "пробовать их все", включая ваше "сглаживание").

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

Я не уверен, серьезно ли ты. Итак, вы думаете, что весь этот код для преобразования дерева Less во внешнее дерево библиотек и обратно (не считая, что ни одна из этих JS-библиотек не может обрабатывать блоки CSS) действительно стоит того, чтобы оптимизировать этот конкретный случай 4px + 2rem - 2p ? Хм...

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

И что именно заставляет код думать, что какое-то дерево выражений вообще может быть уплощено? (Так что мой "суффлинг" здесь не о каком-то конкретном алгоритме дедукции, а о ярлыке для "пробовать их все", включая ваше "сглаживание").

Анализатор определяет, является ли контекст, например, «длиной», и можно ли интерпретировать поддерево как «длину».

Я не уверен, серьезно ли ты. Итак, вы думаете, что весь этот код для преобразования дерева Less во внешнее дерево библиотек и обратно

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

(не считая, что ни одна из этих JS-библиотек не может обрабатывать блоки CSS)

Вы просто конвертируете единицы в алгебраические переменные. Подстановки (например, mm -> px ) могут выполняться даже тогда, когда выражение находится в символьной форме.

действительно ли стоит оптимизировать этот конкретный случай 4px + 2rem - 2p?

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

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

попробуй и пиар приветствуется.

Я постараюсь. Я только начал изучать Less сегодня, и у меня проблемы с завершением проектов, поэтому я признаю, что, вероятно, мне не удастся получить PR.

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

Я знаю. Я был здесь по одной из причин. Почему такой укус?

Почему такой укус?

Что ж, может быть ... Если так - мои извинения (похоже, я просто слишком шокирован усилиями и временем, которое кто-то готов посвятить решению практически не существующей проблемы calc(4px + 2rem - 2px) . Вероятно, у нас просто совсем другое представление легкости).

и позвольте Less добавить больше математических функций.

Не могли бы вы назвать несколько?

решить практически не существующую проблему calc(4px + 2rem - 2px)

Хм? Меньше с этим вообще не справится. [остальные удалены, так как я неправильно понял, о чем идет речь]

Чтобы упростить / переформулировать предложение - математические изменения будут следующими

1. Сложение и вычитание будут рассчитываться только для одинаковых единиц. например, 1px + 2px = 3px , 1px + 1vh = 1px + 1vh
2. Деление и умножение могут быть рассчитаны только с безразмерными делителями / множителями. например, 10px/2 = 5px , 10px/5px = 10px/5px
3. Соотношения стоимости без единиц будут обрабатываться аналогично пункту 2, например, 1/3 = 1/3
4. Для упрощения выражения с частично недопустимыми подвыражениями можно рассматривать как недопустимые математические выражения и выводить как есть. например, 1px + 2vh / 2 = 1px + 2vh / 2

Это предложение решает следующее (из этой ветки):

• font: 10px/5px и аналогичный (коэффициент) синтаксис (без расчета)
• calc(100vh - 30px) (без расчета)
• lost-column: 1/3 и аналогичный синтаксис пользовательского соотношения (без расчета)

В то же время эти изменения сохранят 99% типичного использования Less math. Кроме того, существующие функции unit() и convert() позволяют пользователям преобразовывать значения в совместимые математические единицы.

Меньше с этим вообще не справится.

Вы просто не прочитали то, о чем я и @leewz говорили выше. Это не имело ничего общего с calc(100vh - 30px) . И мое «решение практически не существующей проблемы» сводится исключительно к «оптимизации арифметических выражений в calc ».

@ seven-phase-max Ох, верно. Прости. Нет, оптимизировать не нужно. Просто выясните, когда нужно заниматься математикой.

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

Удаление метки планшета, поскольку проблема все еще важна и становится только хуже по мере развития CSS.

@ Мэтью-Дин
Собираюсь на минутку сыграть здесь адвоката дьявола ...

12px/30px вы _ можете_ рассматривать как допустимое математическое выражение, но должны ли вы?

Да; вам следует. Он вычисляет скалярное значение, которое представляет собой соотношение между обоими размерами и может быть весьма полезно при преобразовании в единицы em.

Скажем, у меня есть известный базовый размер шрифта 16 пикселей и известный размер заголовка 24 пикселя, оба спрятаны в переменных, а затем я хочу назначить конкретный вариант заголовка с правильным размером шрифта, но в единицах em.

@fontsize-body    : 16px;
@fontsize-heading : 24px;

// ( ... and then somewhere else ... )

.heading {
  font-size : unit(@fontsize-body/@fontsize-heading, em);

  // Or if dividing compatible unit values is produces a unit-less scalar
  // value ( as it really _should_ -- mind you... ),  you could prefer:
  font-size : @fontsize-body/@fontsize-heading * 1em;
}

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

Теперь разрешено, что это может включать использование скобок для принудительного математического выражения и принятие литерала CSS по умолчанию. Но это кажется неправильным и подверженным ошибкам. Для этого требуется множество заранее подготовленных особых случаев, таких как сокращенные обозначения border-radius и font , и требуется, чтобы Less постоянно обновлял их. (Как было показано на примере некоторых новых свойств сетки, в которых возникает та же проблема со знаком деления.)

Так...

Почему бы не перевернуть свои рассуждения? Если что-то похоже на математическое выражение и в нем есть совместимые единицы измерения, то по умолчанию оно будет рассматриваться как математическое выражение. И если вы не хотите, чтобы это произошло ... ну; затем используйте аварийный люк ~"..." . В конце концов, это именно то, для чего он нужен ...

Мое текущее видение предложения:

• Прекратить рассматривать / как деление в любом месте, независимо от любых UNIS и любых параметров (если - необязательно - оно заключено в избыточные скобки, такие как -sm = on)
  Таким образом, Less оценивает только 1anything./3whatever и (необязательно) (1anything/3whatever) .
• + , - и * остаются без изменений
• calc subissue решается не-оценки любого arithm. выражения внутри calc(...) (хотя, опять же, избыточные скобки тоже могут иметь свой эффект).

@ семь фаз-макс

Проблема в том, что / невероятно укоренился в качестве оператора деления. Использование любого другого символа для этого было бы сложной задачей для пользователей. Вы берете общий вариант использования и отбрасываете его для исключительного варианта использования ( / в сокращениях CSS), который вряд ли кто-либо когда-либо использует.

@rjgotten

Проблема с этим невероятно укоренилась в качестве оператора деления.

Не в CSS.

для исключительного случая использования (/ в сокращениях CSS), который почти никто не использует.

К настоящему времени / уже используется очень часто, и для сравнения, операция Less div намного более исключительна, чем CSS / наши дни (в отличие от того, что было всего несколько лет назад, когда CSS / чаще всего можно найти только в font ).

@ seven-phase-max Спасибо, что держите в курсе. Я добавил бота Stale, чтобы помочь нам справляться с проблемами, и дал довольно много времени на то, чтобы пометить устаревший. Я также исключил два ярлыка: «ошибка» и «разыскиваемый». Любые предложения по этому поводу приветствуются, например, добавление других ярлыков в белый список. Файл здесь: https://github.com/less/less.js/blob/3.x/.github/stale.yml

Возвращаясь к теме проблемы ...

@rjgotten
Ваш вариант использования создает произвольную проблему. Аргумент в том, что это полезно. Но такое структурирование ваших vars создает проблему, которую можно избежать с помощью синтаксиса, который, как указал @ seven-phase-max, неоднозначен.

Даже если брать за чистую монету, используя CSS в качестве руководства для принципов Less, вы не можете в calc разделить 12 пикселей на 30 пикселей. Выполнение этого в Less не только создает проблему двусмысленности, но и отрывается от модели без уважительной причины (кроме исторической). Вероятно, одна из вещей, отсутствующих в Less, - это просто способ извлечь числовое значение единицы, чтобы Less не прибегал к математической магии для деления.

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

font-size : @fontsize-body/number(@fontsize-heading) * 1em

Но я тоже согласен с предложением @ seven-phase-max. Мы все еще могли оценивать _vars_ в calc() , но не в математике. И не оценивать деление вне скобок. Думаю, это хороший компромисс. И, возможно, если вы хотите сохранить математику магического деления для деления единицы на единицу, но сохранить единицу (что все еще странно, но это нормально), это могло произойти в пределах скобок.

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

Я думаю, что мы все находимся на той же странице, что текущий (по умолчанию) подход к математике в Less нарушен. И мы получили обратную связь, что по умолчанию «parens-all» легче рассуждать, но обременительно. Так что я надеюсь на какую-то хорошую золотую середину, которую мы скоро сможем сделать по умолчанию (возможно, в 4.0?)

Вероятно, одна из вещей, которых не хватает в Less, - это просто способ извлечь числовое значение единичной стоимости.

Функция unit действительно делает это, если вы не укажете второй параметр. Но это скорее побочный эффект того факта, что скаляры в настоящее время реализованы с типом узла Dimension , для которого не определена единица измерения.

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

Я бы также добавил, что я категорически против любых догадок о «совместимых единицах» (например, пусть a/b остается делением, а b/c - нет) в этом конкретном контексте.
Просто потому что:

• исключительная обработка - это корень всего зла (например, # 3047 - см. ниже, http://stackoverflow.com/questions/19705791 - я помню, что не мог найти причину проблемы SO, пока я не прошел через каждую из миллионов строк Меньше задействованного кода в отладчике).
• и самое главное, это просто не будущее доказательство, т.е. если основная обкатка изменение неизбежно , мы бы лучше , чтобы обеспечить , чтобы сделать это один раз (и в идеале навсегда) ... и не так, как они добавляют некоторые новые функции CSS с участием a/b и он снова сломан.

Так что для меня «совместимые единицы» больше похожи на совершенно несвязанные и ортогональные вещи (могут быть некоторые дискуссии о результирующих единицах с или без -su , но это уже другая история).

(не по теме:)
И, кстати, говоря о примерах выше:
@rjgotten, если у вас есть:

@fontsize-body/@fontsize-heading * 1em; 

где-то в вашем коде и любая из двух переменных px вы действительно используете ошибку :)
Правильный код:

1em * @fontsize-body/@fontsize-heading;

Это всегда приводит к четко определенной единице для http://lesscss.org/features/#features -overview-feature-operations (считая # 3047, который должен быть исправлен, ошибка снова является примером ошибки, созданной слишком большим количеством код догадки вокруг «совместимых единиц» в кодовой базе). На самом деле нет необходимости в --su , number , unit bla-bla ... Текущее поведение -su типа «просто выдайте ошибку, если увидите несовместимые блоки» , т.е. простая проверка, более чем подходит (для меня). Я не вижу необходимости в сверхинжиниринге 1px/2px->.5 и 1px*2px->2px^2 mambo-jambo. Но опять же, это уже другая история, не имеющая отношения к делу).

@ семь фаз-макс

на самом деле использую ошибку

Гм .. да; Вы, конечно, правы. К счастью, у меня на самом деле нигде нет этого кода в разработке. Это был всего лишь краткий пример, подброшенный вместе, чтобы проиллюстрировать суть дела.

Я также добавлю, что я категорически против любых догадок о «совместимых единицах» (например, пусть a / b остаются делением, а b / c - нет) в этом конкретном контексте.

Думаю, я был согласен с этим больше как с оливковой ветвью для тех, кто хочет голых делителей. Но я думаю, что ваш комментарий [ здесь ] - наиболее работоспособное предложение. Это было изначальное намерение «строгой математики», чтобы устранить двусмысленность. Я думаю, что проблемой стали операции внутри миксина и вызовы функций, приводящие ко всем видам парных скобок внутри парных скобок. Но в целом я согласен с тем, что попытки упростить математику в Less также, по иронии судьбы, очень затруднили ее из-за возросшей двусмысленности.

Кроме того, позже я понял, что font: 10px/3 - допустимое сокращение. Так что алгоритмического решения, которое может здесь помочь, действительно нет.

Возвращаясь к вашему вопросу, @rjgotten ...

Почему бы не перевернуть свои рассуждения? Если что-то похоже на математическое выражение и в нем есть совместимые единицы измерения, то по умолчанию оно будет рассматриваться как математическое выражение. И если вы не хотите, чтобы это произошло ... ну; затем используйте аварийный люк ~ "...". В конце концов, это именно то, для чего он нужен ...

Идея / отношение Less к CSS аналогична TypeScript и JavaScript. То есть переименуйте свой действительный .css в .less и вы можете начать добавлять меньше функций. Подобно тому, как вы можете переименовать .js в .ts и начать добавлять функции TypeScript. Если вы ничего не добавляете, вы должны получить тот же действительный Less / JavaScript, потому что языки являются надмножествами базового языка.

Однако в случае этих соотношений или других делителей / в CSS по умолчанию Less уже не работает сразу после выхода из строя. Ваш обычный CSS произвольно превращается в математическое выражение Less с другим результатом, даже если вы ничего не изменили. Это нарушает договор о языке. Возможность изменить .less на совершенно другое выражение Less, чтобы вернуть исходный CSS, с которым вы начали, упускает суть. Эта работа никогда не должна требоваться. Less не должен требовать от вас изменения вашего действительного CSS на совместимые выражения Less, чтобы вернуть действительный CSS, который у вас был изначально. Это просто сломанная модель.

То же самое относится и к calc() . Да, вы можете экранировать свои выражения строкой, но это не обязательно. .css переименованный в .less должен давать такой же эффективный CSS. Это должно быть основной целью проекта - не вмешиваться / перезаписывать / интерпретировать исходную таблицу стилей. Все остальное пытается навязать проблему разработчику без всякого иного греха, кроме как с помощью парсера / языка в первую очередь.

Да, вы можете экранировать свои выражения строкой, но это не обязательно. .css, переименованный в .less, должен давать такой же эффективный CSS. Это должно быть основной целью проекта - не вмешиваться / перезаписывать / интерпретировать исходную таблицу стилей. Все остальное пытается навязать проблему разработчику без всякого иного греха, кроме как с помощью парсера / языка в первую очередь.

Тот.

LESS знает, где / разрешено, а где нет в css. Там, где его нет, но он все равно появляется, он должен предполагать, что математика должна быть сделана. Также, когда математика окружена круглыми скобками, где круглые скобки не разрешены в css, следует интерпретировать LESS.

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

@thany

Слишком много предположений о том, что знает компилятор (а некоторые из них просто неверны).
В любом случае режим "круглых скобок" - это почти то же самое, что и --sm=on , поэтому используйте его и забудьте об этом потоке (скорее всего, вы просто не используете математику в своих проектах, кроме calc (введено несколько спустя годы после того, как был разработан Less), поэтому вы не можете видеть, как лишние скобки раздражают. Но другие раздражают.)

Об остальном см. Https://github.com/less/less.js/issues/1880#issuecomment -345194431.

@ seven-phase-max Не забывайте, что / также имеет значение в сокращениях background и border-radius и, возможно, в других, о которых я сейчас не думаю. LESS с радостью будет относиться к ним как к подразделению. Со строгим математическим режимом или без него, LESS должен «знать, когда остановиться», выполняя свои собственные маленькие математические вычисления.

@thany
LESS должен «знать, когда остановиться», выполняя свои собственные небольшие вычисления.

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

Sofar есть два разумных и предсказуемых варианта для / в качестве оператора деления:

• Всегда относитесь к нему как к таковому и требуйте явного экранирования для других целей.
  Это нарушит поведение, в котором синтаксис Less является строгим надмножеством синтаксиса CSS.
• Никогда не относитесь к нему как к оператору деления __, если__ он не находится в известном математическом контексте.
  Если известный математический контекст может / будет решен, как в текущем поведении --strict-math=on .

_{(Также обратите внимание, что имя Less больше не пишется заглавными буквами.)}

Не забывайте, что / также имеет значение в сокращениях фона и радиуса границы,

Это в основном то, с чего начинается эта ветка.
И см. Сводку предлагаемых изменений на https://github.com/less/less.js/issues/1880#issuecomment -345194431 (без каких-либо предположений о том, что компилятор должен или не должен знать).

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

Я полностью согласен с этим. @thany Хотя вы согласились со мной в том, что вы цитировали из того, что я написал, вы приходите к другому выводу, чем я. Менее не следует и не может знать, когда «перестать заниматься математикой». Что я бы сказал, так это то, что решающее изменение должно заключаться в том, что Less более консервативен в отношении начала математики (если использовать американский / канадский подход) в первую очередь.

@rjgotten

Никогда не относитесь к нему как к оператору деления, если он не находится в известном математическом контексте.
Если известный математический контекст может / будет решен, как в текущем поведении --strict-math = on.

Чтобы уточнить, эта часть (с которой я согласен):

Никогда не относитесь к нему как к оператору деления, если он не находится в известном математическом контексте.

На самом деле есть 4 возможных решения, которые, как я знаю, вы знаете, но просто резюмируя для потока:

1. Все вычисления выполняйте только в круглых скобках . Это, по-видимому, было отклонено сообществом, что нормально, хотя оно все еще доступно как дополнительный переключатель ( strictMath ).
2. Везде выполняйте всю математику, а деление - только в круглых скобках.
3. Везде выполняйте всю математику, а деление - только в круглых скобках. Если оператор деления не напечатан как ./
4. Выполняйте всю математику везде, но исправляйте математику, чтобы 12px/4px не приводило к делению. (Умножение и деление только с безразмерными значениями.) Другими словами, деление везде, но с гораздо более консервативными правилами. В тех случаях, когда это не решает проблемы, вернитесь к побегу. Итак, не полное решение, но все же (спорное) улучшение по сравнению с текущей ситуацией.

С точки зрения удобства использования мне нравится делать математику «умнее», как в #4 . С точки зрения разработки и обслуживания, а также для защиты от будущих изменений CSS мне нравится #3 как наиболее надежное решение.

Однако я думаю, что на самом деле нам нужно будет сделать как #3 и #4 , чтобы исправить calc() . Прямо сейчас, меньше игнорировать все единицы при выполнении математических расчетов - это настоящий беспорядок. 100vh - 12px никогда не должен касаться Less (скобки или нет). Но ИМО также не должен 12px/4px (круглые скобки или нет), но я могу быть в меньшинстве в этом.

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

Умножение и деление только с безразмерными значениями.

это не поможет, потому что есть такие вещи, как:

font: small-caps bold 24px/3 ...;
lost-column: 1/3;
// etc.

и они не div.

Однако я думаю, что на самом деле нам нужно будет сделать как #3 и #4 , чтобы исправить calc()

calc() - это боль. По иронии судьбы, это _ вероятно_ лучше всего решить, реализовав ее как фактическую функцию Less, которая в идеале взяла бы свое проанализированное дерево выражений и попыталась бы упростить выражение. То есть: он должен предварительно вычислить и объединить совместимые компоненты, такие как 4px + 12px (или 4px + @a когда известно, что @a имеет значение в пикселях), но оставить несовместимые компоненты, например те, только с несовместимыми устройствами.

Например

<strong i="17">@a</strong> : 4px;
<strong i="18">@b</strong> : 2;
width : calc(100%/<strong i="19">@b</strong> - 10px + @a);

в конечном итоге должен оказать

width : calc(50% - 6px);

(повторяется из https://github.com/less/less.js/issues/1880#issuecomment-345345735)
И я не вижу никакой пользы от чрезмерной разработки компилятора для оптимизации выражений внутри calc . Если вы пишете calc тогда у вас все в порядке с браузером, чтобы выполнить эту работу, какое бы длинное выражение у вас там ни было. Итак, как уже упоминалось выше, я за «не трогайте ничего внутри calc » (= не пытайтесь быть умнее, чем это действительно необходимо) и оставлю это для браузера ( или для css-minifier, поскольку , если я правильно помню, некоторые из них уже неплохо справляются с оптимизацией подвыражений calc).

«Умное поведение юнита мамбо-джамбо» напоминает мне монстров min/max (раздуваемый стек необслуживаемого и никогда не использовавшегося кода) - как сильно я сожалею, что не кричал против «юнитов мамбо» тогда , ох (так что я буду ныть здесь до тех пор, пока сама идея «различной семантики операторов в зависимости от единиц операнда» не будет полностью уничтожена: P).

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

@rjgotten
То, что компилятор Less "знает" об этом, является в корне ошибочным подходом.

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

@ Мэтью-Дин
Менее не следует и не может знать, когда «перестать заниматься математикой». Что я бы сказал, так это то, что решающее изменение должно заключаться в том, что Less более консервативен в отношении начала математики (используя американское / канадское учение) в первую очередь.

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

background: url(...) no-repeat 50% 50% / 40px + 10px 40px;

Что LESS должен здесь делать, для меня очевидно:

background: url(...) no-repeat 50% 50% / (40px + 10px) 40px;

В результате чего:

background: url(...) no-repeat 50% 50% / 50px 40px;

Он не должен вычислять здесь часть 50% / 50px , потому что (1) это не должно быть возможным из-за несовместимых единиц и (2) потому что этого уже достаточно для значения background . Вот где он «перестанет заниматься математикой».

Вот что я имел в виду, говоря МЕНЬШЕ "зная, когда остановиться".

Было ли это другое свойство вроде этого:

padding-left: 50% / 10px + 5px;

Он должен сломаться с ошибкой (несовместимые блоки). Одним из возможных выходных данных может быть 50% / 15px что недопустимо для этого свойства. Другим результатом может быть 5% что он и будет делать сейчас, что неверно во всех направлениях.
И:

padding-left: 50px / 10px + 5px;

Должен привести к:

padding-left: 10px;

Как и ожидалось. Так что в этом случае / недопустим для padding-left и берется в LESS и сделать его математику пимпочка.

@ Мэтью-Дин
На самом деле есть 4 возможных решения, которые, как я знаю, вы знаете, но просто резюмируя для потока:

Еще один:
5) Используйте оператор \ для делений в LESS и исключите использование / . В MATLAB есть что-то подобное, и некоторые разновидности BASIC использовали его для принудительного целочисленного деления. Так что использование обратной косой черты не является чем-то необычным.

/редактировать
Мы также можем лоббировать включение клавиши ÷ в комбинации клавиш и использовать ее в качестве оператора деления. Этому я научился в начальной школе :)

То, что вы предлагаете, уже обсуждалось много раз раньше (не стесняйтесь просматривать темы, упомянутые здесь). Итак, вот только крошечные-ленивые комментарии:

Используйте оператор \ для деления в LESS, а не рекомендуется использовать / .

https://github.com/less/less.js/issues/1872#issuecomment -35245890

достаточно для background ... недопустимо для padding-left

Встречайте: «Ребята, мой браузер / polyfill / все, что только что добавило / обновило / расширило поддержку свойства fnord , не могли бы вы выпустить для меня новую версию Less?» проблема.
Встречайте проблему font .
и т. д. и т. д.
Что ж, @rjgotten уже прокомментировал выше, почему такое «знание» - это путь в никуда.

@ семь фаз-макс
Обратная косая черта была всего лишь предложением. Вы также можете использовать ? для деления. На самом деле это не имеет значения. Я полагаю, что я предлагаю не использовать один символ ( / ), который имеет очень разные и неоднозначные значения.

Встречайте: «Ребята, мой браузер / polyfill / все, что только что добавило / обновило / расширило поддержку свойства fnord , не могли бы вы выпустить для меня новую версию Less?» проблема.

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

Встречайте проблему со шрифтом.

Проблема со шрифтом доказывает, что проблема / существует с момента появления LESS. Не только тогда, когда background получил возможность включать значение для background-size или когда появилось border-radius . Тбх, заявив о проблеме со шрифтом, вы только что сделали лучший аргумент против себя :)

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

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

CSS - это четко определенный стандарт.

Если вы собираетесь придерживаться тех частей спецификации, которые достигли полной зрелости на уровне TR, возможно.
В противном случае? Нет, это не так. Существуют дополнительные спецификации новых «модулей» CSS и изменения существующих модулей с новыми дополнениями, которые появляются ежемесячно, если не еженедельно.

@ семь фаз-макс

он не поможет, поскольку есть такие вещи, как: font: small-caps bold 24px / 3 ...

Нет, я понял. Моя точка зрения была именно такой: только деление / умножение без единиц измерения уменьшает проблему, но не решает ее.

И я думаю, что в целом ваше предложение ./ для всего разделения все еще кажется вполне логичным.

@thany Вместо того, чтобы отвечать на все конкретные примеры, я скажу, что в целом усилия, направленные на то, чтобы сделать Less математику более умным, просто переместят мяч в другую ярдную линию. Это все те же проблемы, только в другом месте. Как сказал @ seven-phase-max, ничего из того, что вы предложили, не обсуждалось.

И я не вижу никакой пользы от чрезмерной разработки компилятора для оптимизации выражений внутри calc. Если вы пишете calc, тогда у вас все в порядке с браузером, который выполняет эту работу, какое бы длинное выражение у вас там ни было. Итак, как уже упоминалось выше, я за "не трогайте ничего внутри calc" (= не пытайтесь быть умнее, чем это действительно необходимо) и оставьте это для браузера (или для css-minifier, поскольку, если я правильно помню , некоторые из них уже неплохо справляются с оптимизацией подвыражений calc).

Я полностью согласен с этим. Мы бы избавились от 99% новых математических проблем, если бы просто добавили calc() белый список. Хотя я предложил несколько способов, с помощью которых Less мог бы более разумно выполнять математические вычисления, чтобы ТАКЖЕ избежать проблем с calc() (что, возможно, и должно), я прошу прощения, если это было истолковано как аргумент против этой идеи. Я тоже за это поддерживаю.

Единственное предостережение (как обсуждается здесь / в другом месте) заключается в том, что разработчик неизбежно захочет использовать переменные в calc() , поэтому нам нужно быть осторожными, чтобы убедиться, что мы продолжаем заменять вары, но просто не делайте этого. математика. Я не уверен, насколько это сложно. Если бы нам удалось это сделать, я бы поддержал изменение в обработке calc() сегодня.

@thany

Проблема со шрифтом доказывает, что проблема / существует с момента появления LESS.

Это может быть правдой и справедливо, но было много подходящих обходных путей, и в то время не обязательно было стандартной практикой использовать сокращение свойства font . Это действительно так, поскольку несколько фонов и calc() появились после того, как Less начал, что сделало это еще более серьезной проблемой, и теперь синтаксис CSS Grid означает, что теперь существует масса конфликтов, которых изначально не существовало в повседневной практике.

Между прочим, вот как Sass решает проблему, проиллюстрированную этим примером:

p {
  font: 10px/8px;             // Plain CSS, no division
  $width: 1000px;
  width: $width/2;            // Uses a variable, does division
  width: round(1.5)/2;        // Uses a function, does division
  height: (500px/2);          // Uses parentheses, does division
  margin-left: 5px + 8px/2px; // Uses +, does division
  font: (italic bold 10px/8px); // In a list, parentheses don't count
}

Это не однозначно, так как вы можете выполнять математику (в настоящее время) в аргументах функций Less, И функции Less могут возвращать значения пикселей (так что Less может делать font: print10px()/8px , теоретически? Нет?), Поэтому я Я просто вставляю это в качестве иллюстрации, а не в качестве предложения. Просто интересно, как они подошли к проблеме.

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

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

+1

_{Даже не считая того, что «решение» не решает ни одну из обсуждаемых здесь проблем, кроме того, что уже делает lessc --sm . А разные результаты для 1/2 и $var/2 просто феноменально гениальны ... ~ глупость ~ "Удачной отладки, неудачники!"}

@ Мэтью-Дин
Между прочим, вот как Sass решает проблему, проиллюстрированную этим примером:

Это отличное решение, не прибегая к услугам другого оператора.
Если выражение, возможно, является допустимым CSS, оставьте его.

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

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

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

Даже не считая того, что «решение» не решает ни одну из обсуждаемых здесь проблем, кроме того, что уже делает lessc --sm. Зачем мне писать 0 + 1/2 вместо (1/2), когда мне нужно просто деление? А разные результаты для 1/2 и $ var / 2 просто феноменально гениальны ... глупость "Удачной отладки, неудачники!" сообщение.

Ха, да, это.

@thany

Это отличное решение, не прибегая к услугам другого оператора.
Если выражение, возможно, является допустимым CSS, оставьте его.

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

Одно наблюдение, от которого мы не можем избавиться: если вы импортируете действительный ванильный CSS, его результат должен быть функционально идентичным. Итак, единственный вывод, который я могу сделать, заключается в том, что LESS не должен касаться выражений, которые, возможно, уже являются действительными CSS. Как это сделать, не мне решать. Но факт остается фактом: импорт ванильного CSS ненадежен, в основном из-за того, что МЕНЬШЕЕ выполнение разделов слишком активно.

Импорт ванильного CSS в Sass работает практически безупречно, потому что, как уже говорилось, Sass оставляет оператор / покое, если он не указывает компилятору идти и делать что-то в соответствии с несколькими простыми синтаксическими правилами. Эти правила синтаксиса описывают способы принудительного разделения, которое не может произойти в валидном ванильном CSS, и поэтому оно великолепно.

Вы по-прежнему спорите со своим воображением, а не с тем, что вам говорят. Ответьте на простой вопрос: «Чем 0 + 1/2 может быть лучше, чем (1/2) ?». Если 100% -ная совместимость с CSS - это единственное, что вам нужно, установите прекрасный -sm и забудьте об этом потоке.

Одно наблюдение, от которого мы не можем избавиться: если вы импортируете действительный ванильный CSS, его результат должен быть функционально идентичным. Итак, единственный вывод, который я могу сделать, заключается в том, что LESS не должен касаться выражений, которые, возможно, уже являются действительными CSS. Как это сделать, не мне решать. Но факт остается фактом: импорт ванильного CSS ненадежен, в основном из-за того, что МЕНЬШЕЕ выполнение разделов слишком активно.

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

Я был бы рад внести эти критические изменения в качестве приоритета:

1. математика вне скобок, требующая ./ вместо голого / . 12px./10px прежнему выглядит немного странно.

@ seven-phase-max - я хочу еще раз вернуться к обратной косой черте. В связи с этим я знаю, что вы упомянули https://github.com/less/less.js/issues/1872#issuecomment -35245890, но я не вижу прямого конфликта, поскольку этих идентификаторов нет и я думаю, что не может быть часть математических выражений. Или я не прав? Я полагаю, что можно придумать теоретический случай, такой как имя функции с экранированным символом как частью имени, но это больше похоже на интеллектуальное упражнение, чем на реальный случай. Экранированные селекторы, да, они обычно используются по разным причинам, но в значениях свойств это просто кажется маловероятным, или, в крайнем случае, можно сломать / обходной путь с помощью исторического (просто избегайте этого текста) обходного пути.

Можем ли мы немного больше узнать о том, что использование одной обратной косой черты для деления может вызвать конфликты в реальном мире? Мои инстинкты таковы, что \ менее проблематично, чем текущая ситуация вокруг / , и более удобна для разработчиков, чем ./ . Если бы мы провели исследование и обнаружили, что это возможно, то мы могли бы внести критическое изменение, чтобы использовать его повсюду, вместо переключения контекста, разрешающего / в скобках. И тогда мы могли бы поддерживать / с устаревшим переключателем.

1. (второй приоритет) calc() имеет специальный регистр, поэтому он может выполнять замену переменных, но не оценивает какие-либо математические выражения

Можем ли мы немного больше узнать о том, что использование одной обратной косой черты для деления может вызвать конфликты в реальном мире?

Что ж, проблема в том, что \anycharacter - это правильный CSS и имеет собственное значение. Конечно, вы вряд ли найдете такой код в реальных проектах (за исключением, может быть, \9 -подобных хаков), но ... хотим ли мы кормить этого льва? Исправление одного "э-э-э, мой 100% -ный CSS не компилируется" путем введения другого "э-э-э" того же самого звучит немного странно :)

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

Что ж, проблема в том, что \ anycharacter является действительным CSS и имеет собственное значение. Конечно, вы вряд ли найдете такой код в реальных проектах (за исключением, может быть, хаков, подобных ie \ 9), но ... хотим ли мы кормить этого льва? Исправление одного "э-э-э, мой 100% -ный CSS не компилируется" путем введения другого "э-э-э" того же самого звучит немного странно :)

Я слышу вас, это возможный компромисс. И да, я знаю, что \anycharacter - это правильный CSS. Думаю, мне интересно, может ли это лучший набор компромиссов. Просто когда я написал 12px./10px это было синтаксически странно. Мне кажется, что Less синтаксически попытался максимально изменить назначение CSS, не создавая конфликтов.

Например, ./ обеспечивает ясность синтаксиса и полностью исключает конфликты, но также заставляет применять круглые скобки повсюду для математики, поэтому я поддержал его, но возникла обратная реакция, и меня это беспокоит. Итак, есть ли законный случай, когда мы могли бы ошибочно принять 10px\10 за намерение разработчика избежать \10 ? Я знаю, что это сложная теория, и ваша точка зрения, вероятно, будет заключаться в том, что мы на самом деле не знаем ... Это сложный вопрос, и добавление нового синтаксиса всегда чревато, особенно с Less, поскольку мы не знаем всего CSS в ни дикий, ни будущий CSS.

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

Хорошо! Должны ли мы отслеживать его отдельно, чтобы улучшить видимость?

@ семь фаз-макс:

Конечно, вы вряд ли найдете такой код в реальных проектах (за исключением, может быть, т. Е. \9 -подобных хаков)

Верно . Ох уж эти самоуверенные "западники" ... :)

@ семь фаз-макс
Ответьте на простой вопрос: «Как 0 + 1/2 может быть лучше, чем (1/2)?»

Я не понимаю, к чему вы клоните. (1/2) должен выполняться LESS, потому что он не может быть действительным CSS, поэтому его следует понимать как LESS. 0 + 1/2 должно стать 1/2 где LESS выполняет часть 0 + 1 потому что это часть, которая не может быть действительным CSS. Часть 1/2 может быть действительной, так что лучше не трогайте ее.

@thany
Хорошо, теперь понимаем, что (1/2) работает так, как вы ожидаете, как в Less, так и в Sass ..
И 0 + 1/2 (а также 1 * 1/2 и т. Д.) Является частью решения, которое вы назвали блестящим выше, а результат "блестящего решения" равен 0.5 .
Все еще не понимаете, что здесь происходит?
Перечитайте все выше (начиная с вашего первого сообщения) еще раз и попробуйте ответить себе «На что именно я жалуюсь?».

@ семь фаз-макс
И 0 + 1/2 (а также 1 * 1/2 и т. Д.) - это часть решения, которое вы назвали блестящим выше, а результат «блестящего решения» равен 0,5.

Нет, решением будет 1/2 не 0.5 , поскольку 1/2 может быть действительным CSS. Кажется, вы не хотите, чтобы LESS знал, когда косая черта действительна, поэтому предполагайте, что она всегда может быть. Поэтому 1/2 - единственный логический результат. Точно так же 2 * 1/2 приведет к 2/2 , потому что в противном случае * сделает его недействительным CSS.

Все еще не понимаете, что здесь происходит?

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

Перечитайте все выше (начиная с вашего первого сообщения) еще раз и попробуйте ответить себе «На что именно я жалуюсь?».

Нет необходимости в личных нападках.

LESS выполняет математические деления с энтузиазмом и слепо игнорирует единицы.

Так вот на что вы жалуетесь, верно?

Нет необходимости в личных нападках.

Так что же мне делать вместо этого? Повторять два исходных сообщения снова и снова (и снова)? Пока вам не станет ясно:
@сообщество :

используйте параметр -sm

@thany :

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

@ семь фаз-макс:

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

Итак, вы повторяете «он должен», «он должен», «он должен», ожидая чего? Думаю, нам легче ответить просто «Нет, не должно», вместо того, чтобы тратить время на попытки подробно объяснить, почему то, что вы предлагаете, не работает или не имеет смысла в целом (объяснения, которые вы либо не хотите понять или просто не могу).

Так о чем эта ветка? Речь идет о том, чтобы «осознать, что, хотя возможное критическое изменение« -sm -подобного поведения по умолчанию »неизбежно, мы должны предоставить средства для более удобной арифметики, кроме ужасных: margin: (1/2) (3/4) (5/6) (7/8); для тех, кто много используйте арифму ".
Вы здесь либо предлагаете что-то, что не лучше (или делает то же самое) уже существующее поведение -sm либо спорите с тем, о чем не может быть и речи с самого начала (например, там ). Другими словами, просто случайный шум .

@ seven- phase -max понизим температуру на ступеньку ниже. Повсюду существуют твердые мнения.

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

font: 12px/10px;
width: calc(100% - 20px);

Итак, по этим пунктам в основном есть согласие, и большинство аргументов связано с возможными решениями. Похоже, что проблема calc() имеет достаточно консенсуса, чтобы двигаться дальше. В основном: не трогайте calc и обрабатывайте vars в calc() как строковую интерполяцию. Примерно так и поступает Sass, хотя для этого требуется синтаксис интерполяции в calc() , который, я думаю, нам не нужен.

Решения для части font становятся намного сложнее, и ведущими решениями были:

1. По умолчанию требовать паренсы для всего (первая попытка - почти реализована, но сообщество отклонило)
2. Щелкните переключатель strictMath (который был добавлен вместо того, чтобы сделать его значением по умолчанию и предложением @ seven-phase-max), а затем явно выполните все свои вычисления. Технически это возможное решение для большинства людей в настоящее время, но ... этот вопрос возникает так часто, и мы знаем психологически, что кто-то, кто плохо знаком с любой системой, вероятно, сохранит любые настройки по умолчанию, так что это проблематично. И не каждый разработчик может изменить свои настройки сборки, особенно в командах.
3. По сути измените оператор деления в Less. Ведущим соперником в этой ветке был ./ , который работает, но выглядит немного странно. \ на данный момент неизвестен без исследования. Может работать, может вызвать неизвестные конфликты с побегом. Это более чистый синтаксис с (потенциально, но неизвестно) более высоким риском. Если кто-то потратит время на демонстрацию того, что это НЕ приведет к конфликту, т.е. предоставит примеры экранирования и смешения математики таким образом, чтобы синтаксический анализатор мог четко различить их, то это все еще возможно. Так что это просто требует работы. @thany , если вы или кто-то еще фанат этого, то это работа, которая требуется. Меньше всего нам нужно просто переместить перемычки в другое место.

Я думаю, чтобы упростить этот поток, мы должны, отсюда, сосредоточиться ТОЛЬКО на #3 . Я разместил пример Sass в основном из любопытства, но я не верю, что эти решения хороши или полностью решают проблему, и они концептуально несовместимы с Less. Споры о правомерности требования 0 + 1/2 ни к чему не приведут.

Итак, с хорошим решением для calc() , которое дает нам 50% пути решения большинства опубликованных проблем, я бы рекомендовал сосредоточиться на этом вопросе только в краткосрочной перспективе:

Если нужно изменить оператор деления Less, на что его нужно изменить?

• ./ - это так неудобно, как я чувствую, или люди думают, что это нормально?
• \ - без исследований и доказательств и псевдокода для парсера, это не продвинется вперед. Я лично предпочел бы это, если можно будет доказать, что он безопасен.
• Другие замены?

Честно говоря, если мы изменим calc() и изменим / , я думаю, мы бы заглушили 99% шума вокруг математики в Less.

Привет всем, я исправил calc() - https://github.com/less/less.js/pull/3162

Я был немного удивлен, когда пришел к решению, которое работало без особого дополнительного кода. По сути, у нас уже есть код для переключателя strictMath , и мы проверяем выражения, чтобы не оценивать математику, если она была вне скобок, поэтому я просто добавил дополнительный переключатель в вызов, чтобы выключить математику при оценке calc() args, а затем обратно. У нас уже было все необходимое, чтобы оставить математику в покое, но все же заменить vars. Хм.

Проверьте https://github.com/less/less.js/pull/3162/files#diff -a94aaffd78b1d3c5eda7a42d5be1ca0d и https://github.com/less/less.js/pull/3162/files#diff -4e696271823c9690493a91

Достаточно ли тестов?

@ Мэтью-Дин: кофе:

Достаточно ли тестов?

за комментарии в PR добавьте, пожалуйста, тест вроде:

foo: 1 + 2 calc(3 + 4) 5 + 6; // expected result: 3 calc(3 + 4) 11;

И небольшое замечание: это исправление, очевидно, представляет ту же проблему, что и в # 1627, т.е.

<strong i="13">@a</strong>: floor(1.1);
<strong i="14">@b</strong>: floor(1 + .1);

div {
    foo: calc(<strong i="15">@a</strong> + 20%); // ok
    bar: calc(<strong i="16">@b</strong> + 20%); // error: invalid floor arguments
    baz: @b;             // ok
}

Но для calc это нормально (в конце концов, просто нет других простых способов исправить это без серьезного переделывания концепции lazy-eval). Поэтому я думаю, что это просто вопрос размещения в документации примечания о ленивом eval при использовании vars в пределах calc .

И небольшое замечание: это исправление, очевидно, вызывает ту же проблему, что и в # 1627.

Хороший улов!

Переключение свойства контекста mathOn за вызов решает эту проблему, как и ваш комментарий в PR. Я добавил тест на float(1 + .1) который проходит!

Переключение свойства контекста mathOn для каждого вызова решает эту проблему, как и ваш комментарий в PR. Я> добавил тест на float (1 + .1), который проходит!

:) Нет, ошибка "этаж" должна быть при -sm: off . Смотрите мой новый комментарий в PR.
Восстановление касается только вещей, подобных 1 + 2 calc(3 + 4) 5 + 6 .

:) Нет, ошибка "этаж" должна быть при -sm: off.

Почему? Любые функции внутри calc() должны быть Less функциями. Даже если это не так, внутри calc () нет собственных функций CSS, которые, как я знаю, могли бы принимать необработанные математические выражения. Ожидаемым результатом будет оценка vars и функций Less, но необработанные функции внутри calc() оставьте в покое.

Боковое примечание: я провел эксперимент с ветвями, переключая / на \ в качестве оператора деления в Less. Уже существует множество тестов для экранирования (и я добавил их по адресу: # 3160), и все они по-прежнему работают нормально, а математика отлично работает с переключенными операторами. Я не видел внутреннего конфликта. На моей вилке есть ветка: https://github.com/matthew-dean/less.js/commit/509d34fff7e234846afa150b099cd259755a39d0

Re: вложенные функции

Для этого:

div {
    bar: calc(floor(1 + .1) + 20%);
}

Ожидаемый результат для разработчика:

div {
    bar: calc(1 + 20%);
}

Именно это и происходит сейчас (с этими изменениями). Это не должно вызывать ошибки.

@ Мэтью-Дин
Нет, как вы это написали, это:

foo: unit(1/2, px);

с -sm:on будет компилироваться в:

foo: .5px;

^ - неправильно.
То же самое для вложенных функций. Более того, тот факт, что большинство функций обычно не может принимать арифметические выражения в качестве аргумента, не является причиной нарушения -sm: on ;
Таким образом, в -sm: on обе строки:

foo: floor(1 + .1);
bar: calc(floor(1 + .1) + 20%);`

должен выдать ошибку (и это то, что нарушается при фиксации).

О чем ты говоришь?

unit(1/2, px) с -sm:on :

ERROR: error evaluating function `unit`: the first argument to unit must be a number. Have you forgotten parenthesis?

calc(floor(1 + .1) + 20%) с -sm:on

ERROR: error evaluating function `floor`: argument must be a number

Загляните в ветку. Попробуйте сами.

Одна вещь, которая может быть более полезной при проверке кода, заключается в том, что если вы не уверены, что что-то приведет к неправильному выводу, пожалуйста, проверьте это. Или попросите меня попробовать конкретный ввод, чтобы убедиться, что он работает должным образом. Или задавайте вопросы, если не знаете, как / почему это работает. Называть это неправильным, не зная, так ли это, бесполезно.

Мои извинения. Думаю, я упустил косвенный контроль над этой частью .

Загляните в ветку. Попробуй это

Я не могу, извини.

Мои извинения. Думаю, я упустил косвенный контроль над этой частью.

Не беспокойся. С этим обращением, похоже, он работает так, как вы ожидаете?

С этим обращением, похоже, он работает так, как вы ожидаете?

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

@ Мэтью-Дин
По сути измените оператор деления в Less. Ведущим соперником в этой ветке был ./, который работает, но выглядит немного странно. \ на данный момент неизвестен без исследования [...] @thany , если вы или кто-то другой поклонник этого, то эта работа требуется. Меньше всего нам нужно просто переместить перемычки в другое место.

Вовсе нет. Я предложил оператор \ в качестве последнего средства после того, как не прошел, пытаясь заставить LESS выполнять только свои собственные математические вычисления. Если нужен новый оператор деления ... Ну, calc() также может выполнять сложение, вычитание и умножение. Новые операторы для тех? Думаю, это непрактично. Новый оператор деления может быть решением для таких вещей, как font, background и border-radius, но это не решение для математики CSS.

Я по-прежнему думаю, что реальное решение - МЕНЬШЕ знать о контексте. Он должен (да, здесь я снова иду со своим «следует», какое еще слово я должен использовать? ...) знать, что calc() - это функция CSS, и он должен оценивать только математические вычисления, которые CSS не может выполнить. . Но floor() не существует в CSS, поэтому его пришлось бы оценивать (полностью), чтобы не выдавать недопустимый CSS. Я думаю, что об этом говорилось раньше, но в другой формулировке.

Я по-прежнему думаю, что реальное решение - МЕНЬШЕ знать о контексте. Он должен (да, здесь я снова повторяю свое «следует», какое еще слово я должен использовать? ...) знать, что calc () - это функция CSS, и он должен оценивать только математику, которую CSS не может выполнить. Но floor () не существует в CSS, поэтому его пришлось бы оценивать (полностью), чтобы не выдавать недопустимые CSS. Я думаю, что об этом говорилось раньше, но в другой формулировке.

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

12px/10px  // Is this division, or not?
10px/1.5 // is this division, or not? 

Если вы хотите определенно оставить / в качестве оператора деления, чтобы имитировать calc() и не допускать двусмысленности, тогда вам абсолютно необходимо убедиться, что / находится в круглые скобки (кроме исключения calc() ). Это обеспечит предсказуемый контекст.

Это предложение в начале этой беседы также возможно и получило широкую поддержку. По сути, настройка по умолчанию заключается в том, что вся математика поддерживается за пределами круглых скобок, ЗА ИСКЛЮЧЕНИЕМ деления (и снова, за исключением calc() , теперь имеет место с версии 3.0+). Может быть, это правильный путь. Это позволило бы:

font: 10px/1.5;   // not division
font: (10px/10);  // division, result is 1px
font: 10px+15px/1.5;   // addition but not division, result is 25px/1.5
font: (10px+15px/1.5);  // result is 20px

Дело в том, что результат для 10px+15px/1.5 все еще может быть трудным для разработчиков, с выражением, которое, кажется, получает «половинную оценку», если оно не заключено в круглые скобки. Если бы мы пошли дальше и включили строгую математику по умолчанию, это, вероятно, было бы хорошо. Это еще менее неоднозначно. [пожимают плечами] В любом случае, обертывание математики в какой-то контекст - это способ устранить двусмысленность и единственный способ деления, кроме изменения оператора деления.

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

Последний призыв к решению

Итак, чтобы сделать невозможное, я хотел бы предложить, чтобы мы это сделали (ссылаясь на комментарии трехлетней давности).

Дайте --strict-math 3 настройки

1. выключенный
2. разделение
3. strict (псевдоним on для обратной совместимости)

Чтобы уладить спор, позвольте переключателю --strict-math=division сделать следующее:

1. Не выполняйте деление, используя только символ / за пределами круглых скобок. Например, border-radius: 55px / 25px; -> без математики (да, это правильный CSS)
2. Разрешить разделение двумя разными методами:
   а. . префикс - border-radius: 55px ./ 25px;
   б. круглые скобки - border-radius: (55px / 25px);
3. Обе формы действительны в круглых скобках - например, border-radius: (55px ./ 25px); будет действительным

Итак, если вы как разработчик считаете, что одна версия вам не нравится, вы можете использовать другую. Некоторые могут предпочесть не использовать круглые скобки; некоторые могут предпочесть не использовать модифицированный оператор деления. Что-то для каждого. И больше никаких неприятных сюрпризов для новичков в Less, использующих широко распространенный синтаксис в CSS, где / используется в font , background , border-radius , @media запросы, свойства CSS Grid и, возможно, многое другое в будущем.

Следующие шаги

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

@ Мэтью-Дин

Т.е. период действует как обратная последовательность escape-последовательности?
Неплохая идея, правда ...

И, учитывая все обстоятельства, _ вероятно_ одно из самых чистых возможных решений.

@rjgotten Начал здесь: https://github.com/matthew-dean/less.js/tree/strict-math-division

Я все еще получаю странную ошибку в одном из тестов, где он, кажется, превращает один из узлов измерения в рабочий узел (а затем выдает ошибку, потому что он не может выполнить операцию на рабочем узле. Кажется, это проблема синтаксического анализа, потому что другой тест, запущенный не под strictMath: division работает нормально. Хотите проверить его и посмотреть, сможете ли вы помочь?

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

1. Разделение обработки и функция strictMath: 'division' .
2. Обработка математики смешанных единиц. См. Https://github.com/less/less.js/issues/3047