Frontender Magazine

Почему Sass?

Примечание от редакторов A List Apart: Мы рады представить на ваше обозрение отрывок из книги Sass для веб-дизайнеров Дэна Седерхолма (Dan Cederholm), которая теперь доступна для покупки на сайте A Book Apart.

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

Примерно так я думал совсем недавно. Но, правда в том, что Sass, как и другие препроцессоры CSS, может стать вашим самым мощным союзником. Это инструмент, который легко может войти в повседневную работу любого мастера стилизации. Мне потребовалось много времени, чтобы поменять своё мнение, но я, без сомнения рад, что это случилось.

Именно эти перемены и послужили моей мотивацией для написания данной книги. Мне хотелось поделиться с сообществом, как с помощью Sass мне удалось сделать мою работу более продуктивной, придерживаясь при этом обычной манеры написания CSS, к которой я давно привык за последние десять лет. Поначалу, обилие моих заблуждений не давало мне решиться попробовать Sass. Я боялся, что мне придётся полностью поменять свой подход к написанию и управлению таблицами стилей. Поскольку, порой, код CSS может быть очень чувствительным к изменениям, довольно легко понять, почему некоторые разработчики так бережно относятся к своим творениям. Ну, вы понимаете, о чем я.

Окей, тогда идем дальше.

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

В двух словах о Sass

Наверняка вы сталкивались с ситуацией, когда, скажем, нужно поменять цвет в таблице стилей, и обнаруживалось, что для этого необходимо искать и менять значение несколько раз в разных местах таблицы? Разве вам не хотелось бы, что бы в СSS этот процесс был более простым?

       $brand-color: #fc3;
a {
color: $brand-color;
}
nav {
         background-color: $brand-color;
}

А что, если бы можно было изменить нужное значение один раз, и это изменение применилось бы сразу по всей таблице стилей? Это и позволяет делать Sass!

А что насчёт повторяющихся стилевых блоков, которые используются в различных частях таблицы?

p {
margin-bottom: 20px; font-size: 14px; line-height: 1.5;
}
footer {
         margin-bottom: 20px;
         font-size: 14px;
         line-height: 1.5;
}

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

     @mixin default-type {
     margin-bottom: 20px;
     font-size: 14px;
     line-height: 1.5;
}
p {
@include default-type;
}
footer {
     @include default-type;
}

И это тоже Sass! Эти два абсолютно простых примера лишь слегка приоткрывают тайну того, как Sass позволяет сделать разработку таблиц стилей более быстрой, лёгкой и гибкой. Это столь долгожданный помощник в мире веб-дизайна, ведь все, кому приходилось работать над созданием сайта, знают, что на самом деле…

CSS — это сложный язык

Признаемся честно — выучить CSS не просто. Нужно понять, за что отвечает каждое свойство, как работает каскад, какие возможности поддерживает тот или иной браузер, разобраться с селекторами, различными нюансами, и так далее. Это не простая задача. Добавьте к этому ещё и уровень сложности интерфейсов, над которыми мы теперь работаем, а также дальнейшую необходимость их поддержки в рабочем состоянии. Может возникнуть резонный вопрос — почему же мы вообще этим занимаемся? Перед нами стоят трудные задачи, и просто напросто некоторым из нас нравится находить для них решения.

Трудности ещё частично усугублены и тем, что изначально CSS не был задуман для решения тех вопросов, для которых мы его используем сейчас. Безусловно, прогресс стремительно движется вперед, в том числе благодаря быстрому усовершенствованию технологии в браузерах, внедрению инноваций в CSS3 и так далее. Однако, нам всё ещё приходится полагаться на приёмы, которые, в сущности, являются хаками. Например, свойство float было придумано всего лишь для выравнивания изображения относительно текстового блока. Это факт. Пока мы не додумались на основе одного лишь этого свойства построить целую концепцию современных интерфейсов.

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

