Comments 73
Мне казалось, что все, кому не лень используют Sass\Scss или Stylus, а Less используют те, кто не видел и не слышал, ни о первом, ни о втором. Без обид (и холиваров), просто Less очень слабый, по сравнению с ними.
З.Ы.
Когда набирается по 2-3 тысячи строк стилей — этого вопроса уже возникать не будет ;)
З.Ы.
зачем сокращать код, когда он все-равно компилируясь раскрывается и развертывается до разобранного CSS-состояния?
Когда набирается по 2-3 тысячи строк стилей — этого вопроса уже возникать не будет ;)
Слышал и о том и о другом. При этом не являюсь ни верстальщиком, ни дизайнером. В своих проектах пользуюсь LESS. Функционала хватает, очень просто цепляется в режиме компиляции на стороне браузера, не нужно ставить Ruby и node( для разработки, для окончательно компиляции node все же нужен).
Из фич пожалуй только =respond-to не хватает сильно. В общем все это субъективно. Если пользоваться реально всеми фичами SCSS — наверное он однозначно лучше, а для облагораживания CSS для хобби — LESS со своим низким порогом вхождения и неплохой документацией является хорошим выбором.
Из фич пожалуй только =respond-to не хватает сильно. В общем все это субъективно. Если пользоваться реально всеми фичами SCSS — наверное он однозначно лучше, а для облагораживания CSS для хобби — LESS со своим низким порогом вхождения и неплохой документацией является хорошим выбором.
Приведу совершенно реальные примеры:
1) Обычный миксин, который реализует кроссбраузерный transition (учитываем внутри вендоры, т.е. для -moz-transition подставляем -moz-transform в случае передачи transform внутрь, и т.д.)
* На лессе реализовать невозможно — нет условий
2) Обычный спрайтщит, допустим 320х320 с иконками 16х16
* Лесс не будет отличаться от css — нет циклов
3) Миксин css выделений текста или стилизации плейсхолдеров, или кейфреймов css-анимаций:
* На лессе реализовать без извращений невозможно
и прочее. Прошу заметить, что я пишу не извращения с кодом, не выдуманные примеры, которые никогда не найдут применения в жизни, а вполне реальные задачи с которыми реально можно столкнуться в жизни, я не просто так настолько категоричен, сам сидел на less первое время.
1) Обычный миксин, который реализует кроссбраузерный transition (учитываем внутри вендоры, т.е. для -moz-transition подставляем -moz-transform в случае передачи transform внутрь, и т.д.)
* На лессе реализовать невозможно — нет условий
2) Обычный спрайтщит, допустим 320х320 с иконками 16х16
* Лесс не будет отличаться от css — нет циклов
3) Миксин css выделений текста или стилизации плейсхолдеров, или кейфреймов css-анимаций:
Скрытый текст
@mixin placeholder {
&::-webkit-input-placeholder {
@content;
}
&:-moz-placeholder {
@content;
}
&::-moz-placeholder {
@content;
}
&:-ms-input-placeholder {
@content;
}
}
@mixin selection {
&::selection {
@content;
}
&::-moz-selection {
@content;
}
}
@mixin keyframe($name) {
@-webkit-keyframes #{$name} {
@content;
}
@-moz-keyframes #{$name} {
@content;
}
@-o-keyframes #{$name} {
@content;
}
@keyframes #{$name} {
@content;
}
}
* На лессе реализовать без извращений невозможно
и прочее. Прошу заметить, что я пишу не извращения с кодом, не выдуманные примеры, которые никогда не найдут применения в жизни, а вполне реальные задачи с которыми реально можно столкнуться в жизни, я не просто так настолько категоричен, сам сидел на less первое время.
1) странно, а почему у меня тогда работает?
Я не в восторге от less, но использую его и вижу в его использовании смысл, когда мне не приходится разбираться с вендорными префиксами, дописывать полный путь к элементу и прочей байдой, которая убивает время.
Единственный и самый жирный минус — это то, что из консоли разработчика теперь нельзя найти точную строку в less файле ибо браузер используют css файл.
Для меня less не язык никакой, а просто синтаксический сахар. Если к нему относится именно так, то он свою задачу вполне выполняет.
PS: для PHP Storm/Web Storm есть плагин для компиляции less в css. Плагин также умеет сохранять структуру каталогов после компиляции. Все происходит автоматом и не нужно лишних телодвижений делать.
.transition (@transitions, @transform) {
-webkit-transition: @transitions, -webkit-@transform;
-moz-transition: @transitions, -moz-@transform;
-o-transition: @transitions, -o-@transform;
transition: @transitions, @transform;
}
.transition-transform (@transform) {
-webkit-transition: -webkit-transform @transform;
-moz-transition: -moz-transform @transform;
-o-transition: -o-transform @transform;
transition: transform @transform;
}
Я не в восторге от less, но использую его и вижу в его использовании смысл, когда мне не приходится разбираться с вендорными префиксами, дописывать полный путь к элементу и прочей байдой, которая убивает время.
Единственный и самый жирный минус — это то, что из консоли разработчика теперь нельзя найти точную строку в less файле ибо браузер используют css файл.
Для меня less не язык никакой, а просто синтаксический сахар. Если к нему относится именно так, то он свою задачу вполне выполняет.
PS: для PHP Storm/Web Storm есть плагин для компиляции less в css. Плагин также умеет сохранять структуру каталогов после компиляции. Все происходит автоматом и не нужно лишних телодвижений делать.
Зачем изобретать такие mixin's?
Есть же autoprefixer
Есть же autoprefixer
При компиляции less можно задать параметр, который параллельно будет генерировать .map файл. Встроенные инструменты разработчика FF свежей версии умеют его понимать и покажут вам строку именно в .less файле. Хром тоже умеет показывать исходники.
.transition (@transitions, @transform) { -webkit-transition: @transitions, -webkit-@transform; -moz-transition: @transitions, -moz-@transform; -o-transition: @transitions, -o-@transform; transition: @transitions, @transform; }
А что будет в случае:
transition(
box-shadow .3s ease,
background .3s ease .2s,
color .2s linear
);
?
Все будет печально т.к. less вообще не умеет работать с неопределенным количеством аргументов (может в последних версиях это и улучшили, но я давно не обновлялся)
Чтобы оно работало нужно использовать другой миксин
и передавать парамтр вот так:
Это еще 1 неприятная, но для меня не критичная проблема less
Чтобы оно работало нужно использовать другой миксин
.transition (@transitions) {
-webkit-transition: @transitions;
-moz-transition: @transitions;
-o-transition: @transitions;
transition: @transitions;
}
и передавать парамтр вот так:
@transitions: height 0.3s linear, width 0.3s linear;
.transition(@transitions);
Это еще 1 неприятная, но для меня не критичная проблема less
В таком случае где я ошибся, написав то, что Less слабый и реализация некоторых фич требует, либо костылей, либо сторонних библиотек на js? В тоже время озвученные выше языки (sass\stylus) позволяют делать всё это из коробки.
На правах развлекухи:
На правах развлекухи:
Скрытый текст
Помнится я даже смог написать свою функцию синуса, просто ради развлечения, для того, что бы миксин transform rotate для ИЕ нормально понимал градусы (в ИЕ есть хак через фильтры, но он в воспринимает угол поворота в радианах, если не путаю):
Этот код не рабочий, т.к. надо ещё написать функцию факториала числа. Но в целом показывает мощь языка. Конечно — это извращение (так как функция синуса уже есть), но тоже вполне может случиться, что понадобится аналогичное и придётся страдать.
@function pi(){
@return 3.14;
}
// возведение в степень
@function pow($val, $num){
$result: $num;
@for $i from 1 through $num{
$result: $result * $num;
}
@return $result;
}
@function sin($deg){
$c: 9; // точность тейлора (кратно 2+1)
$result: $deg;
@for $i from 3 through $c{
$result: $result + pow($deg, $i) / факториал($i);
$i: $i+1;
}
@return $result;
}
Этот код не рабочий, т.к. надо ещё написать функцию факториала числа. Но в целом показывает мощь языка. Конечно — это извращение (так как функция синуса уже есть), но тоже вполне может случиться, что понадобится аналогичное и придётся страдать.
Такого рода мощь спорно — хорошо это или плохо. Это как Тьюринг-полные языки в конфигах.
Могда уж тогда шаблонизатором серверным генерировать LESS. Кстати местами так и делал.
Есть HTML разметка, есть CSS стили, есть js логика. Зачем смешивать?
Могда уж тогда шаблонизатором серверным генерировать LESS. Кстати местами так и делал.
Есть HTML разметка, есть CSS стили, есть js логика. Зачем смешивать?
Когда не хватает возможностей — это плохо и приходится городить огород, а когда возможностей с избытком, без ущерба синтаксису\простоте языка\etc., то никто в таком случае не заставляет пользоваться всеми возможностями, просто в перспективе костылей не будет.
Причём под избыточными возможностями — я имел ввиду всего лишь наличие циклов, условий и функций, что не является просто «мастхевом» с точки зрения любого языка.
Причём под избыточными возможностями — я имел ввиду всего лишь наличие циклов, условий и функций, что не является просто «мастхевом» с точки зрения любого языка.
Нет, когда сложность языка становится исбыточной это тоже похо. Есть в 99% случаев без этой фичи можно обойтись, то она будет использоваться чаще всего не к месту или неправильно, потому что к ней не привыкли. Часть разработчиков будет на такой исходник смотреть как бараны на новые ворота. Всё хорошо вмеру. По крайней мере это мое личное мнение. Видимо поэтому параллельно и живут LESS и SCSS. Кому что нравится.
1) Есть например lesshat. И можно писать например `.transition(transform scale 200ms linear);`, и все префиксы будут правильно проставлены. Так что это возможно. Хотя хорошей практикой является использовать autoprefixer, который с префиксами работает куда лучше less и sass.
2) Для спрайтовых анимаций лучше использовать js библиотеки, которые во-первых сами сгенерируют нужные css-стили, а во-вторых можно создавать более комплексные анимации. А в целом вы правы — циклов нет. Но нужны ли они?
3) Вытекает из первого пункта.
Заметил, что примеры не выдуманные, а реальные — но решаются они на другом уровне.
2) Для спрайтовых анимаций лучше использовать js библиотеки, которые во-первых сами сгенерируют нужные css-стили, а во-вторых можно создавать более комплексные анимации. А в целом вы правы — циклов нет. Но нужны ли они?
3) Вытекает из первого пункта.
Заметил, что примеры не выдуманные, а реальные — но решаются они на другом уровне.
1) это хорошо, язык растёт. В то время, когда я использовал лесс — о таком даже не слышал и очень сильно ругался =)
2) Я не говорил про анимации, я говорил про маленькие иконочки:
Циклы желательны и очень облегчают жизнь, к примеру генерация
3) Посмотрел на лессхат — не увидел возможности вставки контента миксина, увидел только костыли, которые реализуют узкоспециализированные задачи, в частности вот это для кейфреймов: github.com/madebysource/lesshat/blob/master/mixins/keyframes/keyframes.js
2) Я не говорил про анимации, я говорил про маленькие иконочки:
@include sprite(2, 3); что бы подключить иконочку с позицией -32px на -48px, которая, допустим является обычным крестиком для кнопочек «закрыть». Циклы желательны и очень облегчают жизнь, к примеру генерация
@media screen миксинов с шагом 160, что бы писать так:@include size-320 {
width: 480px; // ширина 480 для экрана, размером меньше или равного 320
}
@include size-480 {
width: 800px; // ширина 800 для 480 и меньше
}
@include size-960 {
width: 100%;
}
3) Посмотрел на лессхат — не увидел возможности вставки контента миксина, увидел только костыли, которые реализуют узкоспециализированные задачи, в частности вот это для кейфреймов: github.com/madebysource/lesshat/blob/master/mixins/keyframes/keyframes.js
2) А обычные спрайты также решаются отдельными утилитами, которые а) собирают спрайт с исходников б) создают css-стили для каждой иконки. В результате, инклудим файл стилей в less и далее, как миксин, подключаем иконку к нужному стилю. И не нужно никаких цыклов, не нужно помнить индексы — лишь одно нужно помнить — имя иконки, которое будет соответсвовать имени стиля, со сгенерированной информацией о пути к спрайту и о позиции. Также добавлю ещё, что мы редко используем пути к картинкам в стилях, в основнпм генерируются нужные стили уже с путями и с размерами.
3) Я имел ввиду не lesshat использовать для keyframes, а autoprefixer — и о префиксах можно забыть. А для совсем сложных анимаций нужно использовать js библиотеку, которя использует те же анимации и css transitions.
Разумеется, я ни коим образом не умалаю мощь sass-a. Просто с less-ом и другими штуками можно получить на порядок больше профита.
3) Я имел ввиду не lesshat использовать для keyframes, а autoprefixer — и о префиксах можно забыть. А для совсем сложных анимаций нужно использовать js библиотеку, которя использует те же анимации и css transitions.
Разумеется, я ни коим образом не умалаю мощь sass-a. Просто с less-ом и другими штуками можно получить на порядок больше профита.
2) Ну это просто другой подход, тоже имеет место быть.
3) Я имел ввиду наличие переменной контент, а не кейфреймы в отдельности ;)
Это обычный миксин, что в лессе, что в сассе — он одинаков по функциональности:
А вот это контент:
Т.е. что-то вроде блоков и yield в руби. Из чего и проистекают миксины указанные в моём примере выше — habrahabr.ru/post/233467/#comment_7871629 (в спойлере)
3) Я имел ввиду наличие переменной контент, а не кейфреймы в отдельности ;)
Это обычный миксин, что в лессе, что в сассе — он одинаков по функциональности:
@mixin some($variable) {
color: #900;
any-style: $variable;
}
.some {
@include some(some-value);
}
А вот это контент:
@mixin some {
@content;
}
.some {
@include some {
// это передаётся в переменную @content
}
}
Т.е. что-то вроде блоков и yield в руби. Из чего и проистекают миксины указанные в моём примере выше — habrahabr.ru/post/233467/#comment_7871629 (в спойлере)
UFO just landed and posted this here
для разработки, для окончательно компиляции node все же нужен
Есть программы, например WinLESS которые при сохранении LESS файла автоматически кладут рядом (или не рядом) скомпилированный CSS. Ну или при использовании SublimeText можно поставить плагин для автоматического компилирования CSS при сохранении LESS файла
Плагин SublimeText требует в PATH lessc, который и есть js, запускаемый через node.js.
WinLESS не пользовался, из-за того что не пользуюсь Windows, но судя по исходникам на github, там внутри всё та же node.
На сколька я знаю, были попытки сделать компилятор на Python, но они благополучно загнулись за практической ненадобностью — все модули дергают lessc, как официальный и развивиемый компилятор.
WinLESS не пользовался, из-за того что не пользуюсь Windows, но судя по исходникам на github, там внутри всё та же node.
На сколька я знаю, были попытки сделать компилятор на Python, но они благополучно загнулись за практической ненадобностью — все модули дергают lessc, как официальный и развивиемый компилятор.
Все современные препроцессоры примерно одинаковые (http://code.tutsplus.com/tutorials/sass-vs-less-vs-stylus-preprocessor-shootout--net-24320)
Сегодня я поделюсь с вами своим опытом практического использования LESS.
…
Все, изложенное выше — просто мое мнение
Примеров практического использования не увидел, кода в тексте — две строчки, а свое мнение принято в свой бложик писать.
Бедный Федя. :(
Вы посмотрите, например, исходный код bootstrap в less, как там генерируются колонки, вычисляются размеры кнопок на основе минимума параметров. Когда можно наследовать стиль одного элемента к другому одной строчкой. Вам бы изучить все юзеркейсы использования less, а потом делать выводы. Хотя с другой стороны если вы не верстаете профессионально, а только тыкаете пипеткой в цвет то да — наверное вам это и не нужно.
Less можно не любить, можно любить. Но придумывать почему он вам не понравился — глупость.
1) Вы заходите в файл с константами, где как раз и укладывается этот base_color и меняете там, а не шаритесь по всему проекту.
2) Replace all, а если вы измените еще какой-то цвет #ccc который не относится к базовому цвету?
3) Што?
А теперь о вашем скепсисе о плюсах.
Если вам это экономит время по 20 секунд на каждое написание такого участка — это уже выгодно. Но теперь вам не нравится конечный исход? А чего вы ожидали, CSS-Less который браузер понимает или что? Очередной стандарт по CSS, который не будет понимать хорошая куча браузеров?
Интересно, на C/C++ вы так-же говорите? Зачем сомнительный C/С++, если есть очень быстрый Assambler?
1) Вы заходите в файл с константами, где как раз и укладывается этот base_color и меняете там, а не шаритесь по всему проекту.
2) Replace all, а если вы измените еще какой-то цвет #ccc который не относится к базовому цвету?
3) Што?
А теперь о вашем скепсисе о плюсах.
Если вам это экономит время по 20 секунд на каждое написание такого участка — это уже выгодно. Но теперь вам не нравится конечный исход? А чего вы ожидали, CSS-Less который браузер понимает или что? Очередной стандарт по CSS, который не будет понимать хорошая куча браузеров?
Интересно, на C/C++ вы так-же говорите? Зачем сомнительный C/С++, если есть очень быстрый Assambler?
Ну не знаю, я как на LESS перешел, так с тех пор и не думаю уходить с него, хотя и использую, наверно, только малую толику его возможностей.
Зачем сокращать код, когда он все-равно компилируясь раскрывается и развертывается до разобранного CSS-состояния?
Ну как же? Рабочий файл остается .less, который чистенький и приятненький. А то, что скомпилировалось (и возможно было сжато), кого должно волновать?
> Во-вторых, аргумент сторонников о том, что удобно: «Изменил в одном месте — поправил все кнопки!» — это для людей, которые не знают или забыли, что такое пакетный реплэйс!
Угу, и функций, констант и т.п. в вашем коде тоже нет. Зачем… Только «пакетный реплэйс» только хардкор)
>… это для людей, которые…
А еще есть люди который не понимают что такое программирование… Уж извините.
Сам я не пользую Less :) мне больше Sass нравится.
Угу, и функций, констант и т.п. в вашем коде тоже нет. Зачем… Только «пакетный реплэйс» только хардкор)
>… это для людей, которые…
А еще есть люди который не понимают что такое программирование… Уж извините.
Сам я не пользую Less :) мне больше Sass нравится.
И таких переменных может быть десяток, и они могут быть все в разных, отдельно подключаемых файлах
LESS поддерживает import как раз для таких случаев
«Изменил в одном месте — поправил все кнопки!» — это для людей, которые не знают или забыли, что такое пакетный реплэйс!
Например на сайте в трех местах используется цвет #ccc, но в двух из них он всегда должен быть одинаковый, так уж продиктовано дизайном, а в третьем так совпало. Вот тогда то и нужна переменная, которая будет использоваться только для первых двух стилей.
А вообще из наиболее важных для меня преимуществ LESS это примеси и возможность писать вложенный код.
Вот моя любимая примесь
.clearfix() {
*zoom: 1;
&:after {
display: block;
content: "";
line-height: 0;
clear: both;
}
}
зачем сокращать код, когда он все-равно компилируясь раскрывается и развертывается до разобранного CSS-состояния?Для удобства сопровождения?
Спросите, почему? Ответ: потому что это не полноценный язык и на выходе мы получаем все те же громоздкие конструкции CSS.
Любой язык программирования плохой. Спросите, почему? Потому что ни один из них не полноценный и на выходе мы всё равно получим бинарный код.
Пишите в бинарном коде, друзья!
LESS использовал в своё время только как переходный период от чистого CSS к SASS
Просто мне не нравится писать скобочки {} и точки с запятыми
Просто мне не нравится писать скобочки {} и точки с запятыми
Вы, наверное, из тех, кто на CoffeeScript не пишет.
О! Верстальщики доросли до религиозных войн программистов 30-40-летней давности. Заменяем в старинных флеймах «ЯВУ по вкусу» на LESS, а ассемблер на CSS и получаем вот это самое. Только ещё оптимизацию забыли — любовно вылизанный вручную CSS даёт 0.0001% прирост отзывчивости веб-странички по сравнению с LESS.
С моей точки зрения — очень спорно:
Во-первых, как уже ранее говорил, банально — чтобы изменить цвет уже существующего элемента нужно найти элемент, который нужно поправить, затем найти ту переменную, к которой уже присвоен сам цвет. И таких переменных может быть десяток, и они могут быть все в разных, отдельно подключаемых файлах, число которых, как вы понимаете, также может исчисляться десятками.
Во-вторых, аргумент сторонников о том, что удобно: «Изменил в одном месте — поправил все кнопки!» — это для людей, которые не знают или забыли, что такое пакетный реплэйс! Проще, быстрее и надежней найти сразу цвет #ccc и сделать «Replace All».
Еще есть мнимое «удобство» less в том, что легко поменять цвет путем сложения или вычитания прямо в коде, но это опять же в кавычках — поскольку если у человека под рукой графический редактор + если он давно занимается версткой и знает наизусть основные коды цветов — ему не нужно ничего прибавлять или убавлять — он сразу прописывает код.
— Уж сколько раз твердили миру: используйте IDE, а не текстовые редакторы! Они умеют многое, например при помощи клика мышки на используемую функцию из миксина — переходить к её дефиниции в сам миксин.
— Кончено, удобней. Лучше сразу поиск и реплейс по всему проекту, особенно если цвет #ccc.
— Что-то из разряда: «Вааась, какого цета у нас небо было? — Зелёного! — Да блин, ты мне нормально, в хексе скажи!». Ни разу не видил человека, что бы взглянув на цвет он выдавал бы его точный хекс код…
З.Ы. а ещё можно копипастить ЦСС общих элементов для каждой страницы отдельно!
Согласен. А потом после такого реплейса выяснится, что кто-то вместо #ccc заюзал цвет #cccccc, кто-то ошибся и написал #cdcdcd, а кто-то через rgb или rgba вообще.
Ни разу не видил человека, что бы взглянув на цвет он выдавал бы его точный хекс код
Ну, не знаю… в моей памяти около 15 цветов +-, вполне ими обхожусь!
border-color: lighten(@base, 30%); — когда уж совсем лень! Но лень, как известно, двигатель прогресса )))))))))))))))))
:D
Вот не буду сегодня шутить, буду смеяться!
© неизвестный
Реакция зала понятна и вполне ожидаема. )) Пользователи языка лягут грудью на амбразуру, а для НЕпользователей все в фиолетовом цвете.
Не буду скрывать, я люблю LESS за те возможности, которые он предлагает!
Прям люблю беззаветной любовью! Верите? )) Поверьте — это так!
+ Понимаю архитекторов проектов, которые, решая каждодневные задачи мирового масштаба (здесь я не шучу), как воздух хватают «вкусные печеньки», хоть как-то облегчающие процесс интеграции и взаимосвязи.
Но говоря откровенно, мотивацией к написанию сего чтива послужило именно то, что я очень неравнодушен к разного рода полезностям, шагам в сторону прогресса, стараюсь четко для себя определить применимость и вообще необходимость существования того или иного человеческого изобретения.
))))))))))))))))))))))))))))))))))))
Поэтому прошу каждого: взвесьте все за и против, 7 раз отмерьте — один раз отрежьте, не идите на поводу собственных предпочтений в крупных проектах, в которых участвует не один десяток разработчиков. А если Вы свободны верстальщик — то изучайте LESS, SASS, SCSS — лишним не будет…
Ибо эргономика — наше все! Не забывайте об этом, друзья!
Ну, и, конечно, НЕ ЗАБЫВАЕМ — молимся богу по имени LESS!
© неизвестный
Реакция зала понятна и вполне ожидаема. )) Пользователи языка лягут грудью на амбразуру, а для НЕпользователей все в фиолетовом цвете.
Не буду скрывать, я люблю LESS за те возможности, которые он предлагает!
Прям люблю беззаветной любовью! Верите? )) Поверьте — это так!
+ Понимаю архитекторов проектов, которые, решая каждодневные задачи мирового масштаба (здесь я не шучу), как воздух хватают «вкусные печеньки», хоть как-то облегчающие процесс интеграции и взаимосвязи.
Но говоря откровенно, мотивацией к написанию сего чтива послужило именно то, что я очень неравнодушен к разного рода полезностям, шагам в сторону прогресса, стараюсь четко для себя определить применимость и вообще необходимость существования того или иного человеческого изобретения.
))))))))))))))))))))))))))))))))))))
Поэтому прошу каждого: взвесьте все за и против, 7 раз отмерьте — один раз отрежьте, не идите на поводу собственных предпочтений в крупных проектах, в которых участвует не один десяток разработчиков. А если Вы свободны верстальщик — то изучайте LESS, SASS, SCSS — лишним не будет…
Ибо эргономика — наше все! Не забывайте об этом, друзья!
Ну, и, конечно, НЕ ЗАБЫВАЕМ — молимся богу по имени LESS!
UFO just landed and posted this here
Ожидал-ожидал! )) Ну, не леденец, ну не сахарный, чтоб всем нравиться! + как раз люблю всех людей (за редким исключением, за их, в первую очередь, непосредственность), даже тех, кто не разобрался в вопросе о том, что кто-то разобрался в вопросе или нет )) И мнение мое вовсе не безапелляционное, скорее наоборот – пытаюсь привести мир к равновесию, пониманию того, что все относительно и категоричным быть не стоит ))))))))))))))))))) расширить, так сказать, заорганизованные ряды и оградить ищущих…
начинал с верстки… а между тем это одна из самых творческих профессий! Вот не писал я про «на помойку», это уже твои слова… говорил только о своей практике: а каждый увидел то что хотел видеть в этом!
Равнодушно отношусь к LESS и обычному CSS. Но насчет трудностей поиска, в Visual Studio можно просто ткнуть на нужной переменной F12 и она сама направит вас на ее объявление. Это же работает и с классами в html-коде.
Согласен полностью! Но просто попробуйте в уже существующем проекте сравнить сколько у вас уйдет времени (в секундах) на изменение конечного отдельного элемента если переменных и подключаемых less-файлов несколько и подход: браузер -> номер строки CSS = всего лишь 2 действия («найти и изменить»)
Возможно, на одной действие больше. Зато всю цветовую схему можно поменять за 10 секунд.
Есть такое дело! Но зачем менять всю цветовую схему, так ради баловства: сегодня хочется чтобы был красный, а завтра зеленый? Насколько часто Вам приходилось менять цветовые схемы одного проекта?
У нас своя цмс, все компоненты самописные, все элементы ui и тд. Новый проект на цмс — новый дизайн. Поменял один базовый цвет и весь UI брендировался под цвет дизайна. Но не цветами едиными, как писал ниже, очень часто нужно стилизировать формы, изменить высоту строки. Поменял одну строку высоты, все элементы подстроились под неё. Не нужно копировать базовые стили в шаблон дизайна и всё вручную пересчитывать.
SerDIDG, конечно, речь не только о цвете. Согласен, что в случае «поменять всю схему» это удобно! Но как быть в случае, если нужны изменения одного элемента, которые не вписываются в рамки автоизменений? Ведь, наверняка, Вы согласитесь со мной, что мелкие изменения производятся уж никак не реже общего ребрендинга (пусть даже одной формы, пусть даже и с настроенными общими схемами отступов и высот инпутов), а уж особенно на стадии становления проекта.
SerDIDG, будьте любезны, код в студию! Буду признателен за возможность до конца открыть less для себя как полезный инструмент!
SerDIDG, будьте любезны, код в студию! Буду признателен за возможность до конца открыть less для себя как полезный инструмент!
Каждый компонент у меня фактически в своём отдельном файле. По названию класса / префикса я знаю что это за компонент и открываю нужный файл, либо смотрю в файле настроек, где так же каждый компонент имеет свой префикс, есть ли для нужно мне элемента отдельная переменная. В любом случае, вся стилизация у нас производится в файлах шаблона, а базовые файлы стилей мы не правим, так как они общие для всех проектов на этой цмс. Если нужно что-то изменить конкретное, просто вписываю нужные стили в файл шаблона, или в файл с переменными в шаблоне, переопределяя их. Очень часто по ходу стилизации создаю новые переменные, в будущем они помогают, и при следующих новых дизайнах стилизация сводится всё больше к переопределению настроек.
Я не навязываю использования less, и не могу сказать что мой код отображает правильное / задуманое использование этого инструмента. До сих пор не до конца понял смысл guard'ов. Я не могу показать код конкретного проекта из-за контракта, а так же как те или иные части выглядят на разных дизайнах, но часть, которую мне удалось отделить в отдельную библиотечку, да. Опять же, что конкретно вам показывать я не знаю, для меня оно понятно, что и где, а для стороннего человека, скорее всего будет сложно. Библиотечку делаю сам, так что там много достаточно старых кусков, которые стоит причесать и тд. Некоторым участкам кода уже наверное года 4 :) Если интересно, вот репозиторий: github.com/SerDIDG/FioraUI и частично демо — serdidg.github.io/FioraUI
Я не навязываю использования less, и не могу сказать что мой код отображает правильное / задуманое использование этого инструмента. До сих пор не до конца понял смысл guard'ов. Я не могу показать код конкретного проекта из-за контракта, а так же как те или иные части выглядят на разных дизайнах, но часть, которую мне удалось отделить в отдельную библиотечку, да. Опять же, что конкретно вам показывать я не знаю, для меня оно понятно, что и где, а для стороннего человека, скорее всего будет сложно. Библиотечку делаю сам, так что там много достаточно старых кусков, которые стоит причесать и тд. Некоторым участкам кода уже наверное года 4 :) Если интересно, вот репозиторий: github.com/SerDIDG/FioraUI и частично демо — serdidg.github.io/FioraUI
SerDIDG, премного благодарен! … интересует именно использование общенастроенного стиля форм, то о чем Вы говорили ранее! Решение пока не перекрывает минусы, но это еще один несомненный плюс в копилку достоинств LESS.
Надеюсь когда-нибудь по-настоящему оценю всю прелесть препроцессоров вообще и LESS в частности!
Большое человеческое спасибо и Всех благ!
Надеюсь когда-нибудь по-настоящему оценю всю прелесть препроцессоров вообще и LESS в частности!
Большое человеческое спасибо и Всех благ!
Не очень понял что вы имеете в виду.
Вот у меня есть стиль:
Ставлю курсор на @link-color и жму F12:
Это разные less-файлы, один из которых ссылается на другой.
Вот у меня есть стиль:
Ставлю курсор на @link-color и жму F12:
Это разные less-файлы, один из которых ссылается на другой.
Да, dobriykot, вы все правильно поняли. Вы привели пример одной переменной, поэтому не так явно видны потери во времени. Часто для того чтобы получить всего лишь это:
существуют конструкции вида:
… и это не самая длинная цепочка!
Встречаются и подобные конструкции:
Возникнет вопрос: чем может быть оправдано столь серьезное затягивание такого примитивного действия, как замена единственного стиля единственного конкретного элемента?
Открываю описание в поисках скрытых возможностей и полезностей: "… позволяет сделать CSS более поддерживаемым, тематизируемым..." – хорошо, это беспорно полезно! Но тематизирование можно легко сделать и в самом CSS.
Имеет смысл движение в 2-х направлениях:
Поскольку
То есть, в конечном итоге, less все-таки призван облегчить жизнь разработчика и ускорить процесс, не так ли?
Берем конкретный пример: сократить время на добавление все тех же вендорных свойств transition, box-shadow, border-radius и т.п.
Но ответьте, пожалуйста, мне на вопрос: для чего объявлять переменную (или класс) – создавать дополнительный элемент (а ведь на создание его тоже уходит время), чтобы потом добавить одну строку вместо огромных кусков, если набрав пару символов + Tab в Emmet мы делаем ту же операцию в реальном времени без всяких переменных, вложенностей и миксинов.
а {
color: #66c2ff;
}
существуют конструкции вида:
/* стиль: */
а {
color: @baseLighterLink;
}
/* один файл: */
@baseLighterLink: lighten(@baseLighterColor, 15%);
/* второй файл: */
@baseLighterColor: lighten(@baseColor, 5%);
/* третий: */
@baseColor: #0099FF;
… и это не самая длинная цепочка!
Встречаются и подобные конструкции:
@baseColor: @baseGreenColor;
Возникнет вопрос: чем может быть оправдано столь серьезное затягивание такого примитивного действия, как замена единственного стиля единственного конкретного элемента?
Открываю описание в поисках скрытых возможностей и полезностей: "… позволяет сделать CSS более поддерживаемым, тематизируемым..." – хорошо, это беспорно полезно! Но тематизирование можно легко сделать и в самом CSS.
Имеет смысл движение в 2-х направлениях:
- улучшения качества продукта: скорость загрузки / работы, удобство и дружественность по отношению к пользователю;
- удобство для разработчика – ускоряет процесс разработки, а значит снижает себестоимость продукта.
Поскольку
То есть, в конечном итоге, less все-таки призван облегчить жизнь разработчика и ускорить процесс, не так ли?
Берем конкретный пример: сократить время на добавление все тех же вендорных свойств transition, box-shadow, border-radius и т.п.
Но ответьте, пожалуйста, мне на вопрос: для чего объявлять переменную (или класс) – создавать дополнительный элемент (а ведь на создание его тоже уходит время), чтобы потом добавить одну строку вместо огромных кусков, если набрав пару символов + Tab в Emmet мы делаем ту же операцию в реальном времени без всяких переменных, вложенностей и миксинов.
4символа в Emmet
Я понял все ваши претензии и не настаиваю чтобы вы использовали ту или иную технологию. Могу сказать со стороны программиста, что повторение кода — это плохо. Все что у повторяется более одного раза всегда хочется унифицировать в одном месте. LESS позволяет избежать этого повторения, пусть и небольшой ценой разбора цепочек.
Ну это еще объяснимо. Представьте, что у вас есть перечисление всех одобренных дизайнером цветов и базовый цвет. И тут вам говорят «меняем сайт с красного на зеленый». И вы корректируете одну строку, меняя baseRedColor на baseGreenColor вместо автозамены по десятку файлов. И еще представьте, что у вас красный использовался не только для базового цвета, но и, скажем, для окошка с ошибкой. Автозаменой и оно затронется. А так исправится только то что надо.
Короче, LESS для меня — это серьезное упрощение действий именно того, кто пишет стили. Конечному пользователю все равно.
Встречаются и подобные конструкции:
@baseColor: @baseGreenColor;
Ну это еще объяснимо. Представьте, что у вас есть перечисление всех одобренных дизайнером цветов и базовый цвет. И тут вам говорят «меняем сайт с красного на зеленый». И вы корректируете одну строку, меняя baseRedColor на baseGreenColor вместо автозамены по десятку файлов. И еще представьте, что у вас красный использовался не только для базового цвета, но и, скажем, для окошка с ошибкой. Автозаменой и оно затронется. А так исправится только то что надо.
Короче, LESS для меня — это серьезное упрощение действий именно того, кто пишет стили. Конечному пользователю все равно.
Все переменные можно и нужно хранить в одном файле. С названием порой у меня возникает проблема, но после какой-то большой проделанной работы делаю небольшой рефакторинг и привожу всё к нормальному виду. Вот мой пример такого файла:
github.com/SerDIDG/FioraUI/blob/master/less/variables.less
Да и дело то не только в цветах. Например можно задавать переменной высоту поля ввода (input), и относительно неё пересчитаются все размеры, падинги, line-height, и тд. Раньше приходилось огромные куски стилей копировать в файл шаблона, чтобы выровнять все размеры и отcупы, а теперь в файл настроек шаблона одну строку вписать. В основном в плане стилизации форм очень удобно.
github.com/SerDIDG/FioraUI/blob/master/less/variables.less
Да и дело то не только в цветах. Например можно задавать переменной высоту поля ввода (input), и относительно неё пересчитаются все размеры, падинги, line-height, и тд. Раньше приходилось огромные куски стилей копировать в файл шаблона, чтобы выровнять все размеры и отcупы, а теперь в файл настроек шаблона одну строку вписать. В основном в плане стилизации форм очень удобно.
Дело не в том, что LESS плохой, может вы просто не умеете его готовить?
Sign up to leave a comment.
LESS? — мнение обывателя-верстальщика или дизайнера со стажем