Sass Guidelines

Formatação e sintaxe

Se me perguntarem, diria que a primeira coisa que um guia de estilo deve ser capaz de nos dizer é descrição do aspecto visual que queremos para o nosso código.

Quando vários programadores estão responsáveis por escrever CSS simultaneamente nos mesmos projectos, é apenas uma questão de tempo até que um deles comece a escrever as coisas à sua maneira. Guias de estilo que promovam consistência não só previnem isto, mas ajudam também à leitura e manutenção do código.

Sucintamente, queremos que (desavergonhadamente inspirado nas CSS Guidelines):

• dois (2) espaços de indentação, em vez de tabs;
• idealmente, linhas de no máximo 80 caráteres
• regras de CSS multi-linha devidamente escritas
• uso significativo de espaço em branco

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

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

    padding: 0 1em;
}

// Uma vez que Sass força estes padrões de indentação,
// Não há como errar aqui.
.foo
  display: block
  overflow: hidden
  padding: 0 1em

Strings

Acreditem ou não, strings desempenham um papel muito importante tanto em ecosistemas CSS e Sass. A maior parte dos valores de CSS são medidas ou identificadores, por isso é bastante crucial seguir algumas regras.

Codificação

Para evitar algum eventual problema com codificação de carateres, é recomendado forçar o modo UTF-8 na principal folhas de estilo, utilizando a directiva @charset. Certifiquem-se que é o primeiro elemento da folhas de estilo e que não existe mais nenhum caráter antes deste.

@charset 'utf-8';

@charset 'utf-8'

Aspas

CSS não necessita que strings apareçam entre aspas, nem mesmo as que contêm espaços. Peguemos no exemplo de font-family: não importa se utilizamos aspas no início e no fim.

Graças a isto, Sass também não necessita que as strings sejam entre aspas. Melhor ainda (e felizmente), uma string entre aspas é estritamente equivalente à sua irmã gémea sem aspas (por ex., 'abc' é estritamente igual a abc).