По мере усложнения интерфейсов и повышения их функциональности, мы придумываем для компонентов CSS новое, более изощренное применение, о котором бы его авторы и подумать не смели. Что и говорить, мы столь изобретательны. К счастью, сегодня разработчики браузеров уже намного быстрее вводят в реализацию новые возможности CSS. С каждым днем становятся доступны всё более могущественные свойства и селекторы, позволяющие более эффективно решать проблемы, которые ставит перед нами современный веб. Появляются такие нововведения, как новые средства для позиционирования в CSS3, border-radius, box-shadow, новые селекторы, переходы, трансформации, анимации и прочее. Мы живём в интересное время. И тем не менее, пока ещё многого CSS не хватает. Есть много пробелов, которые нужно заполнить, и тогда жизнь фронтенд-разработчика станет намного проще.

Принцип DRY

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

Возможно, вы уже что-то слышали о принципе «DRY» («don’t repeat yourself», не повторяйся). Этот принцип, который был впервые введён и описан Енди Хантом (Andy Hunt) и Дейвом Томасом (Dave Thomas) в книге «Программист-прагматик», несёт следующую мысль:

Каждый фрагмент знаний должен иметь единственное однозначное официальное представление в системе.

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

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

«Как вы !@#$Ь вообще умудряетесь поддерживать это в рабочем состоянии?!» — спросит он.

«А, кстати, я не говорил тебе нюансах работы в IE?» — ответите вы с толикой отвращения к самому себе.

Так почему же с CSS работать так трудно?

Немного света на то, почему уже так много лет у CSS столь ограничен синтаксис, проливает очерк одного из соавторов CSS, Берта Боса (Bert Bos):

Мы не решились добавить в CSS такие мощные возможности, как макрокоманды, переменные, символьные константы, условные конструкции, и др., используемые программистами в большинстве языков. Причина состоит в том, что хоть эти компоненты и открывают перед продвинутыми пользователями огромные возможности, однако менее опытных пользователей они могут полностью сбить с толку. Или даже вовсе, что более вероятно, напугать настолько, что те и близко не подойдут к CSS. Тут дело в балансе. И когда речь идёт о CSS, баланс для нас — это нечто иное, чем для остальных языков.

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

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

Что же такое Sass?

Sass (сокр. от «Syntactically Awesome Stylesheets», Синтаксически совершенные стилевые таблицы) — это препроцессор, промежуточное звено между таблицами стилей, которые вы пишите, и самими .css файлами, которые отправляются в браузер. Он заполняет пробелы в языке CSS, позволяя писать более быстрый, более продуктивный и более простой в поддержке код, полностью соблюдая принцип DRY.

Вот как описывают Sass на вебсайте его разработчики:

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

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

Если быть более точным, то Sass является расширением CSS3, а именно, его синтаксиса SCSS («Sassy CSS», стильный CSS), о котором мы поговорим несколько позже, и представляет собой расширенную версию CSS3. Это значит, что любой валидный документ CSS3 является также валидным документом SCSS. Вот оно, неотъемлемое свойство Sass, позволяющее в нём быстро разобраться. Начать использовать синтаксис Sass можно без особых усилий в удобном для вас объёме. Это значит также, что конвертировать уже существующие таблицы стилей из CSS в SCSS можно также поэтапно, по мере изучения и освоения новых возможностей Sass.

Вы сами почувствуете позже, когда вы полностью освоите Sass, а это не займёт много времени, что он сам по себе воспринимается как естественное расширение CSS. Он просто заполняет пробелы спецификации, которые вам давно хотелось бы видеть в самом CSS. Именно поэтому, когда я начал использовать Sass, мне в голову ни разу не приходила мысль о том, что он неудобен, или требует каких-то дополнительных усилий. Мне он кажется настолько же простым, как и CSS. Стоит вам его попробовать, и скорее всего, вы уже не сможете отказаться от его применения.

Более того, Sass помогает улучшить CSS. Предусматривая применение некоторых скоростных методов, которые пока невозможны без препроцессоров, он даёт разработчикам CSS живую реализацию и поле для экспериментов. Позже, если это будет целесообразно, некоторые возможности Sass могут оказать влияние на будущие спецификации CSS.

Заблуждения насчёт Sass

Ранее я упоминал о том, что я долго не решался попробовать Sass. Отчасти причиной этому было множество сомнений и вопросов, овладевшие мной. Нужно ли мне знать Ruby или продвинутые тонкости командной строки? Не придётся ли мне полностью изменить свой подход к написанию таблиц стилей? И не будет ли конечный CSS раздутым и нечитаемым?

