Less.js: Невозможно создать эллиптическую границу с радиусом

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

.class {
    font: 13px/1.231 arial, helvetica, clean, sans-serif;
} 

он должен оставаться неизменным, но становится:
.класс {
шрифт: 10.560519902518276px arial, helvetica, clean, sans-serif;
}

У dotless также есть эта проблема (https://github.com/dotless/dotless/issues/16). Было бы неплохо прийти к соглашению, как действовать в обоих случаях.

Самое простое решение, которое сегодня работает «из коробки», - это заключить его в строковый литерал.

 font: ~"13px/1.231 arial, helvetica, clean, sans-serif";

или даже

 font: ~"13px/1.231" arial, helvetica, clean, sans-serif;

Я понял, что одна из целей less - совместимость с обычным синтаксисом CSS. Работа вокруг нарушает это правило.

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

 <strong i="6">@example</strong>: 24pt;
 .foo {
     font: normal @example/2 sans-serif;
 }

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

 font: normal (@example/2) sans-serif;

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

 <strong i="13">@import</strong> "legacy.css";

В этом случае импорт проходит успешно, но не изменяет и не преобразует CSS.

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

: +1: по этой проблеме от меня, но я также не уверен в элегантном способе ее решения, который не требует либо экранирования действительного CSS, либо скобок для запуска вычислений.

@agatronic @cloudhead Я работаю над исправлением этого, но я хотел бы получить ваше мнение о том, как, по вашему мнению, следует поступать, прежде чем я продолжу. SASS и Stylus справляются с этим, разрешая деление только внутри круглых скобок, все остальные математические операции могут выполняться вне скобок. Этот метод предотвратит нарушение любых будущих реализаций косой черты W3C и устранит необходимость в парсерах Ratio и Shorthand. Так я впервые решил исправить проблему. Это разумное решение для вас обоих?

Обратите внимание, что эта ошибка также нарушает сокращение фона CSS3, в котором используется косая черта для отделения background-position (которые могут быть ключевыми словами или размерами) от background-size. Например:

.foo {
    background: url(image.png) center / 1px 100px;
}

Также пингует @matthewdl @Synchro

Предыдущее предложение заключалось в том, что «/» делит, а «/» - это соотношение. Было бы неплохо получить ввод от @cloudhead, потому что, хотя было бы действительно неплохо получить сортировку, это довольно страшно, если это нарушит существующее поведение ...

@cloudhead ответил через твиттер, несколько минимально: «Парен-решение кажется приличным».

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

как насчет «временного» варианта, чтобы люди могли пользоваться обоими в течение льготного периода?

или же

мы должны выпустить релиз непосредственно перед объединением этого исправления и повысить номер основной версии до 1.4 (и, надеюсь, добавить переменные в include, интерполяцию имен свойств и т. д.)

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

Я имел в виду флаг, чтобы сохранить существующее поведение .. но я согласен с вами.

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

Лично я считаю, что мы должны проглотить таблетку и начать перечислять математические операции без скобок как устаревшую функцию. Слишком много случаев, когда он конфликтует с действующим CSS. @agatronic - стоит обсудить в Skype с @cloudhead (или где-нибудь еще), и я очень не хочу разрушать чьи-либо библиотеки LESS, но LESS не должен вырывать и ломать CSS, чего не планировал автор. Парсеру LESS должны быть предоставлены четкие сигналы о необходимости математической операции, и круглые скобки - хороший способ сделать это. В скобках: DO MATH. Не в скобках: оставьте его в покое.

В качестве этапа 1, чтобы уменьшить удар, мы могли бы ПРЕКРАТИТЬ математику ТОЛЬКО в тех случаях, когда деление неоднозначно, например, в местах, где косая черта «/» является допустимым символом в этом значении. Итак, в случае радиуса границы, если LESS не уверен, он оставляет его в покое. Если автор уверен, что хочет разделить два числа, он может изменить поведение по умолчанию, добавив круглые скобки.

Но на данный момент LESS задокументирован как «действительный CSS = действительный LESS», и с этой ошибкой это не так. Он ошибочно переписывает действительный CSS, что делает его явной ошибкой. Проблема в том, что это ТАКЖЕ четко задокументированная математическая операция. Они находятся в противоречии, и мне кажется очевидным, что второй случай - это тот, который следует изменить, сохранив CSS.

Я вижу, что @ttfkam и @ mlms13 сказали примерно то же самое. Я думаю, что их инстинкт верен, и я бы решительно проголосовал за то, чтобы LESS начал медленный переход к круглым скобкам, который является требованием для операций.

@matthewdl +1

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

@matthewdl : В целях своего пиара я начал работу с разрешения деления только в круглых скобках. Считайте это временной мерой, чтобы LESS не нарушил действующий CSS. Он не ограничен конкретными правилами, поэтому везде, где встречается косая черта, и она не заключена в скобки, она будет выводиться как буквальный ограничитель. Как только это будет сделано, я немного подробнее рассмотрю, как ограничить выполнение всех операций только внутри скобок.

Хорошо, я обсудил это с @cloudhead в Skype. Он согласен, так что вот план:

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

2) В следующем выпуске после шага №1 для ВСЕХ математических операций потребуются круглые скобки. Документация изменится с «не рекомендуется» на «не поддерживается» (или что-то в этом роде - как мы это сообщаем, можно уточнить).

Звучит неплохо? Это означает, что мы должны начать планировать основные этапы следующих двух выпусков, но это выходит за рамки этой темы.

На самом деле, чтобы уточнить, документацию можно обновить СЕЙЧАС, чтобы сказать, что математика за пределами круглых скобок устарела, поскольку математика в круглых скобках работает нормально. Итак, это действительно Шаг 0: мы обновляем документацию сейчас, чтобы сообщить людям: а) Математика должна быть в круглых скобках, и если этого не делать, в будущем может произойти сбой, б) Продемонстрировать всю математику в скобках.

Работает для меня! : +1:

поэтому предположительно @dmcass должен сделать запрос на
https://github.com/cloudhead/lesscss.org

а затем нам нужно заставить @cloudhead сделать коммит или дать нам права на коммит для этого проекта?

О верно. Да, я постараюсь напомнить ему сегодня об этом.

21 августа 2012 г., в 5:19, Люк Пейдж [email protected] написал:

поэтому предположительно @dmcass https://github.com/dmcass должен выполнить запрос на перенос
против
https://github.com/cloudhead/lesscss.org

а затем мы должны заставить @cloudhead https://github.com/cloudhead
совершить или предоставить нам права коммитирования на этот проект?

-
Ответьте на это письмо напрямую или просмотрите его на
Gi tHub https://github.com/cloudhead/less.js/issues/146#issuecomment -7899194.

Я открыл PR для обновления документации на cloudhead / lesscss.org # 29.

Исправлено на мастере для 1.4.0

Так будет в 1.4.0

Посмотрите альфа-версию на less2css.org

Эта ошибка все еще возникает в 1.4.1, если вы используете следующий CSS:
border- radius: 0 0 100% 100% / 0 0 24px 24px;

Он выводит:
радиус границы: 0 0 100% Бесконечность% 0 24px 24px;

(Пробовал на http://less2css.org)

@rubious вы

Хорошо, это работает, однако я использую LiveReload, и эта опция, похоже, не включена.

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

border-radius:0 0 100% 100% ~"/" 0 0 24px 24px;