Dito isto, linguagens que não necessitam de aspas à volta de strings são uma minoria e, desta forma, strings devem sempre ser escritas com aspas curvas simples (também chamadas plicas) em Sass (as aspas simples ' são mais fáceis de escrever do que as duplas " em teclados qwerty). Para além de consistência com outras linguagens, incluindo JavaScript, existem outros motivos para esta escolha:

• nomes de cores são tratados como cores quando não possuem aspas, o que pode levar a conflitos;
• a maior parte dos highlighters de sintaxe dão problemas com strings sem aspas;
• ajuda em geral à leitura;
• não existe uma razão válida para não as usar;

// Yep
$direction: 'left';

// Nope
$direction: left;

// Yep
$direction: 'left'

// Nope
$direction: left

Strings como valores CSS

Valores específicos de CSS (identificadores), tais como initial ou sans-serif não necessitam de aspas. É verdade que a declaração font-family: sans-serif vai falhar silenciosamente porque o CSS está à espera de encontrar um indentificador, não uma string envolta em aspas. Deste modo, não utilizamos aspas nestes valores.

// 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')

Desta forma, podemos fazer uma distinção entre strings que pretendemos utilizar como valores de CSS (identificadores) como no exemplo anterior, e strings quando nos referimos aos tipos de dados em Sass, como por exemplo índices de mapas.

Não utilizamos aspas no primeiro, mas no segundo exemplo utilizamos aspas simples.

Strings com aspas

Se uma string contém uma ou várias aspas, vale a pena considerar envolver a string com aspas duplas ("), de modo a evitar fazer o escaping de carateres dentro da string.

// 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."

URLs

URLs devem ser envolvidos em aspas:

// 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)

Números

Em Sass, um número representa um tipo de dados que inclui tudo desde números sem unidades a medidas, a frequências, ângulos, e outros. Isto permite que cálculos sejam efetuados nestas medidas.

Zeros

Números devem mostrar zeros à esquerda da vírgula em valores abaixo de um (1). Nunca se deve mostrar zeros no final.

// 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

Unidades

Quando estamos a lidar com medidas, um valor 0 nunca deve ter unidade.

// Yep
$length: 0;

// Nope
$length: 0em;

// Yep
$length: 0

// Nope
$length: 0em

O erro mais comum que me consigo lembrar no que diz respeito a números em Sass é pensar que as unidades representam strings que podem ser adicionadas livremente a um número. Enquanto isto pode parecer correto, não é como as unidades funcionam. Pensem em unidades como símbolos algébricos. Por exemplo, no mundo real, multiplicar 5 centímetros por 5 centímetros resulta em 25 centímetros quadrados. A mesma lógica aplica-se em Sass.

Para adicionar uma unidade a um número, devemos multiplicar este número por 1 unidade.

$value: 42;

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

// Nope
$length: $value + px;

$value: 42

// Yep
$length: $value * 1px

// Nope
$length: $value + px

Reparem que adicionar 0 dessa mesma unidade também funciona, mas recomendo o primeiro método, uma vez que adicionar 0 unidades é algo confuso. Na verdade, quando tentamos converter um número para outra unidade comparável, adicionar 0 não irá funcionar. Leia mais sobre isso, neste artigo.

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

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

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

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

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

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

No final de contas, depende tudo do que estivermos a tentar obter. Lembrem-se apenas que adicionar o número-unidade como string não é uma boa prática.

Para remover a unidade de um valor, temos que dividi-lo por uma unidade do seu tipo.

$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)

Adicionar uma unidade como string a um número resulta numa string, prevenindo qualquer operação adicional no seu valor. Cortar a parte numérica de um número com uma unidade também resulta numa string, o que não é o desejado. Use cumprimentos, não strings.

Cálculos

Cálculos numéricos de maior prioridade devem sempre estar presentes entre parênteses. Isto não só melhora significativamente a sua leitura, como evita que aconteçam alguns casos extremos como forçar Sass a avaliar e computar o conteúdo entre parênteses.

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

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

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

// Nope
.foo
  width: 100% / 3

Números mágicos

“Números mágicos” (magic numbers) dizem respeito a um termo antigo computacional para constante numérica não definida. Basicamente, é um número aleatório que simplesmente parece funcionar por magia num caso específico e que não tem qualquer lógica por detrás dele.

Escusado será dizer que números mágicos são uma praga e devem ser evitados a todo o custo. Quando não conseguirem encontrar uma explicação para um determinado número funcionar, escrevam pelo menos um comentário que explique como chegaram a ele e porque é que acham que ele funciona. Admitir que não sabemos porque algo funciona é sempre mais útil do que deixar o programador seguinte tentar adivinhar o que se passa, sem qualquer pista.

/**
 * 1. Número mágico. Este é o valor mais baixo que encontrei para
 * alinhar o topo de `.foo` com o elemento pai.
 * Idealmente devíamos corrigir isto.
 */
.foo {
  top: 0.327em; /* 1 */
}

/**
 * 1. Número mágico. Este é o valor mais baixo que encontrei para
 * alinhar o topo de `.foo` com o elemento pai.
 * Idealmente devíamos corrigir isto.
 */
.foo
  top: 0.327em /* 1 */

Sobre o tema, CSS-Tricks tem um artigo maravilhoso sobre números mágicos em CSS que eu te encorajo a ler.

Cores

Cores ocupam um lugar muito importante em CSS. Naturalmente, Sass acaba por se tornar um aliado poderoso no que toca à manipulação de cores, especialmente porque providencia um punhado de funções úteis para tal.

Sass é tão bom na hora de manipular cores que artigos tem florescidos por toda parte da internet, exatamente sobre este tema. Por isso, posso recomendar algumas leituras:

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

Formatos de cores

De maneira a tornar cores em Sass o mais simples possível, o meu conselho é que respeitem a seguinte ordem de preferência para formatação de cores:

1. Anotação HSL;
2. Anotação RGB;
3. Anotação hexadecimal (minúscula e encurtada).

Keywords de cores CSS não devem ser usadas, a não ser para uma rápida prototipagem. De fato, elas são palavras reais, mas algumas fazem um trabalho péssimo em descrever a cor que representam, especialmente para falantes não nativos. Desse modo, keywords não são perfeitamente semânticas. Por exemplo: grey é, na verdade, mais escura que darkgrey. Além disso, a confusão entre grey e gray, pode levar a usos inconsistentes desta cor.

A representação HSL não é somente a mais fácil para o cérebro humano compreender^{[citation needed]}, ela também facilita que autores das folhas de estilos troquem a cor ajustando matiz (hue), saturação e luminosidade (lightness), individualmente.

RGB tem a vantagem de mostrar de cara se uma cor é mais vermelha, verde ou azul. Portanto, isso pode ser melhor que HSL em algumas situações, especialmente quando é necessário um vermelho, verde ou azul puro. Contudo, isso não facilita a criação de uma cor à partir das três partes.

Finalmente, a notação hexadecimal é próxima do indecifrável para a mente humana. Use isso como um último recurso, se você precisar.

// 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

Quando usarem a anotação HSL ou RGB, adicionem sempre um espaço simples depois da vírgula (,) e removam os espaços entre os parênteses ((, )) e o conteúdo.

// 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% )

Cores e variáveis

No caso de utilizarmos uma cor mais que uma vez, será provavelmente útil guardá-la numa variável cujo nome diga algo sobre essa cor.

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

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

Assim podemos usar esta variável onde for necessário. No entanto, se o seu uso estiver demasiado preso a um tema, eu não recomendaria utilizar a variável desta forma. Em vez disso, devemos guardá-la numa variável cujo nome explique como deve ser utilizada.

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

$main-theme-color: $sass-pink

Assim previne-se que a mudança de um tema leve a algo como $sass-pink: blue. Este artigo faz um bom trabalho ao explicar por que o pensamento de suas variáveis ​​de cores é importante.

Clarear e Escurecer cores

Tanto o clarear lighten como o escurecer darken representam funções que permitem manipular a luz de uma cor no espaço HSL adicionando ou subtraindo ao valor do espaço HSL. Basicamente, representam atalhos para o parâmetro $lightness do método de ajuste de cor adjust-color.

É importante referir que estas funções muitas vezes não geram os resultados que se esperaria. Por outro lado, a função de mistura mix é uma boa forma de escurecer ou clarear uma cor misturando-a com branco ou preto.

A vantagem de usar a mix em vez das primeiras funções mencionadas é que esta fará com que a cor tenda progressivamente para preto (ou branco) à medida que subtraímos a proporção da cor, enquanto que darken e lighten irão rapidamente esgotar a cor para os extremos de branco ou preto.

Se não quiserem escrever a função mix todas as vezes, podem criar duas funções fáceis-de-usar tint e shade (que já fazem parte de Compass) que fazem essencialmente o mesmo:

/// Clarear ligeiramente uma cor
/// @access public
/// @param {Color} $color - cor
/// @param {Number} $percentage - percentagem da `$color` na cor devolvida
/// @return {Color}
@function tint($color, $percentage) {
  @return mix($color, white, $percentage);
}

/// Escurecer ligeiramente uma cor
/// @access public
/// @param {Color} $color - cor
/// @param {Number} $percentage - percentagem da `$color` na cor devolvida
/// @return {Color}
@function shade($color, $percentage) {
  @return mix($color, black, $percentage);
}

/// Clarear ligeiramente uma cor
/// @access public
/// @param {Color} $color - cor
/// @param {Number} $percentage - percentagem da `$color` na cor devolvida
/// @return {Color}
@function tint($color, $percentage)
  @return mix($color, white, $percentage)

/// Escurecer ligeiramente uma cor
/// @access public
/// @param {Color} $color - cor
/// @param {Number} $percentage - percentagem da `$color` na cor devolvida
/// @return {Color}
@function shade($color, $percentage)
  @return mix($color, black, $percentage)

Listas

Listas são o equivalente de arrays. Uma lista é uma estrutura de dados “flat” (ao contrário de mapas) usada para guardar valores de qualquer tipo (incluindo listas, dando origem a listas aninhadas).

As listas devem respeitar as seguintes orientações:

• sejam uma linha ou várias;
• necessariamente em várias linhas se forem demasiado longas para caber numa linha de 80 carateres;
• a não ser para fins de CSS, sempre separadas por vírgula;
• sempre envolvidas em parêntesis;
• finalizadas com um ponto final em multi-linha.

// 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,)

Ao adicionar novos itens a uma lista, usar sempre a API fornecida. Nunca tentar adicionar novos itens manualmente.

$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

Neste artigo, eu vou a fundo de vários truques e dicas para lidar e manipular listas corretamente, no Sass.

Mapas

Com Sass, autores de folhas de estilo podem definir mapas - o termo do Sass para arrays associativos, mapas de hash ou mesmo objectos em JavaScript. Um mapa é uma estrutura de dados que associa chaves a valores. Tanto chaves quanto valores podem ser de qualquer tipo de dados, incluindo mapas, embora eu não o recomende usar tipos de dados complexos como chaves, para que matenhamos a sanidade.

Mapas devem ser escritos da seguinte forma:

• espaços depois dos dois pontos (:);
• parêntesis de abertura (() na mesma linha dos dois pontos (:);
• chaves com aspas se forem strings (o que representa 99% dos casos);
• cada par chave/valor na sua própria linha;
• vírgula (,) após cada par chave/valor;
• vírgula final (,) no último item, para que seja mais fácil adicionar, remover ou reordenar items;
• parêntesis de fecho ()) na sua própria linha;
• não colocar um espaço um um caractér de nova linha entre o parêntesis de fecho ()) e o ponto e vírgula (;).

