Это обновленная версия статьи, первоначально опубликованной 28 апреля 2014 года.
Я много писал о Sass, но некоторые комментарии, которые я получил, дали понять, что не все точно знают, на что ссылается Sass. Вот немного ясности:
Когда мы говорим о Sass , мы обычно имеем в виду препроцессор и язык в целом. Мы скажем, например, «мы используем Sass» или «вот миксин Sass». Между тем, Sass (препроцессор) допускает два разных синтаксиса:
- Sass , также известный как синтаксис с отступом
- SCSS , CSS-подобный синтаксис
История Sass
Первоначально Sass был частью другого препроцессора под названием Haml , разработанного и написанного разработчиками Ruby. Из-за этого в таблицах стилей Sass использовался Ruby-подобный синтаксис без скобок, точек с запятой и строгого отступа, например:
// Variable !primary-color= hotpink // Mixin =border-radius(!radius) -webkit-border-radius= !radius -moz-border-radius= !radius border-radius= !radius .my-element color= !primary-color width= 100% overflow= hidden .my-other-element +border-radius(5px) Как вы можете видеть, это довольно значительное изменение по сравнению с обычным CSS! Даже если вы являетесь пользователем Sass (препроцессора), вы можете видеть, что это сильно отличается от того, к чему мы привыкли. Знак переменной есть ! а не $ , знак присваивания = а не : Довольно странно.
Но так выглядел Sass до тех пор, пока в мае 2010 года не появилась версия 3.0, в которой был введен новый синтаксис SCSS для Sassy CSS . Этот синтаксис нацелен на сокращение разрыва между Sass и CSS за счет использования удобного для CSS синтаксиса.
// Variable $primary-color: hotpink; // Mixin @mixin border-radius($radius) { -webkit-border-radius: $radius; -moz-border-radius: $radius; border-radius: $radius; } .my-element { color: $primary-color; width: 100%; overflow: hidden; } .my-other-element { @include border-radius(5px); }
SCSS определенно ближе к CSS, чем Sass. При этом сопровождающие Sass также работали над тем, чтобы сделать оба синтаксиса ближе друг к другу, перемещаясь ! (знак переменной) и = (знак присваивания) из отступного синтаксиса в $ и : из SCSS.
Теперь, когда вы начинаете новый проект, вы можете спросить, какой синтаксис вам следует использовать. Позвольте мне осветить путь и объяснить плюсы и минусы каждого синтаксиса.
Плюсы для Sass Indented Syntax
Хотя этот синтаксис может выглядеть странно, у него есть несколько интересных моментов. Прежде всего, он короче и проще для ввода . Нет больше скобок и точек с запятой, вам не нужны все эти вещи. Даже лучше! Нет необходимости в @mixin или @include , когда достаточно одного символа: = и + .
Также синтаксис Sass обеспечивает чистые стандарты кодирования , полагаясь на отступы. Поскольку неправильный отступ может нарушить всю .sass стилей .sass , он гарантирует, что код .sass будет чистым и хорошо отформатированным. Есть один способ написания кода Sass: хороший способ.
Но будьте осторожны! Отступ означает что-то в Sass. Отступ в селекторе означает, что он вложен в предыдущий селектор. Например:
.element-a color: hotpink .element-b float: left
… Выведет следующий CSS:
.element-a { color: hotpink; } .element-a .element-b { float: left; }
Простой факт .element-b один уровень вправо означает, что он является потомком .element-a , изменяя полученный CSS. Будьте очень осторожны со своими отступами!
Как и в сторону, я чувствую, как синтаксис отступа на основе, скорее всего, подойдет команда Рубин / Python более чем команда PHP / Java (хотя это спорно, и я хотел бы услышать мнения об обратном).
Преимущества синтаксиса SCSS
Для начала, он полностью совместим с CSS . Это означает, что вы можете переименовать файл CSS в .scss и он будет просто работать . Обеспечение полной совместимости SCSS с CSS всегда было приоритетом для разработчиков Sass с момента выпуска SCSS, и, на мой взгляд, это большое дело. Более того, они стараются как можно ближе придерживаться того, что может стать допустимым синтаксисом CSS в будущем (отсюда и @directives ).
Поскольку SCSS совместим с CSS, это означает, что практически нет кривой обучения . Синтаксис уже известен: в конце концов, это просто CSS с несколькими дополнениями. Это важно при работе с неопытными разработчиками: они смогут быстро начать кодирование, не зная в первую очередь о Sass.
Более того, его легче читать, потому что это действительно имеет смысл. Когда вы читаете @mixin , вы знаете, что это объявление mixin; когда вы видите @include , вы вызываете миксин. Это не делает никаких ярлыков, и все имеет смысл, когда зачитывается вслух.
Кроме того, большинство существующих инструментов, плагинов и демоверсий для Sass разработаны с использованием синтаксиса SCSS. Со временем этот синтаксис приобретает первостепенное значение и становится выбором по умолчанию, в основном по указанным выше причинам.
Последние мысли
Выбор за вами, но если у вас нет действительно веских причин для кодирования с использованием отступного синтаксиса, я настоятельно рекомендую использовать SCSS поверх Sass. Это не только проще, но и удобнее.
Однажды я сам попробовал использовать синтаксис с отступом, и он мне понравился. Мне понравилось, насколько это было коротко и легко. На самом деле я собирался переместить всю кодовую базу в Sass на работе, прежде чем передумать в последнюю минуту. Я благодарю своего прошлого за то, что он остановил этот шаг, потому что было бы очень трудно работать с некоторыми из наших инструментов, если бы мы использовали отступный синтаксис.
Также обратите внимание, что Sass никогда не пишется в верхнем регистре, независимо от того, говорите ли вы о языке или синтаксисе. Между тем, SCSS всегда в верхнем регистре. Нужно напоминание? SassnotSASS.com на помощь!