re: Css препроцессор

HTML, верстка, кодинг, CSS /
Проголосовал позавчера тут jnet.kz/blog/httml/3195.html, сейчас дошли руки написать развёрнуто. Получилось слишком много для комментария – там ещё и шрифт мельче, так что оформлю отдельным постом.

Мы используем less, по возможности, везде. Возможность есть не всегда, в особенности, когда вёрстка чужая – пока ещё ни один местный потенциальный исполнитель не выразил готовности сверстать нам что-нибудь в less, а необходимость потом копаться в сырой чужой вёрстке на ванильном css с диким количеством копипасты жутко нервирует. Поэтому, займусь пропагандой здорового образа жизни среди местного населения. ;)

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

Повторное использование


Синтаксис css очень слабо подходит для повторного использования. Банально перенести между макетами часть стилей, когда разметка совпадает не на сто процентов – целая проблема. Начиная с механического перебивания вложенности селекторов и отслеживания того, от кого какие стили унаследованы, заканчивая борьбой с различиями в специфичности селекторов.

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

Любой css препроцессор позволяет получить скорость от повторного использования, сохранив гибкость, поскольку подключать можно как большие, так и мелкие фрагменты, причём, только те, которые нужно. А качество даже улучшить, хотя, это от кривизны рук зависит. ;)

Даже тупо копипастить кусок стилей для препроцессора проще: вложенность блоков позволяет не перебивать каждый родительский селектор, а просто вставлять код в нужное место. А если вместо этого оформить кусок в виде миксина и в нужном месте его вызывать, то со временем накопится персональная библиотека реюзабельных наработок – чем не стратегия среднесрочной капитализации? ;) Не говоря уже о том, что можно подключить какую-нибудь уже готовую библиотеку со стандартными вещами, типа наборов свойств с вендорскими префиксами.

Область видимости


Та же самая вложенность блоков косвенно приводит к более чёткому ограничению области действия стилей. Отсутствие необходимости прописывать руками каждый родительский селектор даёт возможность привязывать оформление на максимально конкретном уровне. В результате, паразитные влияния оформления одних элементов на другие практически исчезают.

Поясню на утрированном примере: скажем, если оформляется кнопка, с препроцессором удобно её не как абстрактную кнопку оформить, а как кнопку в форме логина в шапке. А когда потребуется добавить другую форму на сайдбар, стиль кнопки в форме на сайдбаре (а то и всей формы) можно будет либо импортировать из шапки, либо вынести оттуда в общий миксин, который подмешать в оба места. То есть, зависимость стилей становится явной, гадать о путях наследования приходится гораздо меньше и резко снижаются шансы сломать впоследствии что-нибудь рядовым изменением. Хотя, за размером скомпилированной цсс-ки приходится следить.

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

Я не хочу сказать, что остальные фичи не нужны – там масса всего полезного. Просто не повторять вендорские префиксы – уже хорошо, какая-нибудь библиотека функций для работы с цветами – тем более. Приятно, грамотно вынеся переменные и вычислив из них остальное, наблюдать, как при изменении одного размера остальные подравниваются сами, или при изменении цвета перекрашиваются все полутона – думаю каждый, кто хоть раз хватался за голову от фразы «расширить сайдбар на 28 пикселов», судорожно вспоминая все места с отнятыми паддингами и бордерами, которые придётся пересчитывать, это понимает. ;)

Но на лично мой взгляд, level up приходит с изменением подхода к вёрстке с «оформление конкретной структуры с привязкой к месту, откуда стили могут быть унаследованы» на «описание отдельных аспектов оформления миксинами и подмешивание их в конкретно те места структуры, где они используются». А всё остальное – это дополнительные бонусы.

Собственно less


Синтаксически less — это надмножество css. То есть, практически весь корректный css – это и корректный less. На практике не пролазят всякие css hacks и старинные микрософтовские директыксовые фильтры, их приходится эскейпить. В остальном, это экономит кучу усилий по переформатированию каждого фрагмента, найденного на stackoverflow, и (камень в огород стайлуса) позволяет не разводить в результате этого бардак в коде, если поддерживается несколько видов записи.

Синтаксис для расширений там тоже css-образный, используются символы, которые в css уже есть: точки, собаки, двоеточия. С одной стороны это плохо – в некоторых случая возникает неоднозначность разбора и авторы с ней постоянно воюют в компиляторе, с другой — это не выглядит чужеродным и довольно органично воспринимается.

Идеологически less ближе к css, чем остальные препроцессоры – он тоже декларативный, в то время как остальные императивные. Некоторые личности в этих ваших интернетах возмущаются, что «в less даже нет циклов, как так» – они не шарят. Во-первых, итерация запросто делается рекурсивными миксинами, а во-вторых, обоснованная потребность в этом возникает крайне редко. Часто приводимый пример – колонки для модульной сетки – это вообще антипаттерн: такие вещи должны подмешиваться к конкретным контейнерам и рассчитывать всё по принятым параметрам. А идея «нагенерить кучу мусора в выходной цсс» противоречит самой цели использования препроцессора. Я недавно вспоминал, навскидку вспомнил пару случаев, когда это было бы оправдано, и оба – совершенная экзотика.

Инструментальная поддержка у less вполне приемлемая. Куча редакторов понимает синтаксис, куча утилит и сборочных систем умеет его собирать, для большинства распространённых серверных языков есть модули для компиляции.

С полдюжины библиотек миксинов гуглится по запросу «less mixin library», но какого-то абсолютного лидера типа compass вроде бы нет. Ещё, кажется, твитеровский бутстрап можно в таком качестве использовать, но это немного не то.

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

При этом less ещё умеет watch – ему можно включить режим, когда он сам постоянно проверяет, не обновился ли исходный файл, и перегружает стили на ходу, без необходимости «теребить ф5».

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

Впрочем, сейчас это уже не кажется таким откровением, как несколько лет назад. Live reload – фича уже достаточно распространённая: большинство приличных IDE уже умеют это из коробки, в уже упомянутом prepros она есть, ко многим браузерам сделаны плагины, масса других инструментов для этого существует. Нет оправдания тем, кто этим пренебрегает. ;)

Но, при всём этом, less watch от остальных способов перегрузки качественно отличается: они все работают в искусственно создаваемых условиях, им нужен либо собственный встроенный разработочный сервер, либо конкретная версия конкретного браузера, в общем, есть чётко очерченные границы того, где это работает в полный рост. Для обновления файла по инициативе less из браузера достаточно возможности этот файл получить аяксом. У большинства браузеров это работает и без http-сервера с файловой системой, правда некоторым приходится настроить безопасность. Ещё это не слишком быстро, но приемлемо, работает на современных телефонах по вайфаю. Это работает даже если подменять руками файлы в каталоге, куда распакован задеплоеный на сервер приложений архив со сборкой софта. Более того, less может обновляться параллельно с другими методами live reload, например, в одну сторону IDE пропихивает своему браузерному плагину изменения в html, а в обратную сторону less из браузера мониторит свои исходники.

Разумеется, в этом есть и минусы – принципиально нереализуемой в браузере функциональности в less нет, и не ожидается. Поэтому, на тот же компасовский склеиватель спрайтов, или функции получения размера картинок можно и не надеяться.

А по большому счёту, разница между препроцесорами меньше, чем между их наличием и отсутствием.

Заключение


Даю установку: css препроцессор – это инструмент, которым обязательно нужно владеть. Конкретная разновидность непринципиальна – зная один, разобраться с другим не проблема. У тех, кто это умеет, вопросов о применимости возникает гораздо меньше. Тот, кто не использует доступный инструментарий, выполняет свою работу медленнее и хуже, чем мог бы. «Программист, а не верстальщик» – не аргумент: программистам это освоить проще, у них навык обобщения кода уже прокачан. «Нет времени» – не аргумент: если времени не хватает, чтобы начать его экономить, оно никогда и не появится. «Наработки в css» – не аргумент: половина препроцессоров сможет использовать их, как они есть, а с незначительной доработкой ещё продуктивнее.

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

26 комментариев

faiwer
1. Без SCSS уже не представляю себе работу с CSS. Как будто в каменный век попадаешь
2. Профессия «верстальщик» мне кажется бесполезной. Никогда бы недоверил вёрстку какому то левому чуваку, который почти ничего в стеке технологий не понимает, всё равно весь его труд выкидывать.
talgautb
Профессия «верстальщик» мне кажется бесполезной.
как-то обидно прозвучало :(
faiwer
«Ну специалист по левой ноздре» — тоже звучит обидно, но тем не менее :-)
talgautb
а Вы как считает: верстать должен программист или дизайнер или?
faiwer
Web-технолог. Не в коем случае не дизайнер, в этом я давно убедился. Дизайнеру ничего не стоит поставить на фон мегабайтную png-ку шириной 1600px вместо 1 jpeg-тайла весом в 80кб, с тем же результатом.
talgautb
ну, я вижу это так:
в начале верстальщик, а затем уже растешь в web-технолога/фронтендщика
faiwer
Понятие «фронтендщик» мне нравится. Но не замечал я у нас подобных вакансий, к тому же за разумную з\п :) Хотя если работать на какой-нибудь забугорный стартап… это вполне может быть вкусным )
bsl_zcs
не замечал я у нас подобных вакансий, к тому же за разумную з\п
В Караганде точно есть. У нас, например. ;)
bsl_zcs
С первым пунктом соглашусь, со вторым – нет.

Конкретно верстка – это сравнительно неплохо отчуждаемая задача. Как минимум, один (свой) уровень в стеке верстальщик должен знать досконально, а специфические требования, налагаемые остальными уровнями, явно оговариваются в задании. Конечно, наивно ожидать что «левый чувак» всё сам сделает и принесёт готовое, прорабатывать детали с ним придётся. Но для терпимого взаимодействия со сторонними верстальщиками, в принципе, достаточно среднего навыка делегирования работ, обычно это не самая проблемная часть.

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

Нравится нам это или нет, но разработка софта – это командный вид спорта. Любой не совсем тривиальный проект приходится как-то делить между исполнителями. А специализация работников экономически целесообразна. К сожалению, совместно владеющая всей кодовой базой команда универсальных солдат, каждый из которых способен делать всё от и до – это утопия и в реальном мире не встречается. Так что разделение по естественной технологической границе – ещё не самый плохой вариант.
faiwer
Я очень трепетно отношусь к таким вещам как оптимизация, особенно frontend. Сжатие скриптов, свой загрузчик, DataURI вместо спрайтов. Во всём есть свои стандарты, даже в том же самом именовании классов. Подходе к размещению изображений, их компановки. Определённыe внутренние SCSS стандарты, глобальные переменные в нём же, готовые шаблоны, Compass… Блин да всё даже перечислять устану. И тут какой то левый Вася, который знает CSS может мне в этом помочь? 80% времени сэкономленной при помощи Васи я потрачу на то, чтобы привести его поделие в правильную форму. И то, лишь в том случае, если Вася толковый «спец», и такие вещи как сжатие png для него рядовая рутина. В целом я делаю простой вывод — Вася не нужен, как и вся его профессия по левой ноздре. Редко затрачиваю больше 5-7 часов на вёрстку, в отличии, к примеру, от админки для небольшого модуля, где можно засесть на пол недели.

Не вижу смысла в разделение задач записывать вёрстку. Дизайн однозначно за технол.границей, вёрстка, ИМХО, нет.
bsl_zcs
Это просто отсутствие навыка делегирования. Осваивайте, всё равно придётся рано или поздно переходить с односпальных проектов на что-то более крупное.

По пунктам:

Сжатие скриптов, свой загрузчик,
Это верстальщика не касается. Дописать к сборочному скрипту его таблицы стилей может и тот, кто сборкой занимается.

DataURI вместо спрайтов
Это вообще неоднозначный вопрос. Попалось на днях: www.mobify.com/blog/css-sprites-vs-data-uris-which-is-faster-on-mobile/ Думаю, там разница от одного лишнего хттп-запроса амортизируется закачкой параллельно цсс-ке и тем что увеличение её объёма из-за base64 не полностью компенсируется гзипом.

свои стандарты, даже в том же самом именовании классов. Подходе к размещению изображений, их компановки. Определённыe внутренние SCSS стандарты, глобальные переменные в нём же, готовые шаблоны, Compass…
А это всё зона ответственности самого верстальщика. Не надо ему мешать делать так, как он считает правильным – он специалист, ему должно быть виднее. Если не обеспечен результат с соответствующим качеством – пусть устраняет имеющиеся претензии. Если не может – менять на другого. Плохого, значит, специалиста выбрали, жирный минус вам. В общем, всё как у всех, ничем не отличается от любой другой профессии.

Дизайн однозначно за технол.границей
Тут вынужден согласиться. Дизайнеры не умеют верстать, и программисты не умеют рисовать – это данность. Иногда, крайне редко, попадаются программеры, которые могут оформить софт, пусть не слишком красиво, но хотя бы не страшно, вот у них разметка поручается просто изумительная. Когда выразительные возможности изначально выбираются из числа тех, которые браузер умеет, а не произвольная картинка к ним с костылями приводится. Но рассчитывать на то, что повезёт таких найти, не приходится.

какой то левый Вася, который знает CSS
А вот на личности попрошу не переходить. И вообще, откуда вы узнали как меня зовут? К тому же, я и не верстальщик вовсе. ;)
faiwer
И вообще, откуда вы узнали как меня зовут?
До сего момента я понятия не имел как вас зовут, думал, что bsl_zcs :) Вася имя нарицательное :D

Это вообще неоднозначный вопрос. Попалось на днях: www.mobify.com/blog/css-sprites-vs-data-uris-which-is-faster-on-mobile/ Думаю, там разница от одного лишнего хттп-запроса амортизируется закачкой параллельно цсс-ке и тем что увеличение её объёма из-за base64 не полностью компенсируется гзипом.
Вопрос неоднозначный, согласен. Радует что хоть кто-то ещё в нашей стране слышал про datauri :) Если хотите могу подискутировать в личке, ибо у меня уже порядочный опыт с datauri :) Если кратко — почти всегда без datauri есть уйма гифок, которые в спрайты не загонишь, спрайтов более 1-2-3 штук, и сами спрайты это довольно избыточно жирные png-ки. Datauri позволило мне очень солидно ускорить загрузку страницы. Но лучше здесь об этом не флудить =)

А это всё зона ответственности самого верстальщика. Не надо ему мешать делать так, как он считает правильным – он специалист
Не укладывается в моей голове слово «специалист» с человеком, который почти ничего не умеет и почти ничего не знает. Неужели среди них есть специалисты? Я не удивлюсь если 50% верстальщиков не имеют понятия даже о том, что такое спрайт.

В общем, всё как у всех, ничем не отличается от любой другой профессии.
Приведите пример из другой области :)