Ilustração:

// 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,
)

Textos sobre mapas Sass são muitos, dado o quão esperada essa feature foi esperada. Aqui vai três, dos quais eu recomendo: Using Sass Maps, Extra Map functions in Sass, Real Sass, Real Maps.

Conjunto de regras para CSS

A esta altura, isto é essencialmente uma revisão do que toda a gente sabe, mas é assim que um conjunto de regras para CSS deve ser escrito (pelo menos, de acordo com a maioria dos guias de orientação, incluindo CSS Guidelines):

• seletores relacionados na mesma linha; seletores sem relação numa nova linha;
• chaveta de abertura ({) separada do último seletor por um espaço único;
• cada declaração na sua própria linha;
• um espaço a seguir aos dois pontos (:);
• um ponto e vírgula terminal (;) no final de cada declaração;
• chaveta de fecho (}) na sua própria linha;
• uma linha em branco após a chaveta de fecho (}).

Ilustração:

// 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

Acrescentando às regras relacionadas com CSS, queremos prestar atenção a:

• variáveis locais declaradas antes de qualquer outra declaração, separadas de declarações seguintes por uma linha em branco;
• chamadas de mixins sem @content feitas antes de qualquer declaração;
• seletores aninhados sempre precedidos por uma linha em branco;
• chamadas de mixins com @content feitas depois de qualquer seletor aninhado;
• não adicionar uma linha em branco depois da chaveta de fecho (}).

