Less.js: Условный код CSS

перейдите на http://www.lesscss.org/ и найдите охранников.

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

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

.button-maker (<strong i="8">@style</strong>: 'light') {
    cursor: pointer;
    display: inline-block;
    padding: 5px 10px;

    if(<strong i="9">@style</strong> == 'light'){
        /* adds light styling */
    }

    if(<strong i="10">@style</strong> == 'dark'){
        /* adds dark styling */
    }
}

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

Мы можем даже добавить оператор switch.

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

LESS не является языком сценариев. Синтаксис/стиль напоминает CSS.

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

@pierresforge , у вас есть примеры, когда охранников недостаточно?

и где это не было бы решено, если бы у любого селектора были охранники?

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

Предложение с http://lesscss.org/
«LESS расширяет CSS с помощью динамического поведения, такого как переменные, примеси, операции и функции».

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

Я думаю, что CSS Media Query — это не что иное, как условная логика.

<strong i="11">@media</strong> all and (max-width: 699px) and (min-width: 520px), (min-width: 1151px) {
  body {
    background: #ccc;
  }
}

Если CSS может иметь условную логику, такую ​​как охранники. так в чем разница. Охранники просто расширяют его до миксинов.
Guards разрешает условия только за пределами блока кода CSS, а не внутри блока кода.
Например, см. https://github.com/cloudhead/less.js/issues/1293#issuecomment -16929701, охранники не могут помочь с таким требованием.

Даже в HTML есть условная логика, да, и это язык разметки, а не язык сценариев.

<!--[if gte IE 9]><!-->        
    <script src="" />
<!--<![endif]-->

@lukeapage спасибо..

Охранники аналогичны тому, что делают медиа-запросы. Обратите внимание, что в обычном CSS вы не можете вкладывать медиа-запросы внутрь селекторов; Вы можете поместить их только в корень документа.

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

Пример:

.button {
  .inline-block();
  .fix-ie-left-padding();
  .shadow(0, 2px, rgba(0, 0, 0, @buttonShadowOpacity));
  .border: 1px solid @buttonBorderColor;

  if (green(@coreBackgroundColor) > 50%) {
    background-color: darken(<strong i="7">@coreBackgroundColor</strong>, 20%);
  }
  else if (red(@coreBackgroundColor) > 30%) {
    background-color: darken(<strong i="8">@coreBackgroundColor</strong>, 15%);
  }
  else if (blue(@coreBackgroundColor) > 25%) {
    background-color: darken(<strong i="9">@coreBackgroundColor</strong>, 8% );
  }
  else {
    background-color: @coreBackgroundColor;
  }
}

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

.buttonBackground(@color) when (green(@color) > 50%) {
  background-color: darken(<strong i="13">@coreBackgroundColor</strong>, 20%);
}

.buttonBackground(@color) when (red(@color) > 30%) {
  background-color: darken(<strong i="14">@coreBackgroundColor</strong>, 15%);
}

.buttonBackground(@color) when (red(@color) > 25%) {
  background-color: darken(<strong i="15">@coreBackgroundColor</strong>, 8%);
}

.buttonBackground(@color) {
  background-color: @color;
}

.button {
  .inline-block();
  .fix-ie-left-padding();
  .shadow(0, 2px, rgba(0, 0, 0, @buttonShadowOpacity));
  .border: 1px solid @buttonBorderColor;
  .buttonBackground(@coreBackgroundColor);
}

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

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

@Soviut Адвокат дьявола - в LESS вы МОЖЕТЕ разместить свой медиа-запрос внутри селектора, что часто бывает весьма полезно.

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

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

.button {
  .inline-block();
  .fix-ie-left-padding();
  .shadow(0, 2px, rgba(0, 0, 0, @buttonShadowOpacity));
  .border: 1px solid @buttonBorderColor;

  background-color: @coreBackgroundColor;

  <strong i="9">@when</strong> (green(@coreBackgroundColor) > 50%) {
    background-color: darken(<strong i="10">@coreBackgroundColor</strong>, 20%);
  }
  <strong i="11">@when</strong> (red(@coreBackgroundColor) > 30%) {
    background-color: darken(<strong i="12">@coreBackgroundColor</strong>, 15%);
  }
  <strong i="13">@when</strong> (blue(@coreBackgroundColor) > 25%) {
    background-color: darken(<strong i="14">@coreBackgroundColor</strong>, 8% );
  }
}

