Sass Guidelines

Синтаксис и форматирование

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

Когда несколько разработчиков участвуют в написании CSS проекта(ов), то лишь вопрос времени, когда один из них начнёт делать вещи по-своему. Руководство стилей способствуют не только в согласованности, но и помогает, когда приходит время читать и обновлять код.

Грубо говоря, мы хотим (бесстыдно вдохновлён CSS Guidelines):

• двойные (2) отступы пробелом, никаких табов;
• в идеале, 80-символьную ширину строк;
• правильно написанные многострочные CSS правила;
• осмысленное использование пробелов.

// Yep
.foo {
  display: block;
  overflow: hidden;
  padding: 0 1em;
}

// Nope
.foo {
    display: block; overflow: hidden;

    padding: 0 1em;
}

// Так как Sass использует отступозависивый синтаксис,
// то и не существует неправильного способа форматирования
.foo
  display: block
  overflow: hidden
  padding: 0 1em

Строки

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

Кодировка

Чтобы избежать потенциальных проблем с кодировкой символов, крайне рекомендуется использовать кодировку UTF-8 в основной таблице стилей, используя директиву @charset. Убедитесь, что она идёт первой строкой в таблице стилей и перед ней ничего нет.

@charset 'utf-8';

@charset 'utf-8'

Кавычки

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

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

Языки, которые не требуют, чтобы строки были в кавычках, определенно, в меньшинстве, так что строки должны всегда быть обёрнуты в одинарные кавычки в Sass (одну проще набрать, чем двойную, на QWERTY-клавиатуре). Кроме того, для согласованности с другими языками, в том числе с двоюродным братом CSS – JavaScript’ом, есть несколько причин для такого выбора:

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

// Yep
$direction: 'left';

// Nope
$direction: left;

// Yep
$direction: 'left'

// Nope
$direction: left

Строки как значения CSS

Специальные значения CSS (идентификаторы), такие как initial или sans-serif требует не быть закавыченными. В самом деле, объявление font-family: 'sans-serif' потерпит неудачу, потому что CSS ожидает идентификатор, а не строку с кавычками. Именно поэтому, мы не оборачиваем в кавычки эти значения.

// Yep
$font-type: sans-serif;

// Nope
$font-type: 'sans-serif';

// Okay I guess
$font-type: unquote('sans-serif');

// Yep
$font-type: sans-serif

// Nope
$font-type: 'sans-serif'

// Okay I guess
$font-type: unquote('sans-serif')

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

Первое без кавычек, а второе в одинарных кавычках.

Строки, содержащие кавычки

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

// Okay
@warn 'You can\'t do that.';

// Okay
@warn "You can't do that.";

// Okay
@warn 'You can\'t do that.'

// Okay
@warn "You can't do that."

УРЛы

URL тоже должны быть в кавычках, по тем же причинам, что и выше:

// Yep
.foo {
  background-image: url('/images/kittens.jpg');
}

// Nope
.foo {
  background-image: url(/images/kittens.jpg);
}

// Yep
.foo
  background-image: url('/images/kittens.jpg')

// Nope
.foo
  background-image: url(/images/kittens.jpg)

Числа

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

Нули

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

// Yep
.foo {
  padding: 2em;
  opacity: 0.5;
}

// Nope
.foo {
  padding: 2.0em;
  opacity: .5;
}

// Yep
.foo
  padding: 2em
  opacity: 0.5

// Nope
.foo
  padding: 2.0em
  opacity: .5

Единицы измерения

При работе с длинами, 0 (нуль) никогда не должен иметь единицу измерения.

// Yep
$length: 0;

// Nope
$length: 0em;

// Yep
$length: 0

// Nope
$length: 0em

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

Чтобы добавить единицу измерения в число, нужно умножить это число на 1 единицу измерения.

$value: 42;

// Yep
$length: $value * 1px;

// Nope
$length: $value + px;

$value: 42

// Yep
$length: $value * 1px

// Nope
$length: $value + px

Заметим, что прибавление 0 единиц этого значения также работает, но я скорее бы порекомендовал вышеупомянутый метод умножения, так как прибавление 0 единиц измерения может быть немного запутанным. Действительно, при попытке преобразовать число в другую единицу измерения, прибавление нуля не провернёт этот трюк. Подробнее в этой статье.

