Sass Guidelines

Sintaxis Y Formato

En mi opinión, la primera cosa que debe hacer una guía de estilo es describir la forma en que queremos que luzca nuestro código.

Cuando varios desarrolladores están involucrados en la escritura CSS dentro del mismo proyecto o proyectos, es sólo cuestión de tiempo antes de que uno de ellos empiece a hacer las cosas a su manera. Las guías de estilo de código que fomentan la coherencia no solo previenen esto, sino que también ayudan a la hora de leer y actualizar el código.

A grandes rasgos, lo que queremos (humildemente inspirados en CSS Guidelines es):

• dos (2) espacios en blanco, en lugar de tabulaciones;
• idealmente, líneas de 80 caracteres;
• reglas CSS multilínea correctamente escritas;
• buen uso de los espacios en blanco.

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

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

    padding: 0 1em;
}

// Puesto que Sass es una sintaxis con sangría obliga a estos estándares de codificación
// No hay manera incorrecta de proceder
.foo
  display: block
  overflow: hidden
  padding: 0 1em

Cadenas

Lo creas o no, las cadenas (strings) juegan un papel importante en los ecosistemas de CSS y Sass. La mayoría de los valores CSS suelen ser longitudes o identificadores, así que es bastante crucial que cumplas ciertas pautas cuando se trabaja con cadenas en Sass.

Codificación

Para evitar cualquier posible problema con la codificación de caracteres, es muy recomendable forzar la codificación UTF-8 en la hoja de estilo principal usando la directiva @charset. Asegúrate que es el primer elemento de la hoja de estilo y que no hay ningún otro caracter de ningún tipo antes.

@charset 'utf-8';

@charset 'utf-8'

Comillas

En CSS, las cadenas (strings) no tienen por qué estar entre comillas, ni siquiera aquellas que contienen espacios. Toma como ejemplo, los nombres de las tipografías: no importa si las pones entre comillas o no para que el analizador sintáctico CSS las entienda.

Debido a esto, Sass tampoco necesita que las cadenas estén entre comillas. Incluso mejor (y con suerte me darás la razón) una cadena entre comillas es equivalente a su versión gemela sin comillas (por ejemplo, 'abc' es estrictamente igual a abc).