К счастью, ответ на каждый из этих вопросов — утвердительное «нет». Однако, я постоянно слышу их в различных интернет-источниках, как только речь заходит Sass. Давайте же проясним некоторые моменты.

Я боюсь командной строки!

Я никоим образом не являюсь экспертом по использованию командной строки, просто за несколько лет я кое-чему научился. Если честно, то моих знаний как раз хватит на то, чтобы заработать неприятности на свою голову. Максимум, что я могу с помощью консоли — это перемещаться по файловой системе, использовать Git команды и ну и всё в таком духе.

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

Подведём итог: если вы всеми силами избегаете командной строки, это не должно помешать вам попробовать Sass!

Я не хочу менять свой подход к написанию CSS!

Вот от этого заблуждения я страдал больше всего. Для меня огромное значение имеет то, как происходит создание и упорядочение таблиц стилей. Это своего рода искусство. Однако, не забывайте, что поскольку синтаксис SCSS является просто расширенной версией CSS3, вам ничего не нужно менять в своём подходе к написанию CSS. Все ваши привычки по комментированию, отступам, или же их отсутствию, форматированию в общем, могут оставаться теми же, что и при работе с файлами .scss. Когда я это понял, я смог без страха погрузиться в Sass.

Я не хочу, чтобы Sass влиял на то, как я прописываю стили!

С другой стороны, Sass не решит все ваши проблемы, и не избавит вас от плохих привычек. Нерациональные, раздутые таблицы стилей такими же и останутся, даже при использовании Sass. Хорошая организация и рассудительность здесь так же в почете. Собственно, Sass может даже усугубить последствия применения плохих подходов, об этом мы также поговорим. Однако при правильном и разумном использовании, Sass может существенно помочь в создании сайтов.

Вот так. Теперь когда мы разобрались с мелочами, давайте перейдём к самому интересному. Думаю вы будете удивлены возможностями Sass. В следующем разделе мы поговорим о том, как настроить работу с Sass — о том, как он может вписаться в ваш рабочий процесс и насколько просто использовать командную строку и приложения. Время для Sass, ребята.

Если вы заметили ошибку, вы всегда можете отредактировать статью, создать issue или просто написать об этом Антону Немцеву в skype ravencry.

Dan Cederholm
Автор:
Dan Cederholm
GitHub:
simplebits
Twitter:
@simplebits
Сaйт:
http://simplebits.com/
Наталья Фадеева
Переводчик:
Наталья Фадеева
вКонтакте:
natatik_l
Twitter:
@very_busy_girl
GitHub:
NatalieF

Комментарии (9 комментариев, если быть точным)

Автар пользователя
pvpshoot

не так давно начал использовать SASS, просто хотел попробовать. теперь пишу на нем, учу ребят в отделе. Самым приятным для меня оказалась вложенность, которая просто вынуждает выглядеть документ читаемым. Все эти миксины и переменные восхитительны. А верный друг compass мне помогает =)

Автар пользователя
denisisaychx

Спасибо за информацию. =) Ещё бы статью «Почему Stylus?». =)

Автар пользователя
zjoin

Уже больше 3 месяцев была в web standards

Автар пользователя
SilentImp

@pvpshoot попробуй stylus+autoprefixer+coffee+slim|haml|etc+gulp Оно все вкусное. Stylus вкуснее sass.

Автар пользователя
SilentImp

@zjoin у нас её начали переводить сразу после выхода. Вот и так вот бывает. Теперь у тех, кто её еще не прочел есть возможность выбрать тот, который им больше по душе. Ссылочка на статью, собственно: Почему Sass?

Автар пользователя
MrFranke

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

Автар пользователя
P3trovichUA

SASS намного мощнее LESS, по крайней мере большинство авторов это говорят. У меня есть вопрос для тех, кто использеут SASS, есть ли там какой-то компилятор под Win. Ато из командной строчки мне как фронтендщику не очень…

Автар пользователя
MrFranke

SASS действительно мощнее, но я еще ни разу не сталкивался с проектом, на котором не хватало бы фишек LESS. А консоль необходима любому разработчику frontend или backend не важно)

Автар пользователя
SergeyAlexeev

А в чем конкретно SASS мощнее LESS'а?