El mapa de decisiones del track entero

Cincuenta y cinco niveles de CSS se pueden reducir a un puñado de decisiones que reaparecen en todos los proyectos, siempre con la misma forma y casi siempre resueltas por costumbre en lugar de por criterio. Este es el mapa: las diez preguntas, la respuesta corta de 2026, y —lo importante— la señal que te dice cuándo la respuesta corta no sirve para tu caso.

Cascada, ámbito y valores

1. ¿Cómo controlo el orden de la cascada?

Respuesta de 2026: con @layer, declarado en una línea al principio de todo. Nunca con especificidad, nunca con orden de ficheros, nunca con !important.

Cuándo no sirve: cuando el CSS de terceros no se puede envolver y ya está fuera de las capas. Entonces la única salida es que tu regla también esté fuera, y ahí sí vuelve la especificidad.

2. ¿Cómo evito que mis reglas alcancen lo que no deben?

Respuesta de 2026: @scope con techo y, si hay anidamiento del mismo componente, también con suelo. Si tienes herramientas que generan nombres únicos —módulos de CSS, estilos con ámbito de componente— ya lo tienes resuelto y @scope es redundante.

Cuándo no sirve: cuando escribes una biblioteca que aterriza en páginas ajenas. El selector raíz de tu @scope también puede colisionar. Ahí un prefijo sigue siendo la defensa correcta, como se argumentó en la lección de BEM.

3. ¿Cómo hago que mis estilos sean fáciles de sobrescribir?

Respuesta de 2026: :where() en los selectores de todo lo que sea reutilizable, lo que deja su especificidad en cero. Combinado con capas, tu componente nunca gana una guerra que no debería ganar.

Cuándo no sirve: para reglas de accesibilidad que deben ganar siempre. El bloque de movimiento reducido es el ejemplo canónico, y lleva !important con razón.

4. ¿Dónde vive un valor de diseño?

Respuesta de 2026: en una custom property, en la capa de tokens, en el nivel correcto de los tres. Ningún valor literal fuera de los primitivos, ningún componente leyendo primitivos.

Cuándo no sirve: cuando el valor no es una decisión de diseño sino un detalle de implementación —un z-index interno, una compensación de un píxel para alinear un icono—. Convertir eso en token lo asciende a decisión pública y luego no lo puedes cambiar.

Layout, adaptación y estado

5. ¿Cómo se adapta un componente a su contexto?

Respuesta de 2026: con @container y unidades de contenedor. El componente consulta el espacio que le dan, no el tamaño de la ventana, y no sabe dónde está.

Cuándo no sirve: cuando lo que cambia es de verdad una propiedad del dispositivo y no del hueco. La orientación, el tipo de puntero, la preferencia de movimiento y la de contraste son del usuario, y siguen siendo media queries.

6. ¿Grid o Flexbox?

Respuesta de 2026: Grid cuando hay una estructura de pistas compartida entre filas o hace falta solapar en la misma celda; Flexbox cuando el tamaño de cada pieza lo decide su contenido o es un solo eje. En una interfaz real se usan los dos, casi siempre anidados.

Cuándo no sirve: cuando el patrón es de mampostería, con piezas de alturas distintas que se empaquetan. Eso no era ninguno de los dos, y ahora tiene modo propio, como se cuenta en la lección sobre el futuro.

7. ¿Cómo represento un estado?

Respuesta de 2026: con las pseudo-clases nativas siempre que exista una —:hover, :focus-visible, :checked, :user-invalid, :open, :popover-open— y con :has() para propagarlo al contenedor. Ninguna clase sincronizada desde JavaScript.

Cuándo no sirve: cuando el estado no tiene representación en el DOM: “cargando”, “guardado hace tres segundos”, “hay cambios sin guardar”. Eso es un atributo de datos puesto por la aplicación, que sigue siendo una única fuente de verdad y sigue siendo consultable con :has().

Tema, rendimiento y herramienta

8. ¿Cómo hago un tema?

Respuesta de 2026: color-scheme para el esquema y light-dark() para los colores, con redeclaración de semánticos para lo que no son colores. Tres estados, no dos: claro, oscuro y automático. Y una meta etiqueta en la cabecera para que no haya destello.

Cuándo no sirve: cuando los temas son más de dos —marca blanca, temas de alto contraste, densidades—. Ahí light-dark() se queda corto y hay que redeclarar semánticos por tema, como se explicó en el nivel 52.

9. ¿Cómo hago que esto sea rápido?

Respuesta de 2026: reduciendo el alcance de la invalidación y el tamaño del CSS en el camino crítico. Ni una hora en optimizar selectores. contain donde el perfil demuestre que la invalidación se propaga, content-visibility en documentos largos, y will-change solo temporalmente y solo donde se haya medido.

Cuándo no sirve: nunca deja de servir, pero se aplica al revés de como la gente lo hace: primero se mide con la CPU limitada, y solo después se toca algo. Optimizar sin perfil es escribir deuda con la cara de una mejora.

10. ¿Qué herramienta de estilo uso?

Respuesta de 2026: la que encaje con quién escribe tu marcado y con cuánta disciplina puede sostener tu equipo. Todas convergen al mismo artefacto —CSS estático más custom properties— y migrar entre ellas es barato.

Cuándo no sirve: cuando la pregunta esconde otra. Si el equipo discute de herramienta es que casi siempre le falta lo de la pregunta 4, y ninguna herramienta lo resuelve.

La tabla, para tenerla a mano