Dicho esto, los lenguajes que no requieren que las cadenas estén entre comillas, son definitivamente una minoría, y es por lo que las cadenas siempre deben ir entre comillas simples (') en Sass (las comillas simples son mucho más fáciles de escribir en los teclados qwerty). Además de la coherencia con otros lenguajes, entre ellos el primo de CSS, Javascript, hay otras razones para esta elección:

• los nombres de los colores son tratados directamente como colores cuando no están entre comillas, lo que provoca serios problemas;
• muchos resaltadores de sintaxis se volverían locos sin las comillas;
• ayuda a la legibilidad;
• no hay una razón válida para no entrecomillar las cadenas.

// Yep
$direction: 'left';

// Nope
$direction: left;

// Yep
$direction: 'left'

// Nope
$direction: left

Cadenas Como Valores CSS

Los valores CSS específicos (identificadores) como initial o sans-serif no necesitan llevar comillas. De hecho, la declaración font-family: 'sans-serif' fallará porque CSS está esperando un identificador, no una cadena entre comillas. Por ello, no pondremos nunca estos valores con comillas.

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

Por lo tanto, podemos hacer una distinción entre las cadenas destinadas a ser utilizadas como valores CSS (identificadores CSS) como en el ejemplo anterior, y las cadenas que son un tipo de datos Sass, por ejemplo, las claves de mapa.

No ponemos entre comillas la primera, pero si envolvemos la segunda con comillas simples.

Cadenas que contienen comillas

Si una cadena contiene una o varias comillas simples, se podría considerar envolver la cadena con comillas dobles ("), con el fin de evitar escapar demasiados caracteres dentro de la cadena.

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

Las URLs deben ir entre comillas por las mismas razones que se explican anteriormente:

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

En Sass, número es un tipo de datos que incluye de todo, desde números sin unidades a longitudes, pasando por duraciones, frecuencias y ángulos, entre otros. Esto permite que se ejecuten cálculos sobre tales medidas.

Ceros

Siempre se deben mostrar los ceros a la izquierda antes de un valor decimal menor que uno. Nunca mostrar los ceros finales.

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

Cuando se trata de longitudes, el 0 nunca debe llevar el nombre de la unidad.

// Yep
$length: 0;

// Nope
$length: 0em;

// Yep
$length: 0

// Nope
$length: 0em

El error más común que se me ocurre respecto a los números en Sass, es el de pensar que las unidades son solo una serie de cadenas que se añaden a un número. Aunque parezca verdad, esta sin duda, no es la forma en la que funcionan las unidades. Piensa en las unidades como símbolos algebráicos. Por ejemplo, en el mundo real, multiplicar 5 metros por 5 metros, da como resultado 25 metros cuadrados. La misma lógica se aplica a Sass.

Para agregar una unidad a un número, hay que multiplicar este número por 1 unidad.

$value: 42;

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

// Nope
$length: $value + px;

$value: 42

// Yep
$length: $value * 1px

// Nope
$length: $value + px

Ten en cuenta que sumando un valor de 0 de unidad también funciona, pero prefiero recomendar el método antes mencionado, ya que sumar una unidad 0 puede resultar confuso. De hecho, cuando se trata de convertir un número a otra unidad compatible, emplear el truco del 0, no funcionará. Puedes leer más sobre esto en este artículo.

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

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

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

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

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

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

Al final, siempre depende lo que estés tratando de conseguir. Solo ten en cuenta que añadir la unidad como una cadena de caracteres no es una buena manera de proceder.

Para eliminar la unidad de un valor, hay que dividirlo por 1 unidad de su mismo 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)

Al añadir a un número una unidad en forma de cadena, el resultado es una cadena, impidiendo cualquier operación adicional con dicho valor. Separando la parte numérica de un número con una unidad también devolverá una cadena. Usa longitudes, no cadenas.

Cálculos

Los cálculos numéricos de nivel superior deben ir siempre entre paréntesis lo cual, no solo mejorará drásticamente la legibilidad, sino que también evitará algunos casos extremos al forzar a Sass a evaluar los contenidos de los paréntesis.

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

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

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

// Nope
.foo
  width: 100% / 3

Números Mágicos

Un “número mágico” es un término de programación de la vieja escuela para las constantes numéricas sin nombre. Básicamente, es solo un número aleatorio que simplemente funciona y sin embargo no está ligado con ninguna explicación lógica.

No hace falta decir que los números mágicos son una plaga y que se deben evitar a toda costa. Cuando no se puede encontrar una explicación razonable a por qué un número funciona, añade un comentario claro y completo explicando como has llegado hasta allí y por qué crees que funciona. Admitir que no sabes por qué algo funciona es mucho más útil para el siguiente desarrollador que dejarle tener que averiguar lo que está pasando desde el principio.

/**
 * 1. Número mágico. Este valor es el más bajo que pude encontrar para alinear la parte superior de
 * `.foo` con su padre. Idealmente, deberíamos arreglarlo correctamente.
 */
.foo {
  top: 0.327em; /* 1 */
}

/**
 * 1. Número mágico. Este valor es el más bajo que pude encontrar para alinear la parte superior de
 * `.foo` con su padre. Idealmente, deberíamos arreglarlo correctamente.
 */
.foo
  top: 0.327em /* 1 */

Relacionado con esto, CSS-Tricks tiene un excelente artículo acerca de los números mágicos en CSS que te animo a que leas.

Colores

Los colores ocupan un lugar importante en el lenguaje CSS. Naturalmente, Sass termina siendo un valioso aliado cuando se trata de la manipulación de colores, especialmente, al proporcionar un puñado de funciones potentes.

Sass es tan útil cuando se trata de manipular los colores, que han florecido artículos por todo Internet sobre este tema. Te recomiendo algunas lecturas:

• ¿Cómo ir programáticamente de un color a otro? - En inglés
• Usando Sass para construir paletas de color - En inglés
• Tratando con esquemas de color en Sass - En inglés

Formatos De Color

Con el objetivo de que hacer colores sean tan simple como sea posible, mi consejo es que respetes el siguiente orden de preferencia de los formatos de color:

1. Notación HSL;
2. Notación RGB;
3. Notación hexadecimal. Preferiblemente en minúsculas y en formato corto.

Las palabras clave para denominar colores en CSS no deben ser usadas, a menos que se utilicen para prototipos rápidos. De hecho, son palabras inglesas y algunas de ellas hacen un trabajo bastante malo al describir el color que representan, especialmente para hablantes no nativos. Además de eso, las palabras clave no son perfectamente semánticas; Por ejemplo grey es en realidad más oscuro que darkgrey, y la confusión entre grey y gray puede llevar a usos inconsistentes de este color.

La representación HSL no solo es la más sencilla de comprender para el cerebro humano^{[cita requerida]}, sino que también facilita a los autores de las hojas de estilo modificar el color al ajustar el tono, la saturación y la luminosidad de forma individual.

RGB todavía tiene la ventaja de mostrar de inmediato si el color tiene más de azul, o de verde o de rojo. Por lo tanto, podría ser mejor que HSL en algunas situaciones, especialmente cuando se describe un rojo, verde o azul puro. Pero esto no significa que sea fácil construir un color con estas tres partes.

Por último, el formato hexadecimal está cerca de ser indescifrable para la mente humana. Úsalo como último recurso, si tienes que hacerlo.

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

Al usar HSL o notación RGB, añade siempre un espacio simple después de la coma (,) y ningún espacio entre el paréntesis ((, )) y el contenido.

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

Colores Y Variables

Cuando se utiliza un color más de una vez, guárdala en una variable con un nombre significativo que represente al color.

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

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

Ahora puedes usar esta variable en cualquier lugar. Sin embargo, si su uso está fuertemente ligado a un tema, te desaconsejaría usar esta variable como tal. En su lugar, guárdala en otra variable con un nombre que explica como se debe utilizar.

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

$main-theme-color: $sass-pink

Al hacer esto, evitarás que algún cambio en el tema resulte en algo como $sass-pink: blue. Este artículo hace un buen trabajo explicando por qué pensar el nombre de tus variables de color es importante.

Aclarando Y Oscureciendo Colores

Tanto las funciones lighten como darken manipulan la luminosidad de un color en el espacio HSL añadiendo o restando a la luminosidad de dicho espacio. Básicamente, son alias para el parámetro $lightness de la función adjust-color

La cuestión es que esas funciones a menudo no proporcionan el resultado esperado. Por otro lado, la función mix es una buena manera para aclarar u oscurecer un color al mezclarlo con blanco or negro.

La ventaja de usar mix en lugar de una de las funciones anteriormente mencionadas, es que con mix irá progresivamente a negro (o blanco) a medida que se disminuye la proporción de color, mientras que darken y lighten apagará rápidamente el color hasta llegar a negro o blanco.

Si no quieres escribir la función mix cada vez que quieras usarla, puedes crear dos funciones muy sencillas de utilizar, tint y shade (que también son parte de Compass) para conseguir el mismo resultado:

/// Aclarar ligeramente un color
/// @access public
/// @param {Color} $color - color a matizar
/// @param {Number} $percentage - porcentaje del `$color` que debe ser devuelto
/// @return {Color}
@function tint($color, $percentage) {
  @return mix(white, $color, $percentage);
}

/// Oscurecer ligeramente un color
/// @access public
/// @param {Color} $color - color a oscurecer
/// @param {Number} $percentage - porcentaje de `$color` que debe ser devuelto
/// @return {Color}
@function shade($color, $percentage) {
  @return mix(black, $color, $percentage);
}

/// Aclarar ligeramente un color
/// @access public
/// @param {Color} $color - color a matizar
/// @param {Number} $percentage - porcentaje del `$color` que debe ser devuelto
/// @return {Color}
@function tint($color, $percentage)
  @return mix($color, white, $percentage)

/// Oscurecer ligeramente un color
/// @access public
/// @param {Color} $color - color a oscurecer
/// @param {Number} $percentage - porcentaje de `$color` que debe ser devuelto
/// @return {Color}
@function shade($color, $percentage)
  @return mix($color, black, $percentage)

Listas

Las listas son el equivalente en Sass a los arreglos (Arrays). Una lista es una estructura de datos plana (a diferencia de los Mapas) destinada a almacenar valores de cualquier tipo (incluyendo listas, lo que conduce a las listas anidadas).

Las listas deberían respetar las siguientes pautas:

• pueden ser en una línea o multilínea
• deben usar múltiples líneas si su longitud es mayor a 80 caracteres;
• a menos que se utilice para CSS, siempre usará la coma como separador;
• siempre debe ir entre paréntesis;
• Usar coma final si hay múltiples líneas, pero no cuando es una sola.

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

Al añadir nuevos elementos a una lista, utiliza siempre la API proporcionada. No trates de añadir nuevos elementos 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

En este artículo, explico un montón de trucos y consejos para manejar y manipular las listas correctamente en Sass.

Mapas

Con Sass, se pueden definir mapas - el término en Sass para los arreglos asociativos, hashes o incluso objetos JavaScript. Un mapa es una estructura de datos que asocia claves a valores. Tanto las claves como los valores, pueden ser de cualquier tipo de dato, incluyendo mapas, aunque yo no recomendaría usar tipos de datos tan complejos como claves de un mapa, solo por salud mental.

Los mapas deberían estar escritos de la siguiente manera:

• poner un espacio después de los dos puntos (:);
• la llave de apertura (() debe ir en la misma línea que los dos puntos (:);
• poner las claves entre comillas si son cadenas (lo que representa el 99% de los casos);
• cada par clave/valor debe ir en su propia línea;
• poner coma (,) al final de cada par clave/valor;
• poner coma final (,) en el último elemento para que sea más sencillo añadir, eliminar o reordenarlos;
• la llave de cierre ()) debe ir en una línea nueva;
• no poner espacio o línea nueva entre la llave de cierre ()) y el punto y coma (;).