Ilustração:

.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

Ordenar as declarações

Não me ocorrem muitos tópicos em que as opiniões sejam tão divididas como são em relação a ordenar declarações em CSS. Na verdade, existem duas facções:

• manter a ordem alfabética;
• ordenar declarações por tipo (position, display, cores, tipo de letra, outros).

Existem prós e contras em ambas as abordagens. Por um lado, a ordem alfabética é universal (pelo menos em todos os idiomas que usam o alfabeto latino), portanto não existe dúvida quanto a colocar uma propriedade antes de outra. No entanto, parece-me bastante estranho ver propriedades como bottom e top separadas uma da outra. Por que motivo apareceriam animações antes do tipo display? Há imensas peculiaridades na ordenação alfabética.

.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

Por outro lado, ordenar propriedades por tipo faz todo o sentido. Todas as declarações relacionadas com tipos de letra estão próximas, top e bottom estão juntas e ler um conjunto de regras quase se assemelha a ler uma pequena história. Mas a não ser que te mantenhas fiel a algumas convenções, como Idiomatic CSS, há imenso espaço para interpretação própria nesta forma de fazer as coisas. Onde ficaria white-space: font ou display? Onde é que overflow pertence exactamente? Qual é a ordem das declarações dentro de um grupo (poderia ser ordem alfabética; ah, a ironia)?

