Tres motores, tres calendarios

A qué está atado cada motor

La lectura de la tabla es incómoda y es la correcta: Windows es la plataforma más previsible de las tres, que no es lo que la mayoría espera. macOS es aceptable si aceptas soportar solo versiones recientes del sistema. Linux es donde vive el problema, y por eso tiene su propio nivel.

El mínimo común

Como tu interfaz es una sola, lo que puedes usar es la intersección de los tres. Y la intersección la marca casi siempre el motor más rezagado, que en la práctica es WebKitGTK en una distribución de soporte largo.

Esto tiene una consecuencia de planificación que conviene tomar en serio desde el primer día: la lista de plataformas y versiones que soportas es una decisión de producto, no un detalle técnico, y hay que escribirla antes de elegir el stack del frontend.

Soportamos:  macOS   14 y superiores           → el motor de esa generación en adelante  Windows 10 22H2 y superiores      → WebView2, al día  Linux   las distribuciones X e Y  → el WebKitGTK que empaquetenTodo lo que use la interfaz tiene que existir en los tres.

Sin esa lista escrita, la pregunta «¿puedo usar esta característica de CSS?» no tiene respuesta y se contesta por optimismo, que es como se llega a producción con un fallo que solo aparece en la máquina de un usuario.

La regla que lo evita

Es una sola y es aburrida: prueba en las tres plataformas desde la primera semana, en integración continua, con la pantalla más difícil que tengas.

No al final. No cuando esté todo. La primera semana, cuando cambiar de decisión todavía es barato. Si tu vista principal necesita una característica que WebKitGTK no tiene, quieres saberlo antes de construir el producto encima, no después.

Las tres clases de fallo

No todos los problemas de fragmentación son iguales, y cada uno se ataca distinto.

1 · La característica no existe. Una función de CSS o una API de JavaScript que un motor no implementa. Es el caso benigno: se detecta con una comprobación de disponibilidad y se degrada. La disciplina es no dar nada por supuesto y tener una lista escrita de lo que se usa.

// Comprobar, no suponer. Y degradar a algo que funcione, no a un hueco.if (CSS.supports('anchor-name: --x')) {  // el posicionamiento anclado} else {  // la alternativa que funciona en los tres}

2 · La característica existe y se comporta distinto. Es el caso malo, porque no hay comprobación que lo detecte. Diferencias sutiles en la disposición, en el redondeo de subpíxeles, en cómo se resuelve un contenedor flexible cuyo contenido desborda, en el orden en que llegan dos eventos. Se cazan probando, y solo probando.

3 · El motor tiene un fallo. El caso peor: no es que tu código esté mal ni que la característica falte, es que el motor está roto. No se puede arreglar; solo esquivar, documentar el rodeo y esperar a una versión futura que quizá el usuario nunca instale. El nivel 3.4 tiene ejemplos reales.

Lo que sí puedes dar por supuesto

Para terminar en positivo, porque la lista de lo que funciona en los tres es larga y crece:

• El grueso de la disposición moderna: flexbox y grid, con sus variantes anidadas.
• Propiedades personalizadas de CSS, que es lo que hace posible tematizar sin recompilar nada.
• Las consultas de contenedor, que llevan tiempo en los tres.
• El JavaScript moderno: módulos, async/await y la biblioteca estándar del lenguaje.
• IndexedDB, fetch, y los observadores de intersección y de redimensionado.
• SVG, canvas y las fuentes web.

Con eso se construye la inmensa mayoría de una interfaz de aplicación. Lo que hay que vigilar son las adquisiciones recientes —lo que todavía se anunciaba como novedad hace poco— y todo lo que dependa de la GPU, que es donde Linux hace más ruido.