$value: 42 + 0px;
// -> 42px

$value: 1in + 0px;
// -> 1in

$value: 0px + 1in;
// -> 96px

$value: 42 + 0px
// -> 42px

$value: 1in + 0px
// -> 1in

$value: 0px + 1in
// -> 96px

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

Чтобы убрать единицу измерения из значения, нужно разделить его на одну единицу этой же меры.

$length: 42px;

// Yep
$value: $length / 1px;

// Nope
$value: str-slice($length + unquote(''), 1, 2);

$length: 42px

// Yep
$value: $length / 1px

// Nope
$value: str-slice($length + unquote(''), 1, 2)

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

Вычисления

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

// Yep
.foo {
  width: (100% / 3);
}

// Nope
.foo {
  width: 100% / 3;
}

// Yep
.foo
  width: (100% / 3)

// Nope
.foo
  width: 100% / 3

Магические числа

“Магическое число” - это термин старой школы программирования для неименованных числовых констант. В принципе, это просто случайное число, которое просто работает™ и ещё не привязано к какому-либо логическому объяснению.

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

/**
 * 1. Магическое число. Это минимальное число, которое я смог найти, чтобы выровнять верх
 * `.foo` с его предком. В идеале мы должны исправить это по-правильному.
 */
.foo {
  top: 0.327em; /* 1 */
}

/**
 * 1. Магическое число. Это минимальное число, которое я смог найти, чтобы выровнять верх
 * `.foo` с его предком. В идеале мы должны исправить это по-правильному.
 */
.foo
  top: 0.327em /* 1 */

По теме у CSS-Tricks есть потрясающая статья о магических числах в CSS, которую я призываю вас прочитать.

Цвета

Цвета занимают важное место в языке CSS. Естественно, Sass является ценным союзником, когда дело доходит до управления цветами, в основном – путём предоставления мощных функций.

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

• How to Programmatically Go From One Color to Another
• Using Sass to Build Color Palettes
• Dealing with Color Schemes in Sass

Цветовые форматы

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

1. Обозначение HSL;
2. Обозначение RGB;
3. Шестнадцатеричная нотация. Предпочтительно в нижнем регистре и по возможности укороченная.

Названия стандартных цветов CSS не следует использовать, разве что для быстрого прототипирования. Именно так, это английские слова и некоторые из них сослужат плохую службу для описания цвета, который они означают, особенно для тех, кому английский не родной язык. Кроме того, эти названия не очень-то сематичны; например grey в действительности темнее, чем darkgrey, и путаница между grey и gray может привести к мешанине при использовании этого цвета.

Представление HSL – не только самое простое для человеческого мозга ^{[указать источник]}, но у него и самый лёгкий способ настройки цвета путём регулировки цветового тона, насыщенности и яркости индивидуально.

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

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

// Yep
.foo {
  color: hsl(0, 100%, 50%);
}

// Also yep
.foo {
  color: rgb(255, 0, 0);
}

// Meh
.foo {
  color: #f00;
}

// Nope
.foo {
  color: #FF0000;
}

// Nope
.foo {
  color: red;
}

.foo
  color: hsl(0, 100%, 50%)

// Also yep
.foo
  color: rgb(255, 0, 0)

// Nope
.foo
  color: #f00

// Nope
.foo
  color: #FF0000

// Nope
.foo
  color: red

При использовании обозначений HSL или RGB, всегда пишите один пробел после запятой (,) и не ставьте пробел между скобками ((, )) и содержимым.

// Yep
.foo {
  color: rgba(0, 0, 0, 0.1);
  background: hsl(300, 100%, 100%);
}

// Nope
.foo {
  color: rgba(0,0,0,0.1);
  background: hsl( 300, 100%, 100% );
}

// Yep
.foo
  color: rgba(0, 0, 0, 0.1)
  background: hsl(300, 100%, 100%)

// Nope
.foo
  color: rgba(0,0,0,0.1)
  background: hsl( 300, 100%, 100% )

Цвета и переменные

При использовании цвета более одного раза, сохраняйте его в переменной с осмысленным названием, описывающим цвет.

