Lo que quedó obsoleto y el paso a los tokens
El inventario exacto de qué reglas clásicas sustituyó cada función moderna, y por qué el centro de gravedad de la arquitectura se movió de los selectores a los valores.
Entre 2021 y 2026 el lenguaje absorbió, una por una, casi todas las carencias que las metodologías clásicas compensaban con disciplina. El resultado no es que ahora haya que elegir otra metodología: es que el problema central se ha movido. Cuando el motor te garantiza el ámbito, el orden y la especificidad, lo que queda por gobernar ya no son los selectores sino los valores, y ese es exactamente el terreno de los tokens de diseño.
- Emparejar cada regla clásica con la función del lenguaje que la sustituye.
- Distinguir qué disciplina sigue siendo necesaria y por qué.
- Explicar qué es un token de diseño y en qué se diferencia de una variable.
- Entender por qué el centro de gravedad se desplazó de los selectores a los valores.
El inventario de sustituciones
Esta es la tabla que hace falta tener delante al leer cualquier artículo de arquitectura escrito antes de 2022.
| Regla clásica | Qué la sustituye | Qué se gana |
|---|---|---|
| Prefijar todo con el nombre del bloque | @scope con techo y suelo |
lo aplica el motor, no una persona |
| Una sola clase por selector | :where() |
expresividad sin perder control |
| Ordenar ficheros por especificidad creciente | @layer |
independencia del orden de carga |
!important en las utilidades |
la última capa declarada | sin escalada, reversible |
| Variables de Sass en una capa Settings | custom properties | cascada, subárboles, runtime |
| Mixins para valores calculados | clamp(), min(), max(), color-mix() |
se resuelve en el navegador |
Generar nombres con &__ en Sass |
anidamiento nativo | los nombres siguen siendo buscables |
| Clases modificadoras por contexto | @container y unidades de contenedor |
el componente no sabe dónde está |
| Clases de estado puestas por JavaScript | :has() con las pseudo-clases nativas |
una sola fuente de verdad del estado |
| Temas como conjuntos alternativos de reglas | temas como conjuntos de valores | tamaño constante con el número de temas |
Lo que hay que ver en esa tabla no es que las metodologías estuvieran equivocadas, sino que casi todas sus reglas eran implementaciones manuales de mecanismos ausentes, tal como quedó planteado en la primera lección del nivel. Cada fila es una convención que dejó de necesitar voluntarios.
Lo que no sustituye nada
Hay tres cosas que ninguna función del lenguaje resuelve y que siguen exigiendo decisiones humanas. Son, precisamente, lo que queda de arquitectura de verdad.
Nombrar. Ningún mecanismo decide si eso es una tarjeta, un panel o una superficie. Nombrar es modelar, y modelar es la parte difícil. @scope te evita las colisiones, no te dice qué conceptos tiene tu producto.
Decidir la frontera de un componente. Dónde acaba un componente y empieza otro, qué configuración expone y qué se queda dentro, es una decisión de diseño de API que el CSS no puede tomar. Es el mismo problema que decidir la firma de una función.
Fijar la escala. Cuántos pasos tiene tu escala de espaciado, cuántos tonos tiene tu paleta, cuántos tamaños de texto existen. Aquí no hay respuesta correcta universal, y la decisión determina más el aspecto del producto que cualquier otra que tomes.
Los tres son problemas de valores y vocabulario, no de selectores. De ahí el desplazamiento.
Qué es un token, y qué no
Un token de diseño es una decisión de diseño con nombre, almacenada de forma que no dependa de una tecnología concreta. El término salió del sistema de diseño de Salesforce a mediados de la década de 2010, en un contexto muy específico: el mismo producto se construía en web, en iOS y en Android, y el color de marca estaba escrito tres veces en tres lenguajes distintos, con tres procesos de actualización que se desincronizaban.
La respuesta fue sacar el valor de todos ellos y ponerlo en un origen neutral —hoy normalmente un fichero JSON, con un formato que estandariza un grupo de trabajo del W3C— desde el que se generan las representaciones de cada plataforma.
{
"color": {
"marca": {
"600": { "$type": "color", "$value": "oklch(0.55 0.18 265)" }
}
},
"espaciado": {
"3": { "$type": "dimension", "$value": "0.75rem" }
}
}De ahí sale una custom property para web, una constante de Swift para iOS y un recurso XML para Android. Y aquí está la distinción que casi nadie hace explícita: una custom property es el mecanismo; un token es la decisión. Puedes tener custom properties sin tener tokens —si cada componente inventa las suyas y nadie las coordina— y puedes tener tokens sin custom properties, si tu único destino es un lenguaje que no las tiene.
En CSS la implementación es directa, y su forma completa en tres niveles es el contenido del nivel 52:
@layer tokens {
:root {
--marca-600: oklch(0.55 0.18 265);
--espaciado-3: 0.75rem;
}
}El error más común al adoptar tokens es volcar todos los valores del diseño en :root y dar el trabajo por hecho. Eso produce cuatrocientas variables sin jerarquía donde nadie sabe cuál usar, y el equipo acaba eligiendo por parecido de nombre. Un sistema de tokens necesita niveles —qué es un valor bruto, qué es un significado, qué es una configuración de componente— y necesita una regla clara sobre quién puede usar cada nivel. Sin eso solo has cambiado dónde está el desorden.
Por qué se movió el centro de gravedad
El desplazamiento de los selectores a los valores no es una moda; tiene tres causas concretas y merece la pena verlas porque explican también hacia dónde va lo que viene.
El motor absorbió el problema de los selectores. Cuando el ámbito, el orden y la especificidad los garantiza el lenguaje, ya no hay nada interesante que decidir ahí. La discusión se apaga porque el problema se resolvió.
Los componentes absorbieron el problema de la reutilización. La razón principal por la que una clase tenía que ser reutilizable era que el marcado se repetía a mano. Con componentes, la unidad de reutilización es el componente, y la clase deja de tener que serlo. Buena parte de la elaborada teoría de nombres de las metodologías clásicas resolvía un problema que hoy resuelve la plantilla.
El diseño se volvió multiplataforma y multitema. Un producto de 2026 tiene, como mínimo, modo claro y modo oscuro; a menudo densidades, marcas blancas o temas de accesibilidad. Cada uno de ellos es un conjunto distinto de valores sobre la misma estructura. Un sistema organizado alrededor de valores nombrados soporta eso cambiando asignaciones; uno organizado alrededor de reglas por tema multiplica el CSS.
Y hay un cuarto factor, más silencioso: los tokens son el único artefacto que diseño y desarrollo comparten literalmente. La herramienta de diseño y la hoja de estilos pueden leer el mismo fichero. Ninguna metodología de selectores tuvo jamás esa propiedad, porque a nadie que diseñe le importa cómo se llame tu clase.
El malentendido que hunde la mitad de los sistemas de tokens es tratarlos como un diccionario de valores en lugar de como una capa de indirección con semántica. Si tu token se llama --azul-500, has puesto un nombre a un color y no has ganado casi nada: el día que la marca cambie a verde tendrás una variable llamada azul que contiene verde, o una migración que toca todos los ficheros. Si se llama --color-accion-primaria, has puesto un nombre a una decisión, y el valor puede cambiar sin que ninguna otra cosa cambie. La diferencia parece cosmética y no lo es: determina si el sistema absorbe los cambios de diseño o los propaga. Y de ahí sale el criterio que resuelve la discusión eterna sobre cuántos niveles de token hacen falta, que verás desarrollada en el nivel 52. El nivel primitivo existe para que los valores brutos tengan un sitio y no se repitan; el nivel semántico existe para que el resto del sistema no dependa nunca de un valor bruto; y el nivel de componente existe para que un componente concreto pueda desviarse sin que su desviación se convierta en una regla global. Si te saltas el nivel semántico y los componentes consumen primitivos, no tienes un sistema: tienes una hoja de estilos con los colores movidos a :root, y el primer rediseño te lo va a demostrar. La prueba definitiva es sencilla y la puedes hacer hoy: intenta cambiar el color de marca de tu proyecto tocando una sola línea. Si puedes, tienes tokens. Si no, tienes variables.