Что такое css препроцессоры

CSS-препроцессоры против CSS

Свой первый сайт я сделал в 2000 г., около 10 лет писал на обычном CSS и очень его люблю, однако предпочитаю CSS-препроцессоры, т.к. с ними работа идёт быстрее, результат получается более масштабируемым, а порог вхождения в проект увеличивается незначительно. CSS может успешно использоваться в разработке серьезных проектов только при условии его постобработки.

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

Необходимое введение: компонентный подход

Мы живём в эпоху компонентного подхода: интерфейс проекта делится на компоненты (кнопки, вкладки, записи…), которые можно использовать много раз, вкладывать друг в друга, модифицировать. Проще всего добиться этого — использовать методологию БЭМ, в которой компоненты называются Блоками. Более сложные варианты (CSS-модули, CSS-in-JS), обычно завязаны на технологии (фреймворки, вроде React).

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

  • Безопасно включать и отключать компоненты. Когда компонент не используется, его стили, скрипты и пр. не загружаются посетителю (зависит от организации сборки).
  • Иметь несколько «сборок» (стилевых и других файлов), отдаваемых в браузер для разных частей проекта. К примеру, если на сайте есть публичная и приватная части, то стили, скрипты и спрайты приватной части можно подключать отдельно, чтобы не тратить время на их загрузку и обработку для неавторизованных посетителей.
  • Безопасно модифицировать компоненты. Меняя стили одного компонента, крайне сложно сломать другой компонент (но, если постараться, можно).
  • Быстро находить точку редактирования. Когда известно название редактируемого класса, находим файл с тем же именем ( Ctrl + P во многих редакторах) и редактируем. Ориентироваться по коду быстрее и проще, т.к. сам файл имеет меньший размер.
  • Использовать компоненты в других проектах. Базовые стили многих элементов (тех же кнопок) одинаковы от проекта к проекту. Копируем блок из стартовой библиотеки и дописываем нужные проекту стили.
  • Собирать свою библиотеку компонентов. Компоненты, из которых состоят страницы сайтов, часто повторяются: кнопки, соц. ссылки, список пользователей, карточка товара, поле ввода текста с описанием. Можно один раз написать для компонента относительно универсальную разметку, стили, javascript для применения на любом проекте и не изобретать велосипед.

CSS-препроцессоры

Это языки написания стилей, похожие на CSS, но с возможностями, которых не хватает в CSS. Напрямую в браузере не работают, нуждаются в компиляции, результатом которой является CSS-файл. Как это работает: вы запускаете какое-либо ПО (в моём случае — gulp или webpack), оно следит за сохранением препроцессорных файлов и собирает (компилирует) из них CSS-файл. Заодно и страницу в браузере автоматически обновляет.

Актуальные CSS-препроцессоры: Sass (2006 г., лидер рынка), LESS (2009 г., весьма хорош), stylus (2010 г., прекрасен, но не разрабатывается) и PostCSS (2013 г., изначально для постпроцессинга, но с ним можно повторить почти всю функциональность настоящих препроцессоров). PostCSS используется почти во всех проектах и в виде постпроцессора.

Далее сравнение CSS-препроцессоров с обычным CSS.

Разделение на небольшие файлы

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

В CSS есть импорты

Браузер, встречая импорт, идёт по указанному пути, загружает и обрабатывает CSS-файл.

Дьявол в мелочах:

  1. Если в одном CSS-файле написать импорт другого, они будут загружаться последовательно, а не параллельно, как могли бы (увеличение времени до начала рендера на медленных каналах). Это хуже, чем написать в разметке два <link> .
  2. Любое подключение дополнительного файла к странице — дополнительный запрос к серверу (увеличение нагрузки на аппаратную часть сервера), как следствие — при средней и высокой посещаемости сайта все файлы будут отдаваться в браузер медленнее. Спасти может использование протокола HTTP2 (позволяет за один запрос получать несколько файлов), но всего 29,6% из 10 млн. самых популярных сайтов используют его (данные на середину 2018 г., за последний год распространённость выросла почти в 2 раза).

