Hacia dónde va el gráfico 2D en la web
Lo que ya está cerrado, lo que CSS le ha quitado a SVG y al lienzo, el estancamiento de SVG 2, la rasterización en la GPU, y qué parte de lo aprendido sobrevive a cualquier cambio.
Cerrar un track con predicciones es una mala idea, así que este artículo separa tres cosas que suelen mezclarse: lo que ya está resuelto y no va a cambiar, lo que se está moviendo ahora mismo con evidencia de por dónde, y lo que lleva una década anunciándose sin llegar. Y termina con la única apuesta segura, que es la que llevas construyendo desde el nivel 26.
- Distinguir lo consolidado de lo que está en movimiento en el gráfico 2D.
- Identificar qué trabajo ha pasado de SVG y del lienzo a CSS.
- Situar el estado real de SVG 2 y de las propuestas que no llegaron.
- Decidir qué parte de una arquitectura de visualización sobrevive a un cambio de renderizador.
Lo que ya está cerrado
Hay un conjunto de cosas que a estas alturas se pueden dar por seguras y sobre las que se puede construir sin condicionales.
El lienzo 2D está acelerado por GPU en todos los navegadores y lo lleva estando años. La discusión sobre si el lienzo es «software» y WebGL «hardware» dejó de tener sentido hace tiempo: el contexto 2D delega en el mismo rasterizador que el resto de la página.
OffscreenCanvas está disponible en los tres motores, así que dibujar en un worker dejó de ser una técnica exótica. Para un gráfico con cien mil marcas y un hilo principal ocupado, mover el dibujado fuera es una opción real y no un experimento.
Path2D es universal, y con él la posibilidad de construir geometría una vez y reutilizarla, de aceptar cadenas de d de SVG en un lienzo, y de hacer hit testing exacto contra un objeto.
WebGPU está en los tres motores por defecto desde que Safari 26 lo implementó en septiembre de 2025. Eso cierra una discusión de años sobre el techo del 2D: cuando el lienzo no llega, hay un escalón siguiente disponible en todas partes, y no solo en Chromium. WebGL2 sigue siendo la base más segura por cobertura de dispositivos antiguos, así que el enfoque correcto es mejora progresiva y no sustitución.
El estándar CSS de color moderno está en los cuatro motores: OKLCH, color-mix, y con ellos la posibilidad de generar rampas perceptualmente decentes sin biblioteca. Para la visualización de datos eso es más importante de lo que parece, porque resuelve el problema del punto medio sucio de las interpolaciones en sRGB.
Lo que CSS le ha quitado a SVG y al lienzo
Esta es la tendencia más clara de los últimos años y la que más código elimina.
Recortes, máscaras y filtros son propiedades CSS. clip-path, mask y filter aplican a cualquier elemento, con las mismas primitivas que ya conoces de recortar y enmascarar desde CSS. Muchos efectos que hace cinco años exigían un SVG con defs ahora son una declaración.
Las container queries hacen responsivos los gráficos de verdad. Un gráfico no debe adaptarse al ancho de la ventana sino al de su contenedor, y hasta que existieron las consultas de contenedor eso obligaba a un ResizeObserver con JavaScript. Ahora la parte de estilo (ocultar etiquetas, cambiar orientación, reducir el número de series visibles) se puede escribir en CSS, y el observador queda solo para lo que de verdad necesita recalcular geometría.
Las transiciones de vista de mismo documento están disponibles desde 2025 y permiten animar el cambio entre dos estados de una interfaz, incluido el cambio entre dos configuraciones de un gráfico, sin escribir la interpolación. Las transiciones entre documentos están llegando durante 2026 y todavía no son universales.
El posicionamiento de anclaje resuelve el problema clásico del tooltip de un gráfico: colocar un elemento junto a otro sin calcular coordenadas a mano ni preocuparse por los bordes de la ventana. Entró en Baseline cuando Firefox lo implementó en enero de 2026, con un matiz que hay que respetar: @position-try, que es la parte que reubica el tooltip cuando no cabe, requiere Safari 18.4 o superior. Con detección de características, es una simplificación enorme frente al cálculo manual de posición.
Y una que hay que tratar con cuidado: las animaciones dirigidas por scroll, que son la base de las visualizaciones narrativas que avanzan al desplazarse, están solo en Chromium y en Safari. Firefox no las ha implementado. Cualquier uso serio necesita detección y una alternativa:
@supports (animation-timeline: scroll()) {
.paso { animation: aparecer linear both; animation-timeline: view(); }
}Sin ese @supports y sin un estado por defecto legible, el contenido queda invisible en Firefox.
Lo que lleva una década sin llegar
Conviene ser igual de claro con lo que no ha ocurrido, porque hay mucha documentación que lo presenta como inminente.
SVG 2 no llegó como especificación completa. Partes se implementaron, otras se abandonaron. Los gradientes de malla nunca se enviaron en ningún motor. El valor arcs de stroke-linejoin tampoco. Lo que se usa en producción sigue siendo, en la práctica, SVG 1.1 más las propiedades de CSS que se le han ido añadiendo, y esa combinación funciona muy bien. No esperes una versión 2 que reordene el territorio.
La API de pintado de Houdini es solo de Chromium. La idea de escribir un worklet que pinte un fondo programáticamente era elegante y no ha conseguido implementación en los otros motores. Para un gráfico, además, nunca fue la herramienta adecuada: no tiene acceso al DOM ni a datos externos.
La propiedad d en CSS, que permitiría animar la forma de una ruta desde una hoja de estilos, tiene soporte desigual entre motores. Antes de usarla, compruébalo, y ten preparada la alternativa de animar el atributo desde JavaScript.
El texto multilínea en el lienzo sigue sin existir. No hay ninguna API de composición de párrafos en el contexto 2D: hay que medir palabra a palabra y colocar líneas a mano. Ha habido propuestas y ninguna ha llegado. Es probablemente el hueco más molesto que queda en la API.
Lo que sí se está moviendo
Dos movimientos con sustancia, presentados con la cautela que merecen.
La rasterización de vectores en la GPU mediante cómputo. Tradicionalmente, convertir una ruta en píxeles lo hace la CPU y el resultado se sube como textura. Hay una línea de trabajo activa, tanto en los motores de los navegadores como en proyectos independientes, que mueve ese trabajo a shaders de cómputo, lo que aprovecha el paralelismo para rutas complejas y muchos elementos. Con WebGPU disponible en los tres motores, ese enfoque deja de ser académico. Lo que significa para ti a corto plazo es poco; lo que significa a medio es que el techo del gráfico vectorial en la web va a subir sin que cambies de API.
La capa declarativa por encima. La tendencia de la última década en visualización no ha sido hacia APIs más bajas, sino hacia gramáticas: describir un gráfico como una especificación de datos, codificaciones y transformaciones, y dejar que una biblioteca decida el marcado. Es exactamente la misma idea que la capa cinco de la arquitectura de un sistema de visualización, llevada un nivel más arriba: si el gráfico es un objeto de datos, se puede guardar, versionar, compartir, generar por programa y validar con un esquema.
Esa propiedad ha ganado importancia por una razón nueva: un gráfico descrito como datos es algo que un sistema automático puede producir y verificar, y uno descrito como cien líneas de manipulación del DOM, no. Independientemente de lo que se piense sobre la generación automática de código, la conclusión de ingeniería es la misma que llevas leyendo cuatro artículos: la especificación es el activo, el renderizador es un detalle.
Repasa lo que ha cambiado en el gráfico 2D en la web en los últimos diez años: el lienzo se aceleró, apareció OffscreenCanvas, WebGL2 se generalizó, llegó WebGPU, CSS absorbió los filtros y las máscaras, los frameworks pasaron de manipular el DOM a declararlo, y la biblioteca dominante de visualización cambió su forma de uso recomendada.
Y ahora piensa qué parte de un gráfico bien escrito habría habido que tocar en cada uno de esos cambios. Solo el renderizador. El cálculo del dominio, la elección de la escala, el algoritmo de marcas bonitas, la geometría de las barras, la decisión de qué canal codifica qué: nada de eso ha cambiado, porque no depende de la tecnología. La fórmula de la escala de banda es la misma que en 2011 y va a ser la misma en 2036.
Esa observación es la que convierte la arquitectura de este nivel de una preferencia de estilo en una apuesta con retorno medible. La capa cinco es el activo de larga duración y las capas seis son consumibles. Escribir un renderizador nuevo sobre una especificación existente son doscientas líneas y una tarde. Extraer una especificación de tres gráficos que mezclan cálculo y dibujo son semanas, y se hace mal porque hay que hacerlo con el código funcionando.
Tres consecuencias prácticas para los próximos años:
Cuando aparezca la siguiente tecnología de dibujo, no reescribas el gráfico: escribe un renderizador. Y si eso no es posible, ya sabes qué estaba mal.
Cuando dudes entre invertir en la parte de cálculo o en la de dibujo, invierte en la de cálculo. Un formateador de números correcto, un algoritmo de marcas que respete la magnitud, un tratamiento honesto de los huecos: eso se amortiza en todos los renderizadores que escribas nunca. Un efecto visual precioso se amortiza en uno.
Cuando evalúes una biblioteca, mira si te deja quedarte con la especificación. Las que te dan números y te dejan dibujar sobreviven a tus cambios de framework. Las que te dan componentes te atan a los suyos. Es exactamente la lección del nivel 28 generalizada a cualquier dependencia.
Y para cerrar treinta y un niveles con lo único que de verdad hace falta recordar: el gráfico no es el dibujo, es la decisión. Qué dato, en qué canal, con qué escala, contra qué referencia. El dibujo es la parte que la máquina hace, y a estas alturas la sabes hacer de las cuatro maneras. La otra parte no la hace la máquina, no la ha cambiado ninguna tecnología de esta lista, y es la que distingue un gráfico que informa de uno que solo ocupa espacio.
Coge tu gráfico más antiguo en producción y responde a una pregunta: si mañana tuvieras que renderizarlo con una tecnología distinta, ¿cuánto código tendrías que tocar? Cuenta las líneas. Ese número es la medida exacta de cuánto de tu trabajo es activo y cuánto es consumible, y es el mejor indicador que vas a tener de si la arquitectura de este nivel está de verdad en tu proyecto o solo en tus notas.