$sass-pink: hsl(330, 50%, 60%);

$sass-pink: hsl(330, 50%, 60%)

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

$main-theme-color: $sass-pink;

$main-theme-color: $sass-pink

Так вы воспрепятствуете изменениям темы, ведущим к чему-то вроде $sass-pink: blue. Эта статья здорово объясняет, почему важно учитывать ваши цветовые переменные.

Осветление и затемнение цветов

Обе функции lighten и darken манипулируют цветами пространства HSL, добавляя или вычитая в пространстве HSL. В принципе, они ни что иное, как алиасы для параметра $lightness в функции adjust-color.

Дело в том, что эта функция часто не даёт ожидаемого результата. С другой стороны, функция mix является хорошим способом осветлить или затемнить цвет, смешивая его либо с white, либо с ` black`.

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

Если вы не хотите писать функцию mix каждый раз, вы можете создать две простых в использовании функции tint и shade (которые также являются частью Compass), чтобы сделать то же самое:

/// Немного осветлить цвет
/// @access public
/// @param {Color} $color - цвет для осветления
/// @param {Number} $percentage - процент от `$color` в возвращаемом цвете
/// @return {Color}
@function tint($color, $percentage) {
  @return mix(white, $color, $percentage);
}

/// Немного затемнить цвет
/// @access public
/// @param {Color} $color - цвет для затемнения
/// @param {Number} $percentage - процент от `$color` в возвращаемом цвете
/// @return {Color}
@function shade($color, $percentage) {
  @return mix(black, $color, $percentage);
}

/// Немного осветлить цвет
/// @access public
/// @param {Color} $color - цвет для осветления
/// @param {Number} $percentage - процент от `$color` в возвращаемом цвете
/// @return {Color}
@function tint($color, $percentage)
  @return mix($color, white, $percentage)

/// Немного затемнить цвет
/// @access public
/// @param {Color} $color - цвет для затемнения
/// @param {Number} $percentage - процент от `$color` в возвращаемом цвете
/// @return {Color}
@function shade($color, $percentage)
  @return mix($color, black, $percentage)

Списки

Списки Sass эквиваленты массивам. Список представляет собой плоскую структуру данных (в отличие от карт), предназначенную для хранения значений любого типа (в том числе списков со вложенными списками).

Списки должны соблюдать следующие правила:

• либо в одну строку, либо многострочный;
• многострочный необходим, если не помещается в 80-символьную строку;
• если используется для целей CSS, всегда разделяется запятой;
• всегда оборачивается круглыми скобками;
• в многострочном списке ставится запятая после последнего элемента.

// Yep
$font-stack: ('Helvetica', 'Arial', sans-serif);

// Yep
$font-stack: (
  'Helvetica',
  'Arial',
  sans-serif,
);

// Nope
$font-stack: 'Helvetica' 'Arial' sans-serif;

// Nope
$font-stack: 'Helvetica', 'Arial', sans-serif;

// Nope
$font-stack: ('Helvetica', 'Arial', sans-serif,);

// Yep
$font-stack: ('Helvetica', 'Arial', sans-serif)

// Nope (not supported)
$font-stack: (
  'Helvetica',
  'Arial',
  sans-serif,
)

// Nope
$font-stack: 'Helvetica' 'Arial' sans-serif

// Nope
$font-stack: 'Helvetica', 'Arial', sans-serif

// Nope
$font-stack: ('Helvetica', 'Arial', sans-serif,)

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

$shadows: (0 42px 13.37px hotpink);

// Yep
$shadows: append($shadows, $shadow, comma);

// Nope
$shadows: $shadows, $shadow;

$shadows: (0 42px 13.37px hotpink)

// Yep
$shadows: append($shadows, $shadow, comma)

// Nope
$shadows: $shadows, $shadow

В этой статье, я привожу множество советов и хитростей, как правильно обрабатывать и управлять списками в Sass.

Карты

С помощью Sass, авторы таблиц стилей могут создавать карты (maps) – термин Sass для связных массивов, хэшей или даже объектов JavaScript. Карта – это структура данных, сопоставляющая ключи со значениями. И ключ и значение может быть любым типом данных, включая карты, хотя я это не рекомендую использовать сложные типы данных как ключи карты, просто во имя здравого смысла.

