Detectar una declaración con @supports

CSS lleva degradando desde 1996 sin que nadie escriba una condición: el analizador tira al suelo cualquier declaración que no entiende y se queda con la anterior. Ese mecanismo es tan bueno que la mayoría de las veces no necesitas nada más. @supports existe porque falla en dos casos muy concretos, y entender cuáles son es lo que separa usarlo bien de rodearlo todo de condiciones inútiles.

El fallback que ya tenías

Cuando el analizador de CSS encuentra una declaración cuyo valor no sabe interpretar, la descarta entera y sigue. No aborta la regla, no ignora el bloque: elimina esa línea como si nunca se hubiera escrito. De ahí sale el patrón más viejo del lenguaje.

.panel {
  width: 40rem;
  width: min(40rem, 100%);
}

Un motor sin min() se queda con la primera línea. Uno moderno aplica la segunda porque llega después y gana por orden de aparición. No hay condición, no hay detección y no hay coste: el propio orden de la cascada hace de estructura de control.

Ese mecanismo tiene exactamente dos agujeros.

El primero: no puede descartar un grupo. Si una mejora consiste en cinco declaraciones que solo tienen sentido juntas, el analizador va a quedarse con las cuatro que entiende y tirar la quinta, y eso puede ser peor que no aplicar ninguna. Un position: sticky sin su top, o un display: grid con gap pero sin las pistas, dejan la interfaz en un estado intermedio que nadie ha diseñado.

El segundo: no puede condicionar una propiedad distinta. El descarte solo actúa sobre la declaración que no entiende. Si quieres decir “cuando exista :has(), quítale el padding a este otro elemento”, no hay forma de expresarlo con orden de declaraciones, porque el padding es válido en todos los navegadores y ninguno lo va a descartar.

@supports cubre esos dos agujeros y nada más. Cualquier uso que no caiga en uno de ellos probablemente sea ruido.

Cómo evalúa el motor la condición

La forma canónica lleva una declaración completa entre paréntesis:

@supports (display: grid) {
  .rejilla { display: grid; }
}

El navegador coge lo que hay dentro de los paréntesis, lo analiza como si fuera una declaración dentro de un bloque de estilo vacío y responde a una sola pregunta: ¿la conservaría o la descartaría? Si la conservaría, la condición es verdadera. No aplica nada, no mira ningún elemento, no consulta el layout. Es una pregunta sobre el analizador.

De ahí salen tres consecuencias que conviene tener grabadas.

La propiedad sola no vale. @supports (rotate) no pregunta si existe la propiedad rotate: no es una declaración, así que cae en la producción de general enclosed de la gramática, que la especificación define como “sintaxis futura desconocida” y obliga a evaluar como falso. No es un error de análisis y no rompe nada; simplemente siempre da negativo. Si escribes eso pensando que detectas la propiedad, obtienes el camino de fallback en todos los navegadores del mundo, incluidos los que la soportan.

Los paréntesis son obligatorios. @supports display: grid no es válido. Y cuando combinas condiciones, cada una lleva los suyos.

El valor importa tanto como la propiedad. Esta es la parte útil: como la pregunta es sobre la declaración completa, puedes detectar valores concretos de propiedades que existen desde siempre.

@supports (height: 100dvh)                      { }
@supports (width: 1lh)                          { }
@supports (color: color(display-p3 1 0 0))      { }
@supports (background: linear-gradient(in oklch, red, blue)) { }
@supports (animation-timeline: scroll())        { }

Ese es el mecanismo real para detectar unidades, funciones de color, espacios de interpolación y palabras clave nuevas: metes la novedad dentro de una propiedad que la acepte y preguntas por la declaración entera.

Elegir bien la declaración de prueba

Como la respuesta depende de qué escribas dentro de los paréntesis, la calidad de la detección es la calidad de la pregunta. Dos errores frecuentes.

Preguntar por algo más antiguo que lo que quieres. Detectar una característica preguntando por una propiedad relacionada que llegó antes produce falsos positivos permanentes. La propiedad relacionada existe, la condición da verdadero, y la característica que de verdad te importaba no está.

Preguntar por algo que el navegador acepta y tira. Algunos valores se analizan y luego se ignoran en el contexto concreto donde los usas. La declaración de prueba tiene que ser la misma que vas a escribir después, con el mismo valor. Si vas a usar grid-template-columns: subgrid, pregunta por eso exactamente, no por display: grid.

La regla práctica: la condición debe ser la declaración más específica del bloque que protege. Si dentro del bloque hay una línea que es la que de verdad no existía antes, esa es la que va entre paréntesis.

/* mal: la condicion es mas vieja que la mejora */
@supports (display: grid) {
  .tarjeta > * { grid-template-columns: subgrid; }
}

/* bien: pregunta por lo que de verdad usas */
@supports (grid-template-columns: subgrid) {
  .tarjeta > * { grid-template-columns: subgrid; }
}

La misma pregunta desde JavaScript

CSS.supports() usa el mismo evaluador y admite dos firmas.

// dos argumentos: propiedad y valor, sin parentesis
CSS.supports('display', 'grid');              // true

// un argumento: una condicion completa, con parentesis
CSS.supports('(display: grid)');              // true
CSS.supports('(display: grid) or (display: flex)');
CSS.supports('selector(:has(a))');
CSS.supports('not (width: 1foo)');            // true

La firma de dos argumentos es la más segura porque no tienes que preocuparte de la gramática de condiciones; la de un argumento es la única que permite combinaciones y funciones como selector().

El uso legítimo es decidir en JavaScript si merece la pena cargar un polyfill o registrar un observador. El uso ilegítimo, y muy común, es replicar en JS una decisión que el CSS ya habría tomado solo: si el navegador va a descartar la declaración de todas formas, no necesitas preguntarle antes.