Te voy a decir algo que llevábamos años esperando en diseño web: CSS ya empieza a tener una función if() de verdad. No es humo, no es otro truco raro con variables, y tampoco significa que mañana puedas reescribir medio front-end como si JavaScript sobrase. Pero sí cambia una cosa importante: ahora puedo tomar decisiones condicionales dentro del propio valor de una propiedad CSS, y eso abre una puerta bastante interesante para interfaces más limpias, más adaptables y con menos remiendos.
La noticia me parece relevante porque toca una frustración vieja. Si alguna vez has querido cambiar un color, un borde, un espaciado o una alineación según una condición muy concreta, seguro que has acabado montando una mezcla de clases auxiliares, custom properties, media queries desperdigadas y algún parche en JavaScript. Funcionar, funciona. Elegante, no siempre.
Qué trae exactamente CSS if()
La idea es sencilla: dentro del valor de una propiedad puedes evaluar una condición y devolver un valor u otro. Según la documentación técnica y la sintaxis que ya recogen MDN y la especificación del W3C, la función puede trabajar con style queries, media queries y feature queries.
Traducido a lenguaje de proyecto real: puedes decidir desde CSS si aplicas un valor porque el viewport cumple una condición, porque una variable tiene cierto valor o porque una característica del navegador está disponible. Eso, para sistemas de diseño, componentes reutilizables y webs con varias capas de personalización, es mucho más útil de lo que parece a primera vista.
Yo no lo veo como un sustituto de JavaScript, sino como una manera de quitarle trabajo cuando la lógica solo afecta a presentación. Y ahí está la clave: presentación. Si lo usas para eso, tiene mucho sentido.
Por qué esto sí le importa a quien diseña y desarrolla webs
En una web corporativa pequeña quizá no notes el cambio hoy mismo. Pero en cuanto trabajas con un diseño que vive en varios contextos, con temas visuales, componentes compartidos o layouts que se adaptan a muchas condiciones, la cosa cambia bastante.
- Reduce CSS repetido, porque no tienes que duplicar tantos bloques solo para cambiar un valor.
- Mejora la legibilidad en ciertos componentes, sobre todo cuando la variación es pequeña y localizada.
- Encaja bien con design tokens y variables personalizadas, algo muy útil si trabajas con sistemas de diseño.
- Permite decisiones más finas sin sacar la lógica del propio punto donde se aplica el estilo.
Puesto simple: si en un componente quiero un fondo, un borde o una separación distintos según el tema activo, prefiero resolverlo cerca de la propiedad antes que repartir la lógica entre cinco selectores. Ahí CSS if() me parece una mejora de verdad, no una función para lucirse en Twitter.
La parte menos sexy: el soporte todavía no acompaña
Aquí viene el matiz importante. La noticia que recogía Techzine apunta que el soporte práctico está hoy ligado sobre todo a Chromium y navegadores basados en Chromium. Eso incluye Chrome y Edge, pero deja fuera una adopción completa en Safari y Firefox. Y si miras la situación general de compatibilidad en Can I use, queda claro que no estamos ante una feature que puedas soltar sin red en cualquier proyecto de cliente.
Por eso yo no lo vendería como “ya puedes diseñar así desde hoy”. No todavía. Si montas una landing experimental, un panel interno o un producto donde controlas bien el navegador objetivo, puedes empezar a probarlo. Si haces una web pública para un negocio que necesita funcionar fino en entornos variados, te toca ir con prudencia.
Cómo usarlo bien sin pegarte un tiro en el pie
Mi recomendación es bastante terrenal. Usa CSS if() de forma progresiva, no como base única del diseño.
- Empieza en mejoras no críticas. Por ejemplo, temas visuales, adornos, ajustes de espaciado o variantes cosméticas.
- Deja un fallback claro. Si el navegador no entiende la función, el diseño tiene que seguir siendo usable.
- No metas lógica de negocio disfrazada de estilo. En cuanto la decisión deje de ser puramente visual, vuelve a JavaScript o a la capa correspondiente.
- Prueba por navegador. Parece obvio, pero con novedades de CSS mucha gente se confía antes de tiempo.
Yo aquí haría una distinción importante. Una cosa es usar una novedad para mejorar un componente cuando el soporte existe, y otra muy distinta es rediseñar una arquitectura CSS entera alrededor de una función que aún no pisa suelo firme en todos los navegadores importantes. Eso ultimo es justo la clase de entusiasmo que luego se paga en horas de QA.
Lo interesante de fondo no es la sintaxis, sino la dirección
Lo que de verdad me llama la atención no es solo el if() en sí, sino hacia dónde empuja la plataforma web. Llevamos un tiempo viendo cómo CSS gana capacidad expresiva sin dejar de ser CSS: container queries, nuevos selectores, mejoras en tipografía, funciones de color más serias, y ahora lógica condicional dentro de valores. Todo eso apunta a una web donde muchas decisiones visuales pueden resolverse mejor en la propia capa de estilos.
Eso, para quien diseña y desarrolla, es una buena noticia. No porque vaya a simplificarlo todo por arte de magia, sino porque permite escribir soluciones más cercanas al problema real. Menos parche, más intención. Y eso se agradece.
Mi lectura, hoy, es esta: CSS if() merece tu atención ya, pero no tu fe ciega. Me parece una función con futuro, especialmente para componentes avanzados y sistemas de diseño, pero aún no la usaría como pilar de una web generalista sin una estrategia clara de compatibilidad.
Fuentes
Si dentro de seis meses tuvieras que rehacer la base CSS de una web con soporte para navegadores mixtos, ¿en qué pieza concreta te atreverías a introducir if() primero: temas, componentes reutilizables o ajustes responsive?