Код карт следует писать следующим образом:

• пробел после двоеточия (:);
• открывающая скобка (() на той же строке, что и двоеточие (:);
• ключи в кавычках, если это строки (а это так в 99% случаев);
• каждая пара ключ/значение на своей строке;
• запятая (,) на конце каждой пары ключ/значение;
• закрывающая запятая (,) на последней паре, чтобы легче добавлять, удалять или переставлять пункты;
• закрывающая скобка ()) на своей новой строке;
• без пробела или новой строки между закрывающей скобкой ()) и точкой с запятой (;).

Пример:

// Yep
$breakpoints: (
  'small': 767px,
  'medium': 992px,
  'large': 1200px,
);

// Nope
$breakpoints: ( small: 767px, medium: 992px, large: 1200px );

// Yep
$breakpoints: ('small': 767px, 'medium': 992px, 'large': 1200px,)

// Nope
$breakpoints: ( 'small': 767px, 'medium': 992px, 'large': 1200px )

// Nope
$breakpoints: (small: 767px, medium: 992px, large: 1200px,)

// Nope (since it is not supported)
$breakpoints: (
  'small': 767px,
  'medium': 992px,
  'large': 1200px,
)

Записей о картах Sass не столь много, сколь ожидаема была эта возможность. Вот три статьи, которые я рекомендую: Using Sass Maps, Extra Map functions in Sass, Real Sass, Real Maps.

Набор правил CSS

На данный момент, это, в основном, пересмотр того, что все и так знают, но вот как набор правил CSS должен быть написан (по крайней мере, по мнению большинства руководств, в том числе CSS Guidelines):

• связанные селекторы на одной строке; не связанные селекторы на новой строке;
• открывающая скобка ({) отделяется от последнего селектора одним пробелом;
• каждое объявление на собственной новой строке;
• пробел после двоеточия (:);
• завершающая точка с запятой (;) в конце всех объявлений;
• закрывающая скобка (}) на своей новой строке;
• новая строка после закрывающей скобки }.

Пример:

// Yep
.foo, .foo-bar,
.baz {
  display: block;
  overflow: hidden;
  margin: 0 auto;
}

// Nope
.foo,
.foo-bar, .baz {
    display: block;
    overflow: hidden;
    margin: 0 auto }

// Yep
.foo, .foo-bar,
.baz
  display: block
  overflow: hidden
  margin: 0 auto

// Nope
.foo,
.foo-bar, .baz
    display: block
    overflow: hidden
    margin: 0 auto

Дополняя те руководства по CSS, мы должны обратить внимание на:

• локальные переменные объявляются перед любыми объявлениями, потом отделяются от деклараций новой строкой;
• вызовы примесей без @content идут перед любым объявлением;
• вложенные селекторы всегда идут после новой строки;
• вызовы примесей с @content идут после вложенных селекторов;
• без новых строк перед закрывающей фигурной скобкой (}).

Пример:

.foo, .foo-bar,
.baz {
  $length: 42em;

  @include ellipsis;
  @include size($length);
  display: block;
  overflow: hidden;
  margin: 0 auto;

  &:hover {
    color: red;
  }

  @include respond-to('small') {
    overflow: visible;
  }
}

.foo, .foo-bar,
.baz
  $length: 42em

  +ellipsis
  +size($length)
  display: block
  overflow: hidden
  margin: 0 auto

  &:hover
    color: red

  +respond-to('small')
    overflow: visible

Порядок объявлений

Невозможно удержать в голове все обсуждения, где мнения о сортировке объявлений в CSS настолько разнятся. Вообще, можно выявить два лагеря:

• придерживаться алфавитного порядка;
• упорядочивание по назначению (position, display, colors, font, miscellaneous…).

Есть плюсы и минусы в обоих вариантах. С одной стороны, сортировка в алфавитном порядке является универсальной (по крайней мере, для языков, использующих латинский алфавит), поэтому нет никаких споров о сортировке свойств. Тем не менее, мне весьма странно видеть свойства, такие как bottom и top, не рядом друг с другом. Почему анимации должны быть перед display? Есть много странностей с алфавитным упорядочиванием.