.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

Há ainda outro tipo de ordenação interessante chamado Concentric CSS, que parece ser também bastante popular. Basicamente, o Concentric CSS baseia-se no box-model para definir uma ordem: começa no exterior, move-se para o interior.

.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

Devo dizer que pessoalmente não me consigo decidir. Uma recente sondagem no CSS-Tricks apurou que mais de 45% dos programadores ordenam as suas declarações por tipo, contra 14% que o fazem alfabeticamente. Há ainda 39% que o fazem de uma forma totalmente aleatória, incluindo eu próprio.

Por esse motivo, não vou impor uma escolha neste guia de estilos. Escolham aquele que preferirem, desde que sejam consistentes ao longo das vossas folhas de estilo (isto é, não escolham a opção aleatória).

Seletores aninhados

Uma das características do Sass que está a ser extremamente mal usada por muitos programadores são os seletores aninhados. Alinhar seletores oferece aos autores de folhas de estilo uma forma de computar seletores longos, aninhando seletores mais pequenos dentro de outros.

Regra geral

Por exemplo, o seguinte código aninhado em Sass:

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

.foo
  .bar
    &:hover
      color: red

… vai gerar este CSS:

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

Do mesmo modo, desde o Sass 3.3 que é possível usar uma referência ao seletor atual (&) para gerar seletores avançados. Por exemplo:

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

.foo
  &-bar
    color: red

… vai gerar este CSS:

.foo-bar {
  color: red;
}

.foo-bar
  color: red

Este método é geralmente usado em conjunto com a nomenclatura BEM para gerar os seletores .block__element e .block--modifier baseados no seletor original (neste caso, .block).

O problema com aninhar seletores é que, em última instância, torna o código mais difícil de ler. O leitor tem de mentalmente computador o seletor resultante a partir dos níveis de indentação; nem sempre é óbvio o que é que o CSS resultante acabará por ser.

Este argumento torna-se ainda mais verdadeiro à medida que os seletores se tornam mais longos e as referências ao seletor atual (&) mais frequentes. A dada altura, o risco de perder o fio à meada e deixar de perceber o que se passa e onde é tão alto que deixa de valer a pena.

Para evitar tais situações, nós falamos muito sobre a Inception rule alguns anos atrás, aconselhando contra aninhamento de mais de três leveis a fundo, usando como referência o filme “Inception” de Christopher Nolan. Além do mais, eu seria mais dramático e recomendaria evitar aninhamento de seletores, o máximo possível.

Enquanto há, obviamente, algumas exceções para esta regra (como nós vamos ver na próxima seção), esta opinião parece ser a mais popular. Você pode ler sobre isso mais em detelhes no Beware of Selector Nesting e Avoid nested selectors for more modular CSS.

Exceções

Para começar, é permitido e até aconselhado aninhar pseudo-classes e pseudo-elementos no seletor inicial.

.foo {
  color: red;

  &:hover {
    color: green;
  }

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

.foo
  color: red

  &:hover
    color: green

  &::before
    content: 'pseudo-element'

Aninhar seletores em pseudo-classes e pseudo-elementos não só faz sentido (porque lida com seletores intimamente ligados), mas também ajuda a manter tudo relacionado com um determinado componente num único sítio.

Além disso, quando se usam classes de estado independentes de um componente, como .is-active, é perfeitamente aceitável aninhá-las sob o selctor do componente, de modo a manter tudo limpo.

.foo {
  // …

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

.foo
  // …

  &.is-active
    font-weight: bold

Por fim, quando se estiliza um elemento só porque ele está dentro de outro elemento específico, é também aceitável aninhá-lo, de modo a manter tudo sobre um determinado componente no mesmo sítio.

.foo {
  // …

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

.foo
  // …

  .no-opacity &
    display: none

Como tudo, as especificidades são de certa forma irrelevantes, o importante é a consistência. Se te sentes perfeitamente confiante com seletores aninhados, então usa seletores aninhados. Certifica-te apenas que toda a tua equipa está confortável com isso.