Comments 22
А фишки и правда новые, переходя по ссылке я ожидал прочитать про то, что уже и сам знаю, ан нет.
Ну и про Autoprefixer — если вы его еще не используете — делаете себе же хуже. По началу я было сомневался, так как и не надеялся сохранить корректный source map, но Autoprefixer так крут, что после тривиального колдовства с конфигом в веб-инспекторе будут отображаться корректные пути к исходным файлам.
Ну и про Autoprefixer — если вы его еще не используете — делаете себе же хуже. По началу я было сомневался, так как и не надеялся сохранить корректный source map, но Autoprefixer так крут, что после тривиального колдовства с конфигом в веб-инспекторе будут отображаться корректные пути к исходным файлам.
Примеры использования которые вы показали, полезны, когда под рукой нет ничего кроме заготовочек less.
В работе же, задачи слияния классов и свойств, генерацию безошибочных спрайтов, префиксов, выполняют Grunt/Gulp.
Комфортнее писать CSS3 без лишних символов, зависящих от препроцессора.
В работе же, задачи слияния классов и свойств, генерацию безошибочных спрайтов, префиксов, выполняют Grunt/Gulp.
Комфортнее писать CSS3 без лишних символов, зависящих от препроцессора.
Не очень понял, как Grunt (или Gulp) помогут в той части, которая касается слияний. Из моего опыта: довольно часто происходит так, что на элемент наложено 3-4 транзишна и он имеет несколько состояний. При этом отличия в тразишнах для разных состояний только в одном из этих четырех, а переписывать приходится полностью. Тут отлично поможет миксин на неизменяемую часть и объединение через запятую.
Если Grunt как-то здесь может помочь, то не могли бы вы направить в какую сторону смотреть?
В остальном несомненно, вы правы. Однако не только этими примерами ограничивается применение указанных возможностей: циклы (через рекурсию) можно применить при генерации сетки (так делает bootstrap), передача кода как параметр поможет заменить длинные media query (пожалуй, добавлю это в статью), условия вообще полезная штука.
Ну а использовать или не использовать препроцессоры — это настолько холиварная тема, что даже касаться не хочется
Если Grunt как-то здесь может помочь, то не могли бы вы направить в какую сторону смотреть?
В остальном несомненно, вы правы. Однако не только этими примерами ограничивается применение указанных возможностей: циклы (через рекурсию) можно применить при генерации сетки (так делает bootstrap), передача кода как параметр поможет заменить длинные media query (пожалуй, добавлю это в статью), условия вообще полезная штука.
Ну а использовать или не использовать препроцессоры — это настолько холиварная тема, что даже касаться не хочется
По поводу слияний, я подразумевал минификаторы (мне нравится: clean-css, для Grunt это contrib-cssmin). Специально посмотрел, clean-css не делает слияния такого типа (разные транситионы), но, какой смысл писать одно свойство в классе двумя строчками? WebStorm сразу подсветит ошибку, пишу через запятую. Возможно другие минификаторы так могут, мне хватает одного. Не забываем про @extend + работа clean-css по объединению, хороша.
Сам пользую scss естественно, первый комментарий в контексте «плюсов» этой статьи.
Сам пользую scss естественно, первый комментарий в контексте «плюсов» этой статьи.
какой смысл писать одно свойство в классе двумя строчками?
Смысл в том, что LESS сам склеит их в одну строку и Webstorm как ошибку вам их не подсветит.
А ещё более глобальный смысл покажу на примере.
Пусть у вас три транзишна на элементе: top, opacity и color. При этом top и opacity всегда есть. А вот если у элемента :hover, то color у него нету, то бишь проявляться должен цвет мгновенно, а пропадать плавно (http://jsbin.com/qocol/1/)
Вам приходится писать оба неменяющихся транзишна дважды. А если в дело вступают другие состояния (через классы, которые навешиваются в JS), то и ещё больше чем дважды. И если надо поправить тайминг, то делать это приходится везде.
С помощью возможности объединения свойств, используя миксин
Вы сможете написать что-то вроде
И получите то, что нужно
плюс возможность менять общую часть транзишнов в одном месте.
Вам приходится писать оба неменяющихся транзишна дважды. А если в дело вступают другие состояния (через классы, которые навешиваются в 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;
}
плюс возможность менять общую часть транзишнов в одном месте.
Догадываюсь, что вы хотите описать, но, вот без микшина и нестандартных записей (хотя можно и микшин написать в scss, получается не плюс less, а рядовая возможность препроцессоров):
И получите, меньше кода (на 23 символа):
Пишется и выглядит, на мой взгляд, лаконичнее.
WebStorm, в данном случае подсветит в scss ошибку, если в рамках класса дублируется свойство transition (не в моём примере, а если бы писал в две строки).
.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 (не в моём примере, а если бы писал в две строки).
Ваш транзишн отработает неправильно. Потому что в итоговом CSS для класса .button второе объявление убъёт первое, а не дополнит его
Я проверил, работу в браузере, произойдёт слияние свойств. :)
Пока не покажете, не поверю. Только что проверил в последнем стабильном Хроме, свойство перезаписывается: сравните
jsbin.com/qocol/1 — при mouseout плавное движение обратно
jsbin.com/qocol/2 — рывок
jsbin.com/qocol/1 — при mouseout плавное движение обратно
jsbin.com/qocol/2 — рывок
Согласен, поспешил с первым вариантом примера.
Скрытый текст
Получится:
$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;
}
Ваш пример с сокращением media-queries криво работает в WebStorm-е (ломается форматирование и корректная подсветка иногда).
Я использую другой способ:
Я использую другой способ:
// определяем все медиа-типы в переменные
@desktopView: ~'(min-width: @{minWidth})';
@mobileView: ~'(max-width: @{maxWidth})';
// и используем дальше, как и раньше с @media
@media @desktopView {
.someRules { ... }
}
Спасибо большое за статью.
Последняя дата, когда я притрагивался к Less (более того — именно с него я начинал) — была примерно в районе 2011-2012 годов, после этого сложилось вполне стереотипное мнение о неполноценности языка. Сейчас же я вижу, что все мои вопросы и проблемы тех лет уже решились, благодаря развитию языка.
Последняя дата, когда я притрагивался к Less (более того — именно с него я начинал) — была примерно в районе 2011-2012 годов, после этого сложилось вполне стереотипное мнение о неполноценности языка. Сейчас же я вижу, что все мои вопросы и проблемы тех лет уже решились, благодаря развитию языка.
Появилось больше уважения к LESS, но Sass по-прежнему в миох глазах стоит выше. Возможность функций и настоящих условий хотя бы мне очень милы. Хотя вот слияние свойств — довольно вкусная штука, которой в Sass как раз-таки нет.
Чем действительно статья помогла — так это тем, что я ещё раз сходил в репозиторий Автопрефиксера и обнуражил, что уже 2 месяца мог бы им пользоваться (2 месяца назад был релиз Web Essentials со встроенным автопрефиксером — чем я ченжлоги вообще читал?). Лучше поздно, чем никогда, конечно, но обидно. =)
Чем действительно статья помогла — так это тем, что я ещё раз сходил в репозиторий Автопрефиксера и обнуражил, что уже 2 месяца мог бы им пользоваться (2 месяца назад был релиз Web Essentials со встроенным автопрефиксером — чем я ченжлоги вообще читал?). Лучше поздно, чем никогда, конечно, но обидно. =)
Удивительное рядом. Буквально только что из статьи habrahabr.ru/post/181746/ узнал, что LESS умеет выполнять javascript. Это я к чему: функции и обычные условия нужны не так часто и, обычно, если нужны, то нужны вместе (для обычных случаев вполне хватает гардов вместо условий). Тут как раз и придёт на помощь злой, но полезный eval. Так что могу предложить вам задуматься ещё раз =)
Ох ты ж. Какие костыли. Возможностей это, конечно, добавляет кучу, но как-то не по нутру такое вот смешивание языков. Но спасибо, когда-нибудь и это пригодится.)
Я, вообще, знакомство с препроцессорами как раз с LESS и начинал. Гарды и «циклы» немного прочувствовал. В каких-то ситуациях было неудобно — может, в силу нехватки опыта. Потом ушёл к Sass.
В ближайший раз, когда придётся выбирать, может и задумаюсь.
Я, вообще, знакомство с препроцессорами как раз с LESS и начинал. Гарды и «циклы» немного прочувствовал. В каких-то ситуациях было неудобно — может, в силу нехватки опыта. Потом ушёл к Sass.
В ближайший раз, когда придётся выбирать, может и задумаюсь.
Спасибо за статью. Теперь будет урл, которым можно бросаться в less-скептиков )
Кстати, кто какой grunt-плагин использует в добавку к less для генерации спрайтов?
Кстати, кто какой grunt-плагин использует в добавку к less для генерации спрайтов?
интересно, сколько еще людей после прочтения названия решило что речь про юниксовый less(1)
Насчет примечания 2 о том, что нет ни одной причины не использовать последний less — вы заблуждаетесь. LESS 1.7 компилирует примерно в два раза медленнее версии 1.3, при этом не добавляя серьезных удобств и возможностей. На текущем проекте имеется около 15000 строчек less, что приводило к 30-40 секундной компиляции на каждое изменение в стилях, и это на достаточно быстрой машине (последний iMac). Рефакторинг не особенно помогал в этой ситуации, но даунгрейд LESS до версии 1.3 позволил сократить это время до 15-20 секунд, причем как показала практика, обойтись без новых возможностей LESS можно вообще без проблем.
Лучше бы ребята инкрементальную компиляцию имплементировали и занялись серьезно вопросом оптимизации, нежели напичкиванием функционала.
Лучше бы ребята инкрементальную компиляцию имплементировали и занялись серьезно вопросом оптимизации, нежели напичкиванием функционала.
А в каких ситуациях less-файл может быть столь огромным? Я конечно понимаю что в продакшене можно все склеивать и минифицировать, но вот при разработке? Мне кажется что стоит разделять такие большие файлы стилей на логические части. Так и разрабатывать удобнее и компилить быстрее (только измененный файл). А в продакшене уже сливать всё в один минифицированный файл. Правда все равно не уверен что это будет хорошая идея, т.к. по моим прикидкам 15000 строк кода less будут занимать ~300 кб, что в css будет еще больше. И пока такой «жирный» файл стилей не подгрузится, вся страница будет выглядеть ужасно, что может быть критично для медленного канала
Для начала возьмем less-hat (1000 строк). Потом декларацию переменных и декораторов (1500 строк). Потом декларацию шрифтов, иконок. Рисователь png в base64 (еще 1000 строк). Базовая разметка, сетка. Возможно еще что всплывет, уже не помню. Это все — минимальный остаток, после ревизий, рефакторингов и сжатий, самое необходимое (ведь можно было бы использовать фреймворк). Это все — накладные расходы, т. е. зависимости, которые придется подключать всегда, к каждому отдельно компилируемому входному куску less. Уже такая конструкция сама по себе компилится секунд 10-12 на less 1.7. На 1.3 — сносно, в районе 5-7 секунд.
Насчет размера выходного файла в less — он может быть даже нулевым, но компиляция будет долгой, — дело не только в рендеринге, но и парсинге. lesshat, к примеру, вообще не генерит css, как и всяческие декораторы.
Хотя выходной css на проекте действительно довольно большой — 50Кб после сжатия.
Насчет размера выходного файла в less — он может быть даже нулевым, но компиляция будет долгой, — дело не только в рендеринге, но и парсинге. lesshat, к примеру, вообще не генерит css, как и всяческие декораторы.
Хотя выходной css на проекте действительно довольно большой — 50Кб после сжатия.
Да, тоже был нериятно удивлен производительностью 1.7
Sign up to leave a comment.
Малоиспользуемые, но от этого не менее прекрасные возможности LESS