В CSS-препроцессорах импорты работают иначе

В CSS-препроцессорах импорты обрабатываются на этапе компиляции в CSS: если мы импортируем препроцессорный файл, его содержимое «вставится» вместо импорта. В итоге — один CSS файл, содержащий стили всех импортированных файлов.

Итог: импортирование в препроцессорах лучше

Без HTTP2 (менее 1/3 всех сайтов) CSS-импорты — почти всегда зло (увеличение количества запросов к серверу).

Переменные

Это удобно и расширяемо. Записываем в переменную с именем color-danger предупреждающий об опасности цвет, используем переменную везде, где нужен такой цвет (цвет текста в сообщении об ошибке под текстовым полем, бордюр текстового поля, цвет фона сообщения о критической ошибке в нижнем правом углу, фоновый цвет кнопки опасного действия и т.п.). Сменим значение переменной — получим изменения везде, где она применялась.

В CSS есть custom properties

Это как переменные, но круче, ибо работает прямо в браузере. Если значение «переменной» изменить (по медиа-условию или javascript-ом), изменятся стили на всех селекторах, где применена «переменная». К custom properties применяется наследование и каскад.

Первый минус: custom properties не работают в Internet Explorer всех версий (разработка IE прекращена в пользу Edge, где custom properties работают) и в старых Safari (поддерживаются с 9.1 и 9.3 — для мобильного). Костыли в виде cssnext позволяют в небольшом количестве случаев решить эту проблему (глючно, поскольку плохо работают с медиавыражениями или не работают с ними вове). В любом случае, это потеря тех возможностей, благодаря которым custom properties круче, чем препроцессорные переменные.

Второй минус: custom properties не получится применить в CSS-анимациях, т.к. их значения — строки, а браузер не может (пока?) вычислить плавный переход между двумя строками. Решение этой проблемы возможны с javascript, я уверен.

В CSS-препроцессорах переменные — обычные переменные

Препроцессорные переменные работают только на этапе компиляции. Это никак не мешает присвоить их значения в CSS custom properties, чтобы использовать их же как CSS-переменные.

Итог: CSS-переменные круче, если в ТЗ нет IE и старых Safari

Если в техническом задании упомянута поддержка IE или по метрике вы не можете игнорировать старые Safari (особенно актуально для мобильных версий), то CSS custom properties «превращаются в тыкву» — становятся ничуть не лучше препроцессорных переменных.

Математические операции

Мат. операции и переменные созданы друг для друга. Но мат. операции ещё «гуляют налево» (в CSS).

В CSS есть calc()

И он восхитителен по тем же причинам, по которым прекрасны CSS custom properties. Но calc() круче, поскольку поддерживается в IE (хотя и не без багов).

Поскольку это срабатывает в браузере, в момент выполнения предыдущего примера браузер знает чему равно 3em и ширина действительно будет 100% — 3em .

В CSS-препроцессорах есть мат. операции

И calc() никто не запрещает использовать (в LESS придется экранировать, иначе внутри скобок произойдёт мат. операция).

Что есть в CSS-препроцессорах, чего нет в CSS

Единственное, в чём функциональность CSS превосходит препроцессоры — custom properties. Это действительно офигенно. Но что такого есть в препроцессорах, чего нет в CSS?

Вложения

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

Амперсанд

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

ВНИМАНИЕ: амперсанд не стоит использовать в местах разделения слов, а только в местах отделения БЭМ-элементов и модификаторов (для псевдоселекторов и псевдоэлементов — без ограничений). Подробнее — см. Как работать с CSS-препроцессорами и БЭМ.

Примеси

Набор правил, который можно использовать многократно.

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

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

Условия

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

Циклы

@for , @while , @each . Удобны при использовании типов данных, напоминающих массивы (см. пример ниже в разделе о типах данных). Используются относительно редко.

Функции

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

В черновике CSS Color Module level 4 есть функции работы с цветом. Когда будут готовы для использования в реальных проектах — не ясно (вероятно, когда IE умрёт). Сейчас (осень 2018) поддержи нет никакой.

Можно добавлять свои функции, с rem и пикселями.