Отмечу, что я очень предвзято отношусь к этому, просто потому, что у меня есть среднее худ.образование, небольшой чувство прекрасного и немного перфекционизма. И да, я предпочитаю работать соло. Либо с людьми, умеющими сложить 2+2 :) Есть небольшой опыт работы в команде с ярыми халтурщиками, любителями костылей и прочих быстрых решений, которые в будущем ставят крест вообще на проекте в целом… Лучше соло, чем с такими.
talgautb
мне кажется, Вы ошибаетесь, но Ваша точка зрения понятна: верстальщики — не нужная профессия, потому что Вам встречались только ничего не знающие :)
я вот верстальщик, использую вышеописанное ;)
работать в команде сложно, но на больших проектах никак уж, по крайней мере в цепочке дизайнер — верстальщик/фронтендщик — программист.
faiwer
Т.е. Javascript-ом у вас занимается верстальщик? :)
talgautb
Да, точнее фронтендщики.
просто я еще не могу себя так называть :) думаю когда js подтяну, тогда можно будет))
bsl_zcs
есть уйма гифок, которые в спрайты не загонишь
Имеется в виду анимированных гифок? То есть, к css3 анимации позиции фона (типа codepen.io/bsl-zcs/pen/lpaGv ) вы не склонны? А что так? Всё-таки полноценная прозрачность…

спрайтов более 1-2-3 штук
Зачем больше трёх? В самом запущенном случае три: вертикальный, горизонтальный и всё остальное.

Не укладывается в моей голове слово «специалист» с человеком, который почти ничего не умеет и почти ничего не знает. Неужели среди них есть специалисты?
Вы почему-то приравниваете знания вообще к знанию жабаскрипта. Области человеческой деятельности обширны, и я бы даже сказал, что многие из специалистов других областей на тех, кто пишет жабаскпритики, смотрят с некоторым пренебрежением.

Самый приличный верстальщик, с которым я работал, прямо говорил, что он вообще админ, и «скрипты писать – это не моё». Правда, он давно от этого отошёл, и сейчас спокойно админит по банкам. Если так подумать, то админский образ мышления неплохо подходит для вёрстки – им тоже часто приходится глюки в софте взаимно балансировать.

чувство прекрасного и немного перфекционизма
Это хорошо. Только доводить до патологии не надо.

Пример из жизни: когда-то у нас был проект, по поводу которого мы тоже били себя пяткой в грудь, мол, у нас там есть все существующие на то время навороты, оптимизировано всё до упора, рейтинг А по YSlow (тогда это было ещё модно), и так далее. Потом нас с того проекта выперли и через несколько лет заменили нашу версию другой. Там первая страница 4 с лишним мегабайта и под сотню хттп-запросов. И что? Пара человек повозмущались, что rss пропал, и всё. Вот и весь перфекционизм.

Нормальным людям на ваши несколько килобайт разницы глубоко плевать, можете быть уверены.
faiwer
То есть, к css3… вы не склонны?
Неа. Какой то изврат =) К тому же CSS3

многие из специалистов других областей на тех, кто пишет жабаскпритики, смотрят с некоторым пренебрежением.
И имеют на это полное право. 99.999% людей, которые пишут жабаскриптики пишут их пяткой правой ноги по накурке. Javascript грамотность… я бы даже сказал тотальная javascript-безграмотность повсюду царит. Толковые js-кодеры большая редкость. Вон, даже верстальщики уже на джикуери кодют… Пичаль-беда.

Пара человек повозмущались, что rss пропал, и всё. Вот и весь перфекционизм.
4 МБ не заметили? Некислые там у клиентов интернеты.

Нормальным людям на ваши несколько килобайт разницы глубоко плевать, можете быть уверены.
Несколько КБ тут, несколько там, несколько в третьем месте. 1 запрос тут, 1 там… И в итоге имеем разницу в 2+ раза. Для серьёзного проекта может быть довольно весомым аргументом. К тому же от работы нужно получать удовольствие, или ну её нах эту работу. Я бы не мог быть ремесленником, не такой склад ума, свихнусь от скуки и уныния =)
talgautb
Хороший, аргументированный ответ :)
я еще не такой гуру в css препроцессорах, но
css препроцессор – это инструмент, которым обязательно нужно владеть.
полностью, согласен. При чем голосование показывает, что мало кто использует их.

когда вёрстка чужая – пока ещё ни один местный потенциальный исполнитель не выразил готовности сверстать нам что-нибудь в less
а если, например, вам дали верстку на scss как faiwer, в less можно использовать?
faiwer
Если в scss не будет логики типа @if, то переделка займёт не так много времени.
bsl_zcs
Если это вопрос про возможность намешать в проекте несколько препроцессоров, то ответ: не надо так делать. Даже если и получится так извратиться технически, это напрочь лишено практического смысла. К чему отягощать и без того муторную борьбу с совместимостью браузеров борьбой с совместимостью препроцессоров?
talgautb
понравилась презентация по теме.
погуглил немного по теме less vs stylus (просто я less не использовал) интересно, но большинство на западе больше склоняются к stylus, говоря, что less устаревает :)
bsl_zcs
большинство на западе больше склоняются к stylus, говоря, что less устаревает
Я же писал про таких: «они не шарят». ;) Конкретные претензии могу прокомментировать, если будут.
talgautb
bsl_zcs
А вы её вообще читали? Это статья одного из разработчиков лесс, он-то шарит, не вопрос. ;) Претензий там нет, там есть список фич, варианты заимствования которых они обсуждали. Часть из этого уже реализована, а практически всё остальное сейчас делается другими способами. Иногда костыльными. Подробности в обсуждениях по ссылкам.

Распишу по пунктам:

1. Это уже есть. Меня это, кстати, удручает: вместо таких сассо-образных костылей надо было делать полноценный проход оптимизации с дедупликацией и выносом общих стилей. А теперь это у них вряд ли получится, и придётся всегда это делать руками.

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

3. Банально после импорта переопределять надо, а не до. Там ленивое вычисление.

4. Уже есть функция extract для выдирания элемента из списка.

5. Сомнительная польза, но при желании запросто можно сделать встроенным жабаскриптом:
@log: `""+console.log(@{test})`;

6. Тут можно блок оформить локальным миксином перед вызовом. В некоторых случаях удобнее строчками передавать.
Лично мне не нравится, в каком направлении они это обсуждают: думаю, если бы они просто в лоб сделали возможность получить содержимое блока текстом в переменную и просто её потом вывести, на базе этого можно было бы массу полезного построить, а они цепляются за отдельные варианты использования.

7. Сейчас просто присваивают в миксине значение переменной, и снаружи получают результат из неё.

8. Единственный полезный стиль – минифицированный, включается отдельной опцией при компиляции. Остальное вообще бессмысленно, глазами туда никто всё равно не смотрит.

9. Это обходится запросто, но мусорит в выходной разметке.
@prop: ~"background: red";
hack: ~"1;@{prop}";
Если такого будет много, то имеет смысл на постпроцессинге вырезать. Почему они этого до сих пор не сделали, я не понимаю, но вроде бы собираются.

10. Сводится к предыдущему. И сейчас, и после того как интерполяцию сделают.

Хочу подчеркнуть, что список в той статье – это не сравнение фич препроцессоров. Это список задач по различиям от команды разработки одного из них. У других команд должны быть аналогичные списки.
nyekimov
«верстальщик профессия не нужная» — как то в году 2011 где то был на приеме гостей-докладчиков какой то недели интернета, точное название мероприятия не помню. Так вот, моя бывшая коллега от лица международной компании принимала докладчика из Польши доктора наук, каких точно не знаю, но скорей всего в информационных технологиях. Так вот, этот доктор наук ужасно был напышен тем, насколько он крут, я спросил, а чем он занимается, он сказал, что совсем недавно сверстал веб проект на html 5 и тот полностью валиден, проект международный, заказчик вроде бы даже из штатов. Это его основная роль в проекте. Я конечно долго смеялся, но все же это цивилизованный подход.
faiwer
Убер-узко-специализированный специалист :) Вроде тех людей, что умеют на скорость приготовить 20 донеров :)
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.