Hacia dónde va el lenguaje
if(), las consultas de estilo que faltan, la mampostería resuelta como Grid Lanes, y las funciones que Chromium ya envía: qué es real en agosto de 2026 y qué sigue siendo una promesa.
El horizonte de CSS está lleno de cosas que se anuncian tres años antes de poder usarse, y distinguir lo implementado de lo especificado de lo meramente discutido es una habilidad práctica, no una curiosidad. Esto es el estado real en agosto de 2026: qué ha llegado, en cuántos motores, y qué sigue siendo una promesa. Las fechas importan más que las descripciones.
- Escribir condicionales en línea con
if()y saber en qué motores funcionan. - Conocer qué partes de las consultas de estilo siguen sin implementar en ningún sitio.
- Usar el modo de layout que resolvió la mampostería y su estado de soporte.
- Distinguir lo que está en un motor de lo que está en la especificación.
if(): condicionales dentro de un valor
if() permite elegir el valor de una propiedad según una condición, sin escribir una regla aparte. La condición puede ser una consulta de estilo, una media query o una consulta de soporte, y las ramas se separan con punto y coma:
.aviso {
background-color: if(
style(--tono: peligro): oklch(0.58 0.2 25 / 0.1);
style(--tono: exito): oklch(0.62 0.15 150 / 0.1);
else: transparent
);
}Lo que esto resuelve es concreto y llevaba años pendiente: con style() dentro de if() puedes estilar el propio elemento en función de una custom property suya, mientras que una consulta de estilo clásica solo puede afectar a los descendientes de un contenedor. Es la diferencia entre necesitar un envoltorio y no necesitarlo.
Estado en agosto de 2026: disponible en Chromium desde Chrome 137, en junio de 2025. Firefox lo tiene en desarrollo y Safari lo tiene en su hoja de ruta. Un motor de cuatro en estable.
La consecuencia práctica es que hoy es una mejora, no una herramienta. El patrón correcto es escribir el valor por defecto y añadir if() detrás, aprovechando que una declaración con sintaxis desconocida se descarta:
.aviso { background-color: transparent; }
.aviso { background-color: if(style(--tono: peligro): oklch(0.58 0.2 25 / 0.1); else: transparent); }Las consultas de estilo que siguen faltando
Las consultas de estilo sobre custom properties llegaron a los cuatro motores en 2026 y ya se pueden usar con la cautela propia de lo recién disponible. Pero la especificación describe dos capacidades más que no ha implementado nadie, y conviene saberlo porque circulan en artículos y demos desde 2022:
Consultar propiedades estándar. @container style(font-style: italic) está en la especificación desde el principio y no funciona en ningún navegador.
Comparaciones de rango. @container style(--nivel > 3) requeriría que la propiedad estuviera registrada con un tipo numérico y que el motor supiera compararla. Tampoco está implementado.
Cuando esas dos partes lleguen, las consultas de estilo pasarán de ser un mecanismo útil para variantes a ser un sistema de estilado condicional completo. Mientras tanto, lo que hay son variantes por custom property, que ya es bastante.
La mampostería, por fin resuelta
El patrón de mampostería —piezas de alturas distintas que se empaquetan en columnas, sin que las filas se alineen— fue durante años el hueco más visible del layout en CSS. Se hacía con bibliotecas de JavaScript, con column-count a costa de romper el orden de lectura, o con trucos de Flexbox que casi funcionan.
El grupo de trabajo pasó años debatiendo si debía ser una extensión de Grid o un módulo aparte, con propuestas sucesivas que llegaron a implementarse tras banderas. La resolución llegó a comienzos de 2026 con un modo de layout propio, y Safari 26.4 lo envió el 24 de marzo de 2026:
.galeria {
display: grid-lanes;
grid-template-columns: repeat(auto-fill, minmax(220px, 1fr));
gap: 12px;
}Tres líneas. display: grid-lanes cambia el modo de layout, grid-template-columns define las calles con la misma gramática de pistas de Grid —fr, minmax(), auto-fill, repeat()— y gap separa. Cambiando grid-template-columns por grid-template-rows el resultado pasa de cascada vertical a muro horizontal. Se elige un eje, no los dos.
Lo interesante para quien ha llegado hasta aquí no es el efecto visual sino el problema que resolvieron por el camino. La mampostería coloca cada pieza en la calle que la deja más arriba, y eso hace que el orden visual pueda alejarse del orden del documento: dos piezas de alturas casi idénticas producen un zigzag donde el orden de tabulación no coincide con lo que se ve. Es un problema de accesibilidad que las bibliotecas de JavaScript nunca resolvieron.
La solución es una propiedad, flow-tolerance, con valor inicial 1em: antes de mandar una pieza a la calle más corta, el motor comprueba si la diferencia de altura entra dentro de la tolerancia, y si entra, prioriza el orden de lectura. Subir la tolerancia acerca el resultado al orden del documento; bajarla lo acerca al empaquetado óptimo.
Estado en agosto de 2026: en Safari 26.4 y superiores. En Chromium y Firefox, tras una bandera. Es exactamente el caso de una mejora progresiva: sin soporte, display: grid-lanes no se entiende y el contenedor se queda en su display anterior, así que el orden correcto es declarar un grid o un flex razonable antes y grid-lanes después.
Tres preguntas separan una función usable de un titular. ¿En cuántos motores está en la versión estable? Uno significa que puedes experimentar; cuatro significa que puedes adoptar con cautela; cuatro hace treinta meses significa que puedes darla por hecha. ¿Qué ve exactamente quien no la tiene? Si la respuesta es “un diseño menos refinado”, adelante; si es “no se entera de algo”, no era una mejora. ¿Existe detección? @supports cubre pares de propiedad y valor y, con selector(), también selectores; no cubre las at-rules, y eso deja algunos casos sin forma de detectar desde CSS.
Lo que Chromium ya envía y aún no es universal
Durante 2025 y 2026 Chromium ha enviado un conjunto de funciones que todavía no están en los demás motores y que conviene conocer porque cambian patrones enteros cuando lleguen:
Funciones personalizadas con @function. Permiten definir una función CSS propia con parámetros y un valor de resultado. Es lo que los mixins de los preprocesadores hacían en compilación, ahora en el navegador y participando de la cascada.
sibling-index() y sibling-count(). Devuelven la posición del elemento entre sus hermanos y el total. Con eso, escalonar una animación o repartir un ángulo entre elementos deja de requerir una clase por índice o una variable escrita desde JavaScript.
corner-shape. Amplía las esquinas más allá del radio: biselada, muescada, cóncava o cuadrada redondeada al estilo de los iconos de sistema. Elimina una familia entera de trucos con clip-path y máscaras.
reading-flow y reading-order. Controlan el orden de tabulación y de lectura de los hijos de un contenedor flexible o de cuadrícula, que hasta ahora era siempre el orden del documento aunque el visual fuera otro. Es la respuesta a un problema de accesibilidad conocido desde que existe order en Flexbox.
Ninguna de las cuatro es adoptable hoy fuera de un entorno controlado. Todas apuntan en la misma dirección, que es la que conviene retener.
Si ordenas todo lo que ha entrado en CSS desde 2010 y lo miras junto, aparece un patrón tan regular que sirve para predecir. Cada función nueva importante hace una de estas tres cosas, y solo estas tres. Primera: convierte una convención en un mecanismo. @layer absorbió la disciplina de ordenar ficheros, @scope absorbió los prefijos de nombres, :where() absorbió la regla de una sola clase, :user-invalid absorbió la clase de “ya lo ha tocado” que todos escribíamos a mano. Segunda: devuelve al motor información que el modelo le había quitado, para que pueda optimizar. contain y content-visibility son exactamente eso, y por eso su forma es la de un contrato con precio. Tercera: da acceso declarativo a algo que solo se podía hacer con JavaScript. :has(), las container queries, las animaciones dirigidas por scroll, el posicionamiento anclado, field-sizing, el select personalizable: todas retiran una biblioteca del proyecto en lugar de añadir una. Con esas tres direcciones puedes leer cualquier anuncio del grupo de trabajo y saber inmediatamente en qué categoría cae y por tanto qué va a sustituir en tu código. Y hay una implicación más profunda que merece la pena tener presente al decidir dónde inviertes tu tiempo de aprendizaje: como la tercera dirección es una constante, la cantidad de JavaScript que necesita una interfaz típica lleva quince años bajando y va a seguir bajando. Lo que hoy resuelves con una dependencia, dentro de tres años probablemente sea una propiedad; lo que hoy resuelves entendiendo la cascada, el flujo y los contextos de formato lo seguirás resolviendo igual dentro de veinte años. Por eso el reparto sensato de esfuerzo no es cincuenta y cincuenta: el modelo del lenguaje se amortiza siempre y el catálogo de funciones caduca solo.