.foo {
  background: black;
  bottom: 0;
  color: white;
  font-weight: bold;
  font-size: 1.5em;
  height: 100px;
  overflow: hidden;
  position: absolute;
  right: 0;
  width: 100px;
}

.foo
  background: black
  bottom: 0
  color: white
  font-weight: bold
  font-size: 1.5em
  height: 100px
  overflow: hidden
  position: absolute
  right: 0
  width: 100px

С другой стороны, сортировка свойств по типу имеет смысл. Каждые объявления, относящиеся к шрифтам, располагаются рядом, как top и bottom, и чтение набора правил отчасти становится похожим на чтение рассказа. Но пока вы строго не придерживаетесь определённых соглашений, типа Idiomatic CSS, существует много спорных моментов. Где будет white-space – рядом со шрифтами или с display? Где расположить overflow? Что такое порядок свойств в группе (может быть в алфавитном порядке, о ирония)?

.foo {
  height: 100px;
  width: 100px;
  overflow: hidden;
  position: absolute;
  bottom: 0;
  right: 0;
  background: black;
  color: white;
  font-weight: bold;
  font-size: 1.5em;
}

.foo
  height: 100px
  width: 100px
  overflow: hidden
  position: absolute
  bottom: 0
  right: 0
  background: black
  color: white
  font-weight: bold
  font-size: 1.5em

Существует также ещё одно интересное поддерево способа упорядочивания, называется Concentric CSS, и, кажется, оно довольно популярно. В своей основе, Concentric CSS опирается на блочную модель, чтобы определить порядок: начинается за пределами, движется внутрь.

.foo {
  width: 100px;
  height: 100px;
  position: absolute;
  right: 0;
  bottom: 0;
  background: black;
  overflow: hidden;
  color: white;
  font-weight: bold;
  font-size: 1.5em;
}

.foo
  width: 100px
  height: 100px
  position: absolute
  right: 0
  bottom: 0
  background: black
  overflow: hidden
  color: white
  font-weight: bold
  font-size: 1.5em

Должен сказать, я сам не могу определиться. Недавний опрос на CSS-Tricks установил, что более 45% разработчиков упорядочивают свойства по их назначению, против 14% в алфавитном порядке. Кроме того, 39% об этом вообще не думают, и я в том числе.

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

Вложенность селекторов

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

Общие правила

Например, такая вложенность Sass:

.foo {
  .bar {
    &:hover {
      color: red;
    }
  }
}

.foo
  .bar
    &:hover
      color: red

…создаст такой CSS:

.foo .bar:hover {
  color: red;
}

Начиная с Sass 3.3 можно использовать ссылку на текущий селектор, используя &, чтобы создать дополнительные селекторы. Например:

.foo {
  &-bar {
    color: red;
  }
}

.foo
  &-bar
    color: red

…сгенерирует такой CSS:

.foo-bar {
  color: red;
}

.foo-bar
  color: red

Этот метод часто используется в методологии BEM для генерации селекторов .block__element и .block--modifier, основанных на базовом селекторе (т.е. .block в данном примере).

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

Это утверждение становится правдивее, когда селекторы становятся длиннее и ссылки на текущий селектор (&) более частыми. В какой-то момент риск потерять след и не суметь понять, что происходит, становится настолько высок, что не стоит того.

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

Тем не менее, есть, очевидно, несколько исключений из этого правила, и как мы увидим в следующем разделе, это мнение кажется довольно популярным. Вы можете прочитать об этом детальнее в статьях Beware of Selector Nesting и Avoid nested selectors for more modular CSS.

Исключения

Для начала, допускается, и я даже рекомендую, вкладывать псевдоклассы и псевдоэлементы в родительский селектор.

.foo {
  color: red;

  &:hover {
    color: green;
  }

  &::before {
    content: 'pseudo-element';
  }
}

.foo
  color: red

  &:hover
    color: green

  &::before
    content: 'pseudo-element'

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

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

.foo {
  // …

  &.is-active {
    font-weight: bold;
  }
}

.foo
  // …

  &.is-active
    font-weight: bold

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

.foo {
  // …

  .no-opacity & {
    display: none;
  }
}

.foo
  // …

  .no-opacity &
    display: none

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