Resumen

  • El primer borrador público W3C de Reglas Condicionales CSS, del 1 de septiembre de 2011, incorporó @supports para supeditar grupos de estilos a la aceptación de una propiedad y un valor. El borrador de septiembre de 2012 desarrolló el mecanismo.
  • La Recomendación Candidata del 4 de abril de 2013 explicó combinaciones con not, and y or. El texto candidato del 13 de enero de 2022 precisó que la respuesta depende de aceptar la declaración con un nivel utilizable de implementación.

Durante mucho tiempo, CSS tuvo una habilidad civilizada: si el navegador encontraba una propiedad desconocida, podía saltársela y seguir. Para un borde decorativo era una solución bastante digna. Una distribución nueva planteaba un problema mayor. Sus anchos, órdenes y posiciones debían viajar juntos. Si un navegador entendía una regla y perdía dos, la página podía acabar como una mudanza en la que llegaron las mesas pero se extraviaron las puertas.

El primer borrador público del W3C, fechado el 1 de septiembre de 2011, propuso tomarle las medidas al candidato. Una regla @supports podía encerrar un bloque completo detrás de una prueba sobre propiedad y valor. El autor preparaba la distribución para la respuesta afirmativa y otra para la negativa. Aquel texto temprano también incluía @document; la verificación de capacidades con @supports fue la pieza que siguió al centro de la Recomendación Candidata de 2013.

La entrevista no pedía una declaración de amor al diseño moderno. Pedía algo verificable: ¿aceptas display: flex? El borrador de 11 de septiembre de 2012 desarrolló una gramática capaz de negar una condición con not, exigir varias con and o admitir opciones con or. El diseñador podía poner a prueba la instrucción necesaria para su composición en vez de adivinar las habilidades del programa por el nombre y el año de su icono.

La Recomendación Candidata de 4 de abril de 2013 mostró por qué un bloque condicional sirve para algo más que presumir de una propiedad nueva. Un ejemplo agrupa las reglas de una disposición flexible y guarda anchos alternativos tras not. Esos anchos podrían perjudicar la primera disposición si se aplicaran junto a ella. El navegador responde a la pregunta; la hoja de estilos aprovecha la respuesta para mantener unidos los elementos de cada plan.

La letra pequeña de la entrevista importa. El texto de 2013 considera compatible una declaración que el procesador acepta en vez de descartarla por un error de análisis, siempre que implemente el valor a un nivel utilizable. La versión de la Recomendación Candidata del 13 de enero de 2022 lo expresa para una declaración dentro de una regla de estilo. Una respuesta positiva tiene un significado técnico concreto. No es una opinión sobre si el menú queda bonito.

La especificación ofrece un ejemplo que pincha la vanidad del entrevistador. Una preferencia de alto contraste del usuario puede sustituir el color visible y, aun así, el navegador sigue admitiendo la propiedad color. También intervienen la cascada y otras reglas. La pregunta de @supports comprueba una capacidad; el resultado en pantalla nace de más decisiones. El candidato puede superar el examen de sintaxis y encontrarse después con un encargo imposible de maquetar con gracia.

Por eso hay que diseñar la alternativa con el mismo cuidado. Un bloque bajo @supports not (...) necesita anchos, orden de lectura y navegación que funcionen por sí mismos. La rama positiva merece una prueba completa con el contenido real. Si un título se ahoga o una tabla se escapa del contenedor, la hoja de estilos tiene un problema de diseño que ninguna entrevista resuelve. Preguntar bien sirve para escoger el plan correcto; luego toca ejecutar un plan que merezca la pena.

En una clase pública del W3C impartida por Bert Bos en WWW2013, la pregunta salió del papel de la especificación. La demostración ejecutable ocultaba primero seis mensajes y mostraba los que correspondían a las respuestas de @supports, incluidas una prueba de display: flex, su negación y una condición con or. La pequeña página enseñaba el mecanismo delante del público. Elegir entre dos diseños completos para una noticia seguía siendo una tarea mayor que encender un mensaje de prueba.

El calendario W3C cuenta cómo maduró la pregunta: primer borrador público en 2011, otro borrador en 2012, texto candidato en 2013 y versión candidata en 2022. Es la historia de una regla y su definición de apoyo, no una estadística sobre cuántos navegadores habían aprobado el examen cada año. CSS acabó con una entrevista breve y bastante justa. El autor conservó la tarea más larga: escribir condiciones útiles y vestir bien ambas respuestas.