or

.button {
  .inline-block();
  .fix-ie-left-padding();
  .shadow(0, 2px, rgba(0, 0, 0, @buttonShadowOpacity));
  .border: 1px solid @buttonBorderColor;

  background-color: @coreBackgroundColor;  
  background-color: darken(<strong i="15">@coreBackgroundColor</strong>, 20%) when (green(@coreBackgroundColor) > 50%) ;
  background-color: darken(<strong i="16">@coreBackgroundColor</strong>, 15%) when (red(@coreBackgroundColor) > 30%);
  background-color: darken(<strong i="17">@coreBackgroundColor</strong>, 8% ) when (blue(@coreBackgroundColor) > 25%);
}

Более декларативный, чем ifs, более близкий синтаксис к существующему LESS и оценивает каждое выражение независимо (как определено LESS/CSS).

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

.button {
  .inline-block();
  .fix-ie-left-padding();
  .shadow(0, 2px, rgba(0, 0, 0, @buttonShadowOpacity));
  .border: 1px solid @buttonBorderColor;

  background-color: @coreBackgroundColor;  
  .backgroundMixin(<strong i="22">@coreBackgroundColor</strong>, 20%) when (green(@coreBackgroundColor) > 50%) ;
  .backgroundMixin(<strong i="23">@coreBackgroundColor</strong>, 15%) when (red(@coreBackgroundColor) > 30%);
  .backgroundMixin(<strong i="24">@coreBackgroundColor</strong>, 8% ) when (blue(@coreBackgroundColor) > 25%);
}

Возможно, охранники на уровне операторов не более/менее сложны или отличаются по логике, чем охранники на уровне примесей IMO. Вероятно, примеры 2 и 3 менее обширны для языка. Просто подумал, что добавлю это сюда для размышлений/обсуждений.

Я полагаю, что никто особо не возражал против моего предложения по защите декларации. ;-)

На самом деле, нет, нечего сказать. Это было бы просто здорово, имхо :)

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

@matthewdl :+1:

Думаю, я уже поддержал их в вопросе, который они обсуждают.... :)

@lukeapage Вы говорите о выпуске № 748? Если да, то я немного добавил в синтаксис. ;-)

Я хотел бы присоединиться к выражению моего желания получить некоторую форму if или @when .

Я не согласен с мнением, что охранники всегда лучше и делают МЕНЬШЕ код менее сложным, чем использование условных выражений. Я нахожу практические ситуации, когда охранники на самом деле делают мои файлы LESS более уродливыми и трудными для чтения, но if / @when на самом деле будут исключительно читабельными. Охранники и условные операторы if / @when по своей сути являются просто инструментами, оба они могут быть использованы, чтобы сделать вещи красивыми или безобразными, и они лучше подходят для различных ситуаций. Черт, я могу создать файл .less ~ 300b, который использует только самую базовую функцию расширения селектора LESS, чтобы съесть более 1 ГБ ОЗУ и заставить процессор работать в течение нескольких минут.

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

Мое решение состояло в том, чтобы взять пример из того, как MediaWiki обрабатывает RTL, отдав две таблицы стилей из одной. MediaWiki делает это, записывая таблицы стилей в LTR, а затем переворачивая таблицу стилей, чтобы создать вторую таблицу стилей RTL. Нет необходимости пытаться переопределить все, что указано для LTR, для обработки RTL. Точно так же я решил написать свои основные стили в файле main.less (и, возможно, в файлах, на которые он ссылается, чтобы разделить стили), этот файл не будет компилироваться напрямую. Вместо этого у меня было бы две таблицы стилей: desktop.less и mobile.less, обе из которых устанавливали бы такие вещи, как <strong i="14">@mobile</strong>: true/false; , <strong i="16">@desktop</strong>: true/false; , а также переопределяли бы некоторые переменные less, такие как размеры вещей. Таким образом, мой main.less превращается в desktop.css и mobile.css, и я могу обрабатывать медиа-запрос/тест, определяя, какой из них загружать в другом месте (если бы я ДЕЙСТВИТЕЛЬНО хотел, я мог бы фактически определить, какой из них загружать даже на устройстве, которое даже не поддерживает медиа-запросы).

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