Ejemplo:

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

Los escritos acerca de los mapas de Sass son muchos dado cuánto se anhelaba esta característica. Aquí hay 3 que recomiendo: Usando Mapas en Sass - En inglés, Funciones adicionales de mapas en Sass - En inglés, Sass real, mapas reales - En inglés.

Conjunto De Reglas CSS

Llegados a este punto, esto es básicamente una revisión de lo que todo el mundo ya sabe, pero esta es la forma en la que un conjunto de reglas CSS deben estar escritas (por lo menos según la mayoría de las guías, incluyendo la Guía de estilo de CSS):

• los selectores relacionados deben ir en la misma línea; los selectores no vinculados en líneas nuevas;
• la llave de apertura ({) debe separarse del selector usando un espacio;
• cada declaración debe ir en una línea nueva;
• añadir un espacio después de los dos puntos (:);
• poner punto y coma (;) al final de todas las declaraciones;
• la llave de cierre (}) debe ir en una línea nueva;
• añadir una línea después de la llave de cierre (}).

Ejemplo:

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

Adicionalmente a esas guías CSS, queremos prestar especial atención a las siguientes pautas:

• las variables locales se declaran antes que cualquier otra y están espaciadas por un salto de línea;
• las llamadas a los mixin sin @content deben ir antes de cualquier declaración;
• los selectores anidados van siempre después de un salto de línea;
• las llamadas a los mixin con @content deben ir después de cualquier selector anidado;
• no usar un salto de línea antes de una llave de cierre (}).

