Starche 18 авг 2014 в 10:11

Малоиспользуемые, но от этого не менее прекрасные возможности LESS

5 мин

35K

Веб-разработка * CSS *

Из песочницы

+68

Комментарии 22

radist2s 18 авг 2014 в 11:17

А фишки и правда новые, переходя по ссылке я ожидал прочитать про то, что уже и сам знаю, ан нет.
Ну и про Autoprefixer — если вы его еще не используете — делаете себе же хуже. По началу я было сомневался, так как и не надеялся сохранить корректный source map, но Autoprefixer так крут, что после тривиального колдовства с конфигом в веб-инспекторе будут отображаться корректные пути к исходным файлам.

extonec 18 авг 2014 в 11:20

Примеры использования которые вы показали, полезны, когда под рукой нет ничего кроме заготовочек less.
В работе же, задачи слияния классов и свойств, генерацию безошибочных спрайтов, префиксов, выполняют Grunt/Gulp.
Комфортнее писать CSS3 без лишних символов, зависящих от препроцессора.

Starche 18 авг 2014 в 14:23

Не очень понял, как Grunt (или Gulp) помогут в той части, которая касается слияний. Из моего опыта: довольно часто происходит так, что на элемент наложено 3-4 транзишна и он имеет несколько состояний. При этом отличия в тразишнах для разных состояний только в одном из этих четырех, а переписывать приходится полностью. Тут отлично поможет миксин на неизменяемую часть и объединение через запятую.
Если Grunt как-то здесь может помочь, то не могли бы вы направить в какую сторону смотреть?
В остальном несомненно, вы правы. Однако не только этими примерами ограничивается применение указанных возможностей: циклы (через рекурсию) можно применить при генерации сетки (так делает bootstrap), передача кода как параметр поможет заменить длинные media query (пожалуй, добавлю это в статью), условия вообще полезная штука.
Ну а использовать или не использовать препроцессоры — это настолько холиварная тема, что даже касаться не хочется

extonec 18 авг 2014 в 16:06

По поводу слияний, я подразумевал минификаторы (мне нравится: clean-css, для Grunt это contrib-cssmin). Специально посмотрел, clean-css не делает слияния такого типа (разные транситионы), но, какой смысл писать одно свойство в классе двумя строчками? WebStorm сразу подсветит ошибку, пишу через запятую. Возможно другие минификаторы так могут, мне хватает одного. Не забываем про @extend + работа clean-css по объединению, хороша.
Сам пользую scss естественно, первый комментарий в контексте «плюсов» этой статьи.

Starche 18 авг 2014 в 17:04

какой смысл писать одно свойство в классе двумя строчками?

Смысл в том, что LESS сам склеит их в одну строку и Webstorm как ошибку вам их не подсветит.

А ещё более глобальный смысл покажу на примере.

Пусть у вас три транзишна на элементе: top, opacity и color. При этом top и opacity всегда есть. А вот если у элемента :hover, то color у него нету, то бишь проявляться должен цвет мгновенно, а пропадать плавно (http://jsbin.com/qocol/1/)
Вам приходится писать оба неменяющихся транзишна дважды. А если в дело вступают другие состояния (через классы, которые навешиваются в JS), то и ещё больше чем дважды. И если надо поправить тайминг, то делать это приходится везде.
С помощью возможности объединения свойств, используя миксин

.transition (@property: all,@duration: 0s,@delay: 0s,@ease: ease-in-out){
    transition+: @arguments;
}

Вы сможете написать что-то вроде

.button_transitions(){
    .transition(height,1s);
    .transition(opacity,1s);
}

.button{
    .button_transitions;
    .transition(color,1s);
    &:hover{
        .button_transitions;
    }
}

И получите то, что нужно

.button {
  transition: height 1s 0s ease-in-out, opacity 1s 0s ease-in-out, color 1s 0s ease-in-out;
}
.button:hover {
  transition: height 1s 0s ease-in-out, opacity 1s 0s ease-in-out;
}

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

extonec 18 авг 2014 в 18:34

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

.button_transitions {
    transition: height 1s 0s ease-in-out, opacity 1s 0s ease-in-out;
}
.button {
  @extend .button_transitions;
  transition: color 1s 0s ease-in-out;
  &:hover {
    @extend .button_transitions;
  }
}

И получите, меньше кода (на 23 символа):

.button_transitions, .button, .button:hover {
  transition: height 1s 0s ease-in-out, opacity 1s 0s ease-in-out;
}
.button {
  transition: color 1s 0s ease-in-out;
}

Пишется и выглядит, на мой взгляд, лаконичнее.
WebStorm, в данном случае подсветит в scss ошибку, если в рамках класса дублируется свойство transition (не в моём примере, а если бы писал в две строки).

Starche 18 авг 2014 в 18:37

Ваш транзишн отработает неправильно. Потому что в итоговом CSS для класса .button второе объявление убъёт первое, а не дополнит его

extonec 18 авг 2014 в 18:39

Я проверил, работу в браузере, произойдёт слияние свойств. :)

Starche 18 авг 2014 в 18:43

Пока не покажете, не поверю. Только что проверил в последнем стабильном Хроме, свойство перезаписывается: сравните
jsbin.com/qocol/1 — при mouseout плавное движение обратно
jsbin.com/qocol/2 — рывок

extonec 18 авг 2014 в 19:26

Согласен, поспешил с первым вариантом примера.

Скрытый текст

$button_transitions: height 1s ease-in-out, opacity 1s ease-in-out;
button {
  transition: $button_transitions, color 1s ease-in-out;
  &:hover {
    transition: $button_transitions;
  }
}

Получится:

button {
  transition: height 1s ease-in-out, opacity 1s ease-in-out, color 1s ease-in-out;
}
button:hover {
  transition: height 1s ease-in-out, opacity 1s ease-in-out;
}

extensible 23 авг 2014 в 10:51

Ваш пример с сокращением media-queries криво работает в WebStorm-е (ломается форматирование и корректная подсветка иногда).
Я использую другой способ:

// определяем все медиа-типы в переменные
@desktopView: ~'(min-width: @{minWidth})';
@mobileView: ~'(max-width: @{maxWidth})';

// и используем дальше, как и раньше с @media 
@media @desktopView {
 .someRules { ... }
}

Starche 23 авг 2014 в 11:21

Релизы Jetbrains не поспевают за развитием LESS. Вполне может быть, что в EAP-билдах уже работает верно. Надо будет проверить и, если нет, то зарепортить им в багтреккер.

SerafimArts 18 авг 2014 в 11:43

Спасибо большое за статью.

Последняя дата, когда я притрагивался к Less (более того — именно с него я начинал) — была примерно в районе 2011-2012 годов, после этого сложилось вполне стереотипное мнение о неполноценности языка. Сейчас же я вижу, что все мои вопросы и проблемы тех лет уже решились, благодаря развитию языка.

ariser 18 авг 2014 в 13:47

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

Чем действительно статья помогла — так это тем, что я ещё раз сходил в репозиторий Автопрефиксера и обнуражил, что уже 2 месяца мог бы им пользоваться (2 месяца назад был релиз Web Essentials со встроенным автопрефиксером — чем я ченжлоги вообще читал?). Лучше поздно, чем никогда, конечно, но обидно. =)

Starche 18 авг 2014 в 23:03

Удивительное рядом. Буквально только что из статьи habrahabr.ru/post/181746/ узнал, что LESS умеет выполнять javascript. Это я к чему: функции и обычные условия нужны не так часто и, обычно, если нужны, то нужны вместе (для обычных случаев вполне хватает гардов вместо условий). Тут как раз и придёт на помощь злой, но полезный eval. Так что могу предложить вам задуматься ещё раз =)

ariser 19 авг 2014 в 01:41

Ох ты ж. Какие костыли. Возможностей это, конечно, добавляет кучу, но как-то не по нутру такое вот смешивание языков. Но спасибо, когда-нибудь и это пригодится.)
Я, вообще, знакомство с препроцессорами как раз с LESS и начинал. Гарды и «циклы» немного прочувствовал. В каких-то ситуациях было неудобно — может, в силу нехватки опыта. Потом ушёл к Sass.
В ближайший раз, когда придётся выбирать, может и задумаюсь.

derSmoll 18 авг 2014 в 13:50

Спасибо за статью. Теперь будет урл, которым можно бросаться в less-скептиков )
Кстати, кто какой grunt-плагин использует в добавку к less для генерации спрайтов?

vorphalack 18 авг 2014 в 15:54

интересно, сколько еще людей после прочтения названия решило что речь про юниксовый less(1)

Dmitry_f 18 авг 2014 в 16:50

Насчет примечания 2 о том, что нет ни одной причины не использовать последний less — вы заблуждаетесь. LESS 1.7 компилирует примерно в два раза медленнее версии 1.3, при этом не добавляя серьезных удобств и возможностей. На текущем проекте имеется около 15000 строчек less, что приводило к 30-40 секундной компиляции на каждое изменение в стилях, и это на достаточно быстрой машине (последний iMac). Рефакторинг не особенно помогал в этой ситуации, но даунгрейд LESS до версии 1.3 позволил сократить это время до 15-20 секунд, причем как показала практика, обойтись без новых возможностей LESS можно вообще без проблем.
Лучше бы ребята инкрементальную компиляцию имплементировали и занялись серьезно вопросом оптимизации, нежели напичкиванием функционала.

XAKEPEHOK 18 авг 2014 в 17:58

А в каких ситуациях less-файл может быть столь огромным? Я конечно понимаю что в продакшене можно все склеивать и минифицировать, но вот при разработке? Мне кажется что стоит разделять такие большие файлы стилей на логические части. Так и разрабатывать удобнее и компилить быстрее (только измененный файл). А в продакшене уже сливать всё в один минифицированный файл. Правда все равно не уверен что это будет хорошая идея, т.к. по моим прикидкам 15000 строк кода less будут занимать ~300 кб, что в css будет еще больше. И пока такой «жирный» файл стилей не подгрузится, вся страница будет выглядеть ужасно, что может быть критично для медленного канала

Dmitry_f 18 авг 2014 в 21:08

Для начала возьмем less-hat (1000 строк). Потом декларацию переменных и декораторов (1500 строк). Потом декларацию шрифтов, иконок. Рисователь png в base64 (еще 1000 строк). Базовая разметка, сетка. Возможно еще что всплывет, уже не помню. Это все — минимальный остаток, после ревизий, рефакторингов и сжатий, самое необходимое (ведь можно было бы использовать фреймворк). Это все — накладные расходы, т. е. зависимости, которые придется подключать всегда, к каждому отдельно компилируемому входному куску less. Уже такая конструкция сама по себе компилится секунд 10-12 на less 1.7. На 1.3 — сносно, в районе 5-7 секунд.
Насчет размера выходного файла в less — он может быть даже нулевым, но компиляция будет долгой, — дело не только в рендеринге, но и парсинге. lesshat, к примеру, вообще не генерит css, как и всяческие декораторы.
Хотя выходной css на проекте действительно довольно большой — 50Кб после сжатия.

grobitto 18 авг 2014 в 21:37

Да, тоже был нериятно удивлен производительностью 1.7

Зарегистрируйтесь на Хабре, чтобы оставить комментарий