.navigation {
  color: @text-color;
  // [...]
  // Navigation is an accordion on the desktop so include our accordion styles
  .dummy() when (<strong i="21">@desktop</strong> = true) {
    .accordion-styles();
  }
  .dummy();
}

В этой ситуации было бы намного понятнее использовать что-то вроде @when .

.navigation {
  color: @text-color;
  // [...]
  // Navigation is an accordion on the desktop so include our accordion styles
  <strong i="26">@when</strong> (<strong i="27">@desktop</strong> = true) {
    .accordion-styles();
  }
}

На самом деле я подумывал о предварительной обработке моих файлов less, чтобы превратить что-то вроде синтаксиса @when в хак, где создается динамически генерируемый миксин + защита, а затем включается сразу после него.
Излишне говорить, что если идея предварительной обработки препроцессором кажется хорошей идеей, которая облегчит понимание... что-то не так с текущим препроцессором.

И правда в том, что это относится не только к моей настольной/мобильной технике. Это может в равной степени относиться и к схемам тем. Напишите на один основной файл меньше с вашей темой. Затем создайте кучу файлов меньшего размера, в которые вы просто включите этот файл меньшего размера, а затем установите несколько переменных меньшего размера для управления такими вещами, как цветовая схема. Цветовые настройки будут работать нормально, но вы сразу же сбежите с обрыва, как только обнаружите, что действительно можете использовать что-то вроде @use_horizontal_nav .

@dantman с версии 1.5.0 и охрана связанных стилей css, вы можете это сделать

.navigation {
  & when (<strong i="7">@desktop</strong> = true) {
    color:red;
  }
}

который является сахаром для вашего примера.

Единственным недостатком является то, что на данный момент он думает, что это новый селектор, поэтому он не объединяет его с предыдущим селектором. Однако я думаю, что это вряд ли вызовет у вас проблемы, и я/мы исправим это в будущих версиях.

Хорошо, спасибо, мы можем задокументировать это как функцию?

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

Я согласен с @matthew-dean, добавление такого рода условных структур, вероятно, затруднит поддержку и тестирование основных файлов LESS. А файлы .less сложнее отлаживать и так далее.

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

Если разработчику требуется большая сложность и контроль над своими LESS-файлами перед их компиляцией, ничто не мешает им использовать такие языки, как PHP, для предварительной обработки меньшего количества файлов, чтобы добиться большего контроля, гибкости и сложности, есть много способов сделать это. сделать это — это просто вопрос использования воображения, чтобы сделать это наиболее правильным или удобным способом.

Например, если не сказать, что у меня есть файл с именем «myfile.less.php», в котором есть сумасшедший код с условными выражениями, переключателями, массивами и всеми причудливыми вещами, которые вы можете увидеть в PHP, а затем из этого файла «.less.php» выплюнуть другой файл называется «myfile.less», которые имеют окончательный код LESS, таким образом, я могу запросить все переменные сервера с помощью PHP, решить, что @imports мой новый файл .less будет включать или исключать, больше не нужно передавать большое количество глупых переменных в компилятор LESS, и нет необходимости писать уродливые, трудно читаемые глупые охранники, имитирующие моделирующие структуры IF или Switch.

Базовый рабочий процесс может быть таким

1- проверить, не истек ли срок действия кеша
1- вызвать скрипт для поиска и предварительной обработки всех файлов ".less.php"
2- вызвать скрипт для компиляции всех файлов ".less"
3- обновить кеш

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

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

@lukeapage , да, я недавно это заметил. Я просмотрел журнал изменений и заметил такие вещи, как слияние svg-gradient и свойства с +.

Строго говоря, & when ... уже задокументировано, так как это просто комбинация двух документированных функций & и CSS Guards . Но отдельный пример не повредит конечно.

@ семь-фаз-макс, я не знал об этой документации. Судя по всему, это неполный новый набор документации для замены старого сайта, а именно: «Скоро это будет перемещено в репозиторий lesscss.org! Мы рекомендуем вам избегать ссылок на этот сайт, пока все не будет запущено». комментарий. Приятно осознавать, что что-то подобное находится в разработке.

Я имел в виду текущую документацию на lesscss.org, которая была единственной документацией, о которой я знал, и в настоящее время только документы охраняются как функция миксина, не предполагая, что она доступна где-либо еще.

Охранники не так хороши, как это. :(

Это обязательная функция, которая также присутствует в scass.

+1 за это

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

Некоторое сопротивление @when в первоначальном обсуждении связано с дополнительным правилом at. Однако, если подумать об этом сейчас, это не должно быть необходимо.

Учитывая, что эти два блока равны:

.a {
  & .b { color: blue; }
}
.a {
  .b { color: blue; }
}

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

.a {
  & when (1=1) { color: blue; }
}
.a {
  when (1=1) { color: blue; }
}

Если ни по какой другой причине, но & when синтаксически очень неудобно. Отсутствие & означает, что соединение селектора с родительским селектором существовало все время, поэтому исключение & для обозначения защиты родительского селектора не кажется прыжком. Кроме того, блочные корневые функции теперь принимаются парсером для использования с плагинами, так что это уже не выглядит так странно, как могло бы быть в 2013 году.

Я не вижу никаких причин, чтобы открыть это снова. Ведь у нас уже есть #2072

when (1=1) { color: blue; }

Открывать большую коробку путаницы только ради экономии на двух персонажах?

Охранники не так хороши, как это.

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

Я не вижу никаких причин, чтобы открыть это снова. Ведь у нас уже есть when (1=1) { color: blue; }

Эээ... нет?

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

Подождите, пока я не найду запрос функции, на который он должен ссылаться (извините, я случайно нажал Enter, прежде чем закончить его)

Итак, объединяем это с # 2072.

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

Эта проблема называется «Разрешить переопределение переменных внутри защищенных самозапускающихся блоков», а тангенциальное обсуждение внизу этой проблемы содержало аналогичные варианты использования для select / case и vbscript iif([ifcond], [then], [else]) функция больше, чем просто голый, когда, хотя это, возможно, более логичный выбор для обсуждения. Но... возможно, это следует просто поднять как новую проблему только с вопросом when () против & when () .

только с вопросом когда () против и когда ().

Вы не можете быть серьезным на этом, не так ли? Из-за чего именно? when не станет if (все причины см. в #2072), если вы удалите & . Так что оставь как есть и покончим с этим.

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

Я не хотел обидеть или что-то в этом роде.
Мой:

Так что оставь как есть и покончим с этим.

был просто ответ на:

Мы могли бы просто позволить это и покончить с этим.

@seven-phases-max Ладно, тон в тексте теряется. В любом случае, я не был сильно привязан к этой идее, и в целом существующее предложение @when в любом случае лучше/более универсально.

Я думаю, что «дерзость» лучше, чем меньше. У него уже есть if-else. Это действительно сложно, и тем меньше строк кода. Когда работает, но не полностью заполняет потребность. Кроме того, мы можем делать циклы меньше, но язык должен иметь свою особенность.

@aukgit Используйте правильный инструмент для работы. Если вам больше подходит SCSS, лучше использовать его. Sass и Less — очень разные проекты.

@matthew-dean после того, как месяцами меньше учился и писал намного меньше, если «меньшее» сообщество не хочет быть лучше, то это потеря для нас обоих. Я думаю, именно поэтому начальная загрузка перешла на «sass» (https://github.com/twbs/bootstrap/tree/v4-dev) из меньшего (первоначальной причиной была более быстрая компиляция). Принимая во внимание, что первоначальный источник был в «менее». Теперь они пишут свой первоисточник в «sass», а затем конвертируют его в less (тогда как было наоборот).

Еще одна вещь :

«Правильный инструмент для правильной работы»

не следует применять здесь

Меньше | Сксс | Стилус подобных проектов. Начал с того, что было популярно в то время, теперь кажется, что это «меньшее» сообщество не хочет улучшать себя.

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

Спасибо за ваши Коментарии.

Фанатская устаревшая пропаганда. Было бы пустой тратой времени спорить со всеми этими предвзятыми или просто ложными утверждениями.

Например:

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

Ага, «Мне нужен инструмент для написания моего спагетти-кода» — вот так . Если вы пишете такой код, Less определенно не ваш инструмент.

Я думаю, что «меньше» делает «x» чем-то совсем другим, чем дерзость и стилус. Все остальные делают подобные вещи, тогда как «меньше» утверждает, что это не похоже. :)

@аукгит

Я думаю, что «меньше» делает «x» чем-то совсем другим, чем дерзость и стилус.

_Почему_ он должен делать то же самое? См., например, [1] и [2] , чтобы найти основные различия между конструкциями. Таким образом, вам может не нравиться концепция, но никто не заставляет вас использовать инструмент, который вам не нравится.

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

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

Спасибо.

Написал миксен:

Меньше:

.if-value-present(@attribute; <strong i="7">@value</strong>: '') {
    .x (@value) when not (<strong i="8">@value</strong> = '') {
        @{attribute}: @value;
    }

    .x(@value);
}

.if-value-present-multi(@attributes; @values) {
    .iter(@i) when (<strong i="9">@i</strong> > 0) {
        .iter(<strong i="10">@i</strong> - 1);
        // loop

        <strong i="11">@attr</strong>: extract(<strong i="12">@attributes</strong>, @i);
        <strong i="13">@value</strong>: extract(<strong i="14">@values</strong>, @i);

        .if-value-present(<strong i="15">@attr</strong>, @value);
    }

    <strong i="16">@len</strong>: length(@values);
    .iter(@len);
}
.x {
    <strong i="17">@var</strong>: c1,c2, c3;
    <strong i="18">@val</strong>: v1, '', 'wddww';
    .if-value-present-multi(@var;@val);
}
.x{
    .if-value-present(content, 'new val');
}

Вывод CSS:

.x {
  c1: v1;
  c3: 'wddww';
}
.x {
  content: 'new val';
}

если «меньшее» сообщество не хочет быть лучше, то это потеря для нас обоих

Я думаю, что было бы ошибкой предполагать, что «функция X, которую я хочу, не поддерживается» == «Меньше сообщества не хочет быть лучше». Это нас никуда не приведет.

На Github есть несколько дискуссий по улучшению потоков управления. На самом деле, эта тема не была отклонена, она была объединена с #2072. Вы прокомментировали закрытую ветку трехлетней давности. У меня были и другие идеи, которые, как мне казалось, могли сделать его немного отличным от #2072, но я был убежден в обратном.

теперь кажется, что у него нет лучших функций

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

Теперь они пишут свой первоисточник в «sass», а затем конвертируют его в less (тогда как было наоборот).

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

В конце концов, ваши жалобы на то, что для написания условных выражений нужны обручи, _не так_. Предлагаемые здесь примеры просто плохо подходят для языка. Я предлагаю вам прочитать ветку в # 2072.

(это на самом деле немного оффтоп, но мне просто интересно)

<strong i="7">@var</strong>: c1, c2, c3;
<strong i="8">@val</strong>: v1, '', 'wddww';

И какая польза от этих переменных, кроме вызова .if-value-present-multi ?
(И _if_ эти переменные _are_ используются для чего-то другого) Разве не имеет смысла вместо этого использовать только пары свойство/значение, например:

<strong i="14">@rules</strong>:
    c1 v1,
    c3 'wddww';
   // no need for c2 since it has no effect

Более того, зачем писать .x {.if-value-present(content, 'new val')} , если вам нужно всего лишь .x {content: 'new val'} ? А написать .x {.if-value-present(content)} , если это ничего не даст?

(Хотя, честно говоря, я просмотрел [1] - ну, ничего не комментируя, кроме одного: (_просто для экономии вашего времени_) подумайте о том, чтобы выбросить древние библиотеки, такие как elements и lesshat - и вместо этого используйте autoprefixer .Нам пока не нужны библиотеки с префиксами поставщиков ни для одного из препроцессоров CSS).

Обычно именно так поступает большинство «запросов функций»: «Проблема XY» . (Другие хорошие примеры подобных сбоев в смежной области: #1400 и #1894, дело не в том, что функции были бы совершенно бесполезными (поэтому обе они остаются открытыми), но когда кто-то начинает спрашивать их фактические варианты использования, это обычно показывает это было просто неправильно Y в попытке решить X).

Ну вот вариант использования:
Я попытался создать микс с 3 параметрами, если последний не указан, тогда он должен создать свой атрибут внутри микса, поэтому условия были полезны.

Здесь https://github.com/aukgit/WeReviewProject/blob/master/WereViewApp/Content/Less/remixens/responsive/responsive-placements.less я пытался реализовать один и тот же миксен снова и снова, где я мог бы этого добиться. с условиями очень легко .

Теперь понял.. Всем спасибо.

@aukgit Вы должны легко свернуть эти миксины.

https://gist.github.com/matthew-dean/e617bc1f71528843ef9fa73d70427bcf

Спасибо, @matthew-dean, что уделил мне время и помог. :) Я большой полный к вам.

:)

Я думаю, что «дерзость» лучше, чем меньше. У него уже есть if-else.

Оба языка имеют свои проблемы.

Отсутствие у них динамического импорта — и их нежелание его реализовывать — основная причина, по которой я хотел бы перейти с Sass на Less. У Less была эта функция в течение многих лет!

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

Я чувствую себя застрявшим между молотом и наковальней...

@jslegers Тот же комментарий, что и в № 249. Less имеет различные формы (все больше и больше в новой версии) условных ограничений, начиная с v1.x.

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

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

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

Во всяком случае, что-то вроде...

scss a { <strong i="11">@if</strong> $time == morning { color: red; } <strong i="12">@else</strong> if $time == afternoon { color: blue; } <strong i="13">@else</strong> { color: grey; } }

... или что-то вроде ...

scss <strong i="17">@each</strong> $author in $list .photo-#{$author} background: image-url("avatars/#{$author}.png") no-repeat

... или это...

scss <strong i="21">@for</strong> $i from 1 through 8 { $width: percentage(1 / $i) .col-#{$i} { width: $width; } }

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

Отсутствие таких утверждений и в целом менее читаемый синтаксис Less (по сравнению с Sass) — две основные причины, по которым я предпочитаю придерживаться Sass, и я не хочу даже рассматривать Less для одного из моих проектов.

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

@jslegers Для ваших примеров - постарайтесь узнать, что уже доступно, прежде чем публиковать их.
В остальном (популярность и т.п.) - нет смысла обсуждать что-то в таком упрощенном виде (все это есть в Stylus и что с того?), к тому же Less никогда не заявлялся ни для замены других CSS-препроцессоров, ни для того, чтобы стать их клоном. И, наконец, самая распространенная ошибка — думать, что популярность чего-то является главной и единственной целью авторов этого чего-то.

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

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

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

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

Тем не менее, если вы посмотрите, почему люди переходят с Less на Sass, это довольно просто …

Лично я не вижу там ничего, кроме обычного «Я хочу мои спагетти PHP» (см. посты о неправильном инструменте выше), даже не считая его 2012 года (я уже намекал, что большинство этих примеров довольно компактны в современном Less, но это кажется, вы не хотите просыпаться).
Но ничего, обычно я только аргументирую явную дезинформацию, обсуждение личных мнений о том, почему что-то происходит или не происходит, совершенно не в моем интересе.

Лично я там ничего не вижу, кроме обычного "хочу свои PHP-спагетти"

Мне кажется, что использование Less вместо Sass неизбежно делает ваш код похожим на «спагетти PHP» (если вы думаете, что PHP — это воплощение спагетти-кода, вы, очевидно, никогда не программировали на ABAP), как только вы захотите сделать что-то более сложное. чем базовые переменные и примеси, но я готов считать, что здесь я не прав.

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

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

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