Ejemplo:

.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

Clasificación De Declaraciones

No se me ocurren muchos temas donde las opiniones estén tan divididas como en lo que respecta a la clasificación de las declaraciones en CSS. En concreto, hay dos bandos aquí:

• mantener un estricto orden alfabético;
• ordenar las declaraciones por tipo (posición, display, colores, tipografía, varios…).

Hay pros y contras para estas dos posturas. Por una parte, el orden alfabético es universal (por lo menos para los idiomas que usan el alfabeto latino) así que no hay discusión posible a la hora de poner una propiedad antes que otra. Sin embargo, me parece extremadamente raro ver que propiedades como, bottom y top no estén la una justo después de la otra. ¿Por qué las animaciones deben aparecer antes que el tipo de display? Hay muchas singularidades con respecto al orden alfabético.

.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 otra parte, ordenar las propiedades por tipo tiene mucho sentido. Cada declaración relacionada está reunida, top y bottom están una debajo de la otra y leer un conjunto de reglas parece como leer un cuento corto. Pero a menos que mantengas algunas convenciones como las que se exponen en CSS idiomático, hay mucho espacio para la interpretación en esta forma de escribir CSS. ¿Dónde debería ir white-space: en tipografía o en display?, ¿Dónde pertenece overflow exactamente?, ¿Cuál es el orden de una propiedad dentro de un grupo? (podría ser en orden alfabético, ¡oh! ironía)