Позволяют дописать любую дополнительную логику. Используются относительно редко.

Расширения (экстенды)

Вредная и неочевидная возможность расширять одни селекторы другими. Используется редко. Не используйте это.

Типы данных

Помимо чисел и строк, во многих препроцессорах есть и составные типы данных (массивы).

Удобны при работе с наборами свойств, которые можно перебирать в цикле (цвета, брейкпоинты). Используются относительно редко.

Предупреждения

Не пытайтесь программировать на CSS-препроцессорах. Особенно, если не умеете программировать! В больших возможностях — большая сила и большая опасность выстрелить себе в ногу. См. Как работать с CSS-препроцессорами и БЭМ.

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

Итого: преимущества CSS-препроцессоров

  • Ускоряют работу.
  • Облегчают модификацию проекта.
  • Упрощают компонентный подход.

Итого: недостатки CSS-препроцессоров

  • Требуют знание языка, весьма похожего на CSS.
  • Требуют компиляции (дополнительного ПО).

Выводы

  1. В реальной жизни сверстать что-то без процессинга стилей (используя только CSS) можно, но это будут проекты уровня «Сайт моего хомячка». Изучайте CSS-препроцессоры.
  2. Изучайте новые возможности CSS. Они классные.
  3. CSS-препроцессоры — не конкурирующая с CSS технология, но дополняющая её.

Вышесказанное относится (в основном) к проектам, на которых не используются фронтенд-фреймворки. Однако их всё больше и с ними приходят замечательные возможности добавления стилей к нашим DOM-элементам — CSS modules, CSS-in-JS. «На подходе» и веб-компоненты как стек технологий, поддерживаемых браузерами (полная изоляция компонента и пр. плюшки). Подходы часто комбинируются.

Преимущества использования препроцессора (Sass) при написании CSS

CSS

В сети ведётся много споров о том, стоит ли использовать CSS-препроцессор в разработке. По моему личному мнению, препроцессор излишен для маленьких веб-проектов и приложений.

Тем не менее, по мере разрастания проекта поддержка и читаемость CSS становится всё труднее. Разработчики тратят больше времени при работе с тысячами строк CSS-правил, из-за чего повышается стоимость проекта. Поскольку проект становится больше, CSS вызывает некоторые проблемы, такие как:

  • Большие усилия для внесения небольших изменений
  • Трудности при структурировании кода
  • Избыточность кода
  • Бесконечные строки CSS-классов и правил

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

Что такое CSS-препроцессор?

Это программа/инструмент, имеющая свой собственный синтаксис, который затем компилируется в стандартный CSS-код.

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

Существуют различные препроцессоры, такие как Sass, Less и Stylus. В этой статье я расскажу о некоторых преимуществах Sass.

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

FAQ: Sass или SCSS

Это часто задаваемый вопрос. На самом деле, они оба являются Sass-препроцессором, просто имеют разный синтаксис. Проще говоря, SCSS — это новый синтаксис Sass 3 версии.

Пример синтаксиса Sass:

Пример синтаксиса SCSS:

Как мы можем видеть, SCSS (Sassy CSS) имеет CSS-подобный синтаксис, который намного легче читается. Он является расширением CSS, в то время как синтаксис Sass имеет более существенные отличия. Они также имеют разное расширение файла: .sass и .scss .

Подробнее об этом можно прочитать здесь. А теперь давайте перейдем к особенностям Sass.

Особенность #1: Переменные

В одном проекте разные CSS-классы могут содержать одинаковое правило или группу правил. Например, на странице у нас есть 20 блоков с разным цветом фона:

Позже наш клиент передумал и захотел блоки большего размера. Поэтому мне нужно поменять значения свойств width and height один за другим для каждого класса. А классов может быть и 50. В реальном программировании это может занять много времени. Как я уже упоминал выше, это пример больших усилий для небольших изменений.

Как можно сделать это более эффективно?

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

Возвращаясь к примеру выше, можно задать переменные для свойств width и height :

Если в дальнейшем нужно будет внести изменения, мы должны будем поменять значения всего лишь один раз:

CSS теперь также поддерживает переменные, но они не работают в IE и старых версиях других браузеров:

Особенность #2: Вложенность

Стандартный CSS не поддерживает вложенность. Мы не можем написать класс внутри другого класса. С ростом проекта это приводит к проблемам с читаемостью. Структура также выглядит не очень хорошо.

Например, создадим ниже в HTML навигационное меню с гиперссылками:

HTML поддерживает вложенный код. Но CSS без вложенности будет выглядеть так:

Нам приходится добавлять класс nav для каждого тега, даже для псевдокласса hover, потому что nav является родительским тегом для всех элементов. Однако, Sass поддерживает вложенность:

Используя Sass, мы можем писать более структурированный код, как в HTML. Больше не нужно добавлять nav для каждого класса, что также предотвращает избыточность кода.

Важно: не рекомендуется допускать более 3 уровнейвложенности.

Особенность #3: Mixins (миксины)

Выше мы узнали, как применять переменные для CSS-правил. Но что, если нам нужно использовать несколько правил вместе? Для этих целей у Sass есть миксины.

Что такое миксин?

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

Миксин создается с помощью команды @ mixin и названия миксина:

Также можно создать миксин в виде функции и добавлять к ней параметры:

После создания миксина мы можем воспользоваться им в любом классе при помощи команды @ include. Таким образом, мы можем подключить миксин my-font вместо того, чтобы каждый раз писать 4 строки правил для шрифта. Такой подход упрощает код.

Использование миксинов — это хороший способ предотвратить избыточность кода.

Особенность #4: Импорт

Наконец, мы можем разбить наши огромные CSS-файлы на более мелкие с помощью Sass-функции импорта. Гораздо проще читать и поддерживать маленькие файлы, а не один большой файл с бесконечными строками.

Вообще, CSS сейчас тоже имеет функцию импорта. Но там это работает по-другому. Чтобы импортировать файл, CSS каждый раз посылает HTTP-запрос к серверу. Sass делает это без HTTP-запросов, а значит процесс происходит быстрее.

Всё, что требуется сделать — это импортировать один Sass-файл в другой, используя команду @ import:

При указании пути к файлу не нужно добавлять расширение .scss, Sass найдет его и без этого.

Разбираемся в отличиях препроцессоров CSS

Как ты помнишь, на заре интернета визуальное представление документов целиком ложилось на плечи браузеров, которые использовали свои собственные встроенные стили для отображения различных HTML-тегов. Поскольку никакими стандартами на тот момент оформление не регламентировалось, производители браузеров в борьбе за неокрепшие умы пользователей украшали странички как могли, и в результате один и тот же документ мог разительно отличаться по внешнему виду в зависимости от ОС и браузера, в котором он отображался.

Глядя на эту дикую вольницу, норвежский ученый-информатик Хокон Виум Ли в 1994 году предложил производителям браузеров концепцию каскадных таблиц стилей, призванную отделить оформление от структуры веб-страницы и целиком отдать его на откуп веб-разработчиков. Идея приглянулась свежесобранному консорциуму W3C, и после двух лет прений и согласований спецификация CSS 1.1 была выброшена прямо на поле боя разгоравшейся войны браузеров. В дальнейшем спецификация CSS пережила еще два мажорных релиза, обзавелась огромной кучей новых свойств и умений, но концептуально недалеко ушла от изначальных редакций: задание стилей, как и раньше, сводилось к монотонному перечислению свойств для каждого элемента индивидуально, браузеры исправно поставляли уникальные префиксозависимые фичи. К тому же отсутствовали единые рекомендации по группировке (или сортировке) CSS-свойств внутри блоков, что, в свою очередь, порождало многочисленные холивары.