.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

También hay otra rama interesante en cuanto al orden de propiedades, llamado CSS concéntrico, que parece ser bastante popular. Básicamente el CSS concéntrico se basa en el modelo de caja para definir un orden: se empieza fuera y se mueve hacia dentro.

.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

Debo decir que ni yo mismo puedo decidirme. Una encuesta reciente en CSS-Tricks determinó que más de un 45% de los desarrolladores ordenan sus declaraciones por tipo, frente el 14% que lo hace alfabéticamente. También hay un 39% que lo hace completamente al azar, incluido yo mismo.

Debido a esto, no voy a imponer una opción en concreto en esta guía de estilo. Elige la que más te guste, siempre y cuando sea coherente con el resto de tus hojas de estilo (es decir, no la opción al azar).

Anidamiento De Selectores

Una característica particular que aporta Sass y que está siendo muy mal utilizada por muchos desarrolladores es el anidamiento de selectores. El anidamiento de selectores ofrece una forma para que los autores de las hojas de estilo puedan calcular selectores largos anidando selectores más cortos dentro de ellos.

Regla General

Por ejemplo, el siguiente anidamiento Sass:

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

.foo
  .bar
    &:hover
      color: red

…generará el siguiente CSS:

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

En la misma línea, desde Sass 3.3 es posible usar la referencia al selector actual (&) para generar selectores avanzados. Por ejemplo:

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

.foo
  &-bar
    color: red

…generará el siguiente CSS:

.foo-bar {
  color: red;
}

.foo-bar
  color: red

Este método se utiliza a menudo junto con las convenciones de nombrado BEM para generar los selectores .block__element y .block--modifier basados en los selectores originales (por ejemplo, .block en este caso).

El problema con la anidación de selectores es que en última instancia hace que el código sea más difícil de leer. Se debe calcular mentalmente el selector resultante de los distintos niveles de sangría; no siempre resulta obvio conocer el código resultante en CSS.

Esta afirmación se vuelve más verdadera en cuanto los selectores se hacen más largos y las referencias al selector actual (&) más frecuentes. En algún punto, el riesgo de perder la pista y no poder entender lo que está pasando es tan alto que no merece la pena.

Para evitar estas situaciónes, hemos hablado mucho sobre la regla de Origen - En inglés desde hace algunos años. Recomendaba no anidar los selectores más allá de 3 niveles de profundidad, como referencia a la película Inception de Christopher Nolan. Yo sería mucho más drástico y recomendaría evitar la anidación de selectores tanto como sea posible.

Sin embargo, es evidente que hay algunas excepciones a esta regla como se verá en la siguiente sección, esta opinión es bastante popular y puedes leer más sobre ella en Ten cuidado con la anidación de selectores - En inglés y Evita la anidación de selectores para obtener un CSS más modular - En inglés.

Excepciones

Para los principiantes, se permite e incluso se recomienda anidar pseudo-clases y pseudo-elementos dentro del selector inicial.

.foo {
  color: red;

  &:hover {
    color: green;
  }

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

.foo
  color: red

  &:hover
    color: green

  &::before
    content: 'pseudo-element'

Usar la anidación para las pseudo-clases y los pseudo-elementos no solo tiene sentido (porque trata con selectores relacionados), sino que también ayuda a mantener todo lo relacionado con un componente en un mismo lugar.

Además, cuando se utilizan clases de estado independientes del dispositivo como .is-active, está perfectamente bien anidar dentro del selector del componente para mantenerlo todo ordenado.

.foo {
  // …

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

.foo
  // …

  &.is-active
    font-weight: bold

Por último, pero no menos importante, cuando se da estilo a un elemento, este pasa a estar contenido en otro elemento específico, también está bien utilizar la anidación para mantener todo lo relacionado con el componente en el mismo lugar.

.foo {
  // …

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

.foo
  // …

  .no-opacity &
    display: none

Como en todo, los detalles son algo irrelevante, la coherencia es la clave. Si te sientes completamente confiado con la anidaciones de selectores, entonces utilizala. Sólo asegurate de que todo tu equipo está de acuerdo con ello.