В таком виде CSS вступил в конец двухтысячных, своеобразный ренессанс фронтенд-разработки. CSS-разметка все чаще стала ложиться на плечи профильных фронтенд-разработчиков, которые быстро обнаружили, что в текущем виде CSS сложно поддается структуризации и автоматической генерации и не предоставляет никаких возможностей для гибкой и динамической работы со стилями элементов. Грядущий CSS3 обещал немного скрасить ситуацию, предложив некоторые новые селекторы и встроенные средства для работы с анимацией, но необходимость в префиксах и отслеживании поддержки браузерами новых фич делала процесс еще более утомительным. В результате неуемный энтузиазм Ruby- и JavaScript-разработчиков вылился в создание нескольких «семейств» CSS-препроцессоров, а также целых фреймворков на их основе.

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

В настоящее время многие из этих приемов понемногу переносятся в спецификации самого CSS (например, calc() уже поддерживается большинством современных браузеров, в ближайшем будущем в CSS ожидаются миксины, переменные, задаваемые с помощью @var, и многие другие вкусняшки), но неторопливость W3C никуда не делась, а препроцессоры все это обеспечивают уже сейчас и обеспечивают прекрасную кросс-браузерность получаемых на выходе стилей.

Препроцессор Sass начал свой путь в 2007 году как часть HTML-шаблонизатора Haml для Ruby on Rails. Вдохнув в CSS-разметку новую жизнь, он быстро завоевал симпатии рубистов, несмотря на отсутствие каких-либо средств отладки и необходимость привыкать к нестандартному «своему» синтаксису. В ранних версиях создатели Sass Хэмптон Кэтлин и Натан Вайценбаум вместе с примкнувшим к ним впоследствии Крисом Эпштейном заложили в него многое из того джентльменского набора, что сегодня в том или ином виде сопровождает все CSS-препроцессоры: переменные, вычисления, вложенные селекторы и миксины (в ранних версиях, правда, статические, и не позволяющие подстановку аргументов). По мере взросления функциональность Sass существенно расширялась и дополнялась.

Переменные

То, чего сильно не хватало оригинальному CSS, — переменные в Sass записываются с помощью символа $ и позволяют хранить строки, цвета, булевы значения и даже целые списки свойств:

Строго говоря, переменные в Sass скорее являются константами: после присвоения значение переменной изменить нельзя. Подставлять переменные можно в любые свойства, также их можно использовать в вычислениях и некоторых интересных встроенных функциях Sass. Например, для работы с цветом есть отличные darken() и lighten():

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

Вложенность

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

мы можем записать все гораздо компактнее и проще:

Главное — не поддаваться на провокацию легкости описания и не забывать, что излишней вложенностью CSS-селекторов можно ощутимо затормозить парсинг CSS в браузере.

Импорт

Еще одним долгожданным нововведением в Sass стал импорт файлов. Организован импорт очень просто: имя подключаемого файла (в идеологии Sass такие файлы называются partials) должно начинаться с нижнего подчеркивания, а для его включения в основном файле нужно вызвать директиву @include и указать относительный путь к подключаемому файлу. При этом нижнее подчеркивание и расширение файла можно опустить.

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

Вычисления и миксины

Миксины в Sass — главный генератор восторга и слез умиления у суровых бородатых кодеров. Представляя собой некоторое подобие функций, присущих «большим» языкам программирования, миксины позволяют использовать принцип DRY на полную катушку: описывать заранее наборы CSS-правил и подставлять их в любое место легким движением руки:

На выходе получим вот такой CSS:

А ведь Sass еще и поддерживает разнообразные вычислительные и логические операции с известными ему типами данных: например, с размерами ( height: ($size + 40px) / 2 ) или цветами ( $base-color — #404040 )!

При некоторой сноровке и уйме свободного времени на Sass можно реализовать, например,пузырьковую сортировку. Красиво, бесполезно, работает.

Говоря о Sass, нельзя не упомянуть, что на его основе было создано немало библиотек и целых фреймворков, особое место среди которых занимает Compass, разработанный одним из соавторов Sass Крисом Эпштейном. Compass предоставляет в твое распоряжение отличную подборку CSS3-миксинов (да-да, можно окончательно забыть про все проблемы с префиксами), актуальный reset всех встроенных браузерных стилей, средства для создания различных grid’ов и layout’ов. Чтобы не показалось мало, Compass также обеспечивает разработчика внушительным количеством всяческих утилит и хелперов: средствами для работы с типографикой и шрифтами, расширенной математикой и тригонометрией и многим другим.

В ответ на твит небезызвестной в мире CSS Лии Веру о поисках браузерного компилятора Sass, реализация libsass для C была портирована на JavaScript при помощи emscripten. Теперь при помощи получившейся либы Sass.js Sass и SCSS можно исполнять прямо в браузере!

В 2009 году Алексис Селье представляет миру новый инструмент для более гибкой работы со стилями под названием Less. Первая реализация была разработана Алексисом на Ruby, и это означало, что у Sass появился конкурент.

В это время Node.js начал набирать обороты. Алексис, чувствуя тенденцию, решает переписать Less на JavaScript и преподносит подарок на День защитника Отечества в видеinitial-коммита.

Less довольно быстро начал обретать популярность, Twitter заюзал его в своем фреймворке Bootstrap, звездочки и форки в GitHub росли. По данным опроса сайта css-tricks.com в 2012 году, 51% из всех, кто пользуется препроцессорами, отдают свое предпочтение Less, Sass + SCSS — 41%, Stylus — 6%, другим — 2%.

Он не испытывает проблем с подсветкой синтаксиса в различных редакторах, также нет проблем и со встраиванием во всевозможные сборщики, начиная Grunt и заканчивая ENB. Нет проблем и c GUI-приложениями для сборки на разных платформах: Mac, Windows и других.

В мае 2012 года Алексис передает контроль над разработкой и развитием проекта команде, и, на мой взгляд, это скорее плюс, чем минус, так как спустя месяц после принятия этого решения активность разработки над проектом возросла. Ребята даже сделали новый сайт, который хорошо и понятно структурирован, как, впрочем, и документация.

Теперь Less может работать как на сервере под Node.js или Rhino, так и на клиенте. Отмечу, что с кросс-браузерностью особых проблем не наблюдалось, он нормально заводился и работал даже в IE6. Поэтому некоторые ленивые разработчики использовали его на клиенте без особых плясок с бубном: подключил JS-файл и пиши себе спокойно, не нужно поднимать Node.js, настраивать вотчеры, решать иные проблемы (что с производительностью у такого подхода, тебе, думаю, очевидно :)).

Основные возможности и фичи

Активность — это хорошо, а какие плоды этой активности появились в самом препроцессоре? Что, например, предлагает Less для работы с CSS3? Градиенты, анимации, скругления, трансформации, транзишены в суровых реалиях вендорных префиксов добавляют немало работы. А какие-нибудь хелперы для рутинных задач, например перевод изображений в Base64 или автосборка спрайтов?

Перед тем как я расскажу, что есть из фич, хочется кратко озвучить основные возможности Less.

Переменные

Переменные — они и в Африке переменные. Удобно использовать для объявления имени основных шрифтов, цветов.

Миксины

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

Удобно использовать для создания своих «функций».

Расширение

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

Импорт

Подключает внешние валидные файлы Less, CSS

Гуарды (guards)

Позволяют декларировать условие, по которому меняется результат выполнения правила для селектора.

Мердж

Соединение в одно свойство двух свойств.

Вложенность правил, конкатенация

Простой пример использования, вариации можно посмотреть в разделе Parent Selectors.

Теперь снова можно вернутьcя к фичам. Так вот, на последние два вопроса ответ простой — перевод изображений в Base64 появился в версии 1.4, я в свое время активно работал с версией 1.3, и этой фичи чертовски не хватало, а вот автосборки спрайтов из коробки нет.

Библиотеки

Что касается упрощения работы с CSS3, то тут на помощь приходит 3rd party библиотекаLESS Hat — лучшее, что сейчас есть для этих целей. Она покрывает большинство кейсов, которые возникают при работе с CSS3, позволяет гибко передавать параметры в миксины и делает всю работу за тебя.

Устроена по схожему принципу с LESS Elements. Правда, сходство только в том, что это тоже набор миксинов; таких проблем, как при использовании LESS Elements, не возникает. Решим ту же задачу:

Так в чем же хитрость LESS Hat? Как они реализовали гибкость вызовов миксинов? Все просто. В Less мы можем исполнять JavaScript в процессе обработки стилей, и авторы библиотеки парсят входные данные в миксин и преобразуют их в нужный вид.

Кстати, миксины библиотеки не пишутся руками, а описываются в JS-файлах в определенном формате. Сами Less-миксины создаются на основе этих файлов с помощью сборки Grunt.

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

Заключение

В общем и целом Less — хороший инструмент; в свое время он страдал от недостатка внимания со стороны разработчиков, и ему не хватало библиотеки для работы с CSS3. Сейчас эти проблемы отходят на задний план, и пару Less + LESS Hat можно рассматривать как один из кандидатов в стеке технологий фронтенд-разработчика.

Stylus

Первый релиз Stylus состоялся 31 января 2011 года, и практически следом за ним зарелизилась библиотека Nib, упрощающая работу с CSS3 и решающая проблему контроля вендорных префиксов.

Автором Stylus и, что немаловажно, Nib является небезызвестный TJ Holowaychuk, который описывает Stylus как революционно новый язык. Неясно, правда, что именно в нем революционного: по возможностям он примерно на одном уровне с Sass и Less.

Stylus было не так сложно отвоевать свою часть рынка, так как многие разработчики были знакомы с хорошо зарекомендовавшими себя проектами TJ Holowaychuk (Express, Jade, Mocha). Также немалую роль сыграло то, что в комплекте шел Nib. Приобретенная популярность сыграла свою роль, и вот уже многие IDE поддерживают синтаксис Stylus, системы сборки знают, как и чем собирать его, для Connect написан middleware для исполнения в runtime.

В проекте на текущий момент 113 контрибьютеров, которые активно пилят, в том числе есть разработчики из России, ребята из Яндекс.Почты (кстати, в Почте используется Stylus).

Да, у Stylus определенно есть свои плюсы, он изначально разрабатывался на JavaScript, есть возможность использовать несколько синтаксисов: индентный Ruby-стайл и классический CSS. Также можно отнести к плюсам, что у препроцессора и библиотеки один автор, который явно понимал ее важность и необходимость.

Основные возможности и фичи

У Stylus есть пара примечательных отличий от его коллег по цеху. Первая из них — это возможность получать значения свойств в контексте одного правила:

Вторая — это неявный вызов миксинов, что добавляет синтаксису Stylus элегантность и читаемость. Хотя, с другой стороны, из-за этой фичи может пострадать понимание кода, смотри пример, и сам все поймешь:

В остальном Stylus похож на своих конкурентов. Он так же, как и Less, может выполняться в браузере, может переводить изображения в Base64, так же, как и у Sass, есть автосборка спрайтов (3rd party), имеет схожие базовые возможности: переменные, миксины, расширение, импорт, ветвление, вложенность правил, конкатенация (кстати, у Sass этой возможности нет).

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

Библиотеки

У Stylus есть флагманская библиотека, о которой я уже не раз говорил, — это Nib, но можно посмотреть и на милые альтернативы Dookie и Roots Axis.

Nib — помимо средств нормализации работы с CSS3 (gradients, box-shadow, transform, transition, animation. ) есть еще и утилиты обнуления свойств дефолтных стилей браузера (с возможностью обнулять свойства по группам, например font, использовать clearfix и другое). Все наборы разбиты по группам, что дает возможность подключать конкретно то, что нужно.

Dookie — набор полезных миксинов, призванных избавить тебя от рутинной работы с CSS3 и не только. В составе есть: reset, normalize, CSS3, странный сахар.

Roots Axis является частью более крупного тулкита лучших решений. По возможностям похож на Dookie, тоже имеет свой странный сахар, но еще есть более странное решение под названием buttons (стили для кнопок) и ui (стили для блоков нотификаций).

Заключение

Stylus — гибкий препроцессор, с активным сообществом, мощными библиотеками и с большим количеством 3rd party решений. У него светлое будущее, скорее даже уже светлое настоящее. Определенно лидер в гонке препроцессоров.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *