- Permite renderizar elementos del DOM directamente en contextos de Canvas 2D, WebGL y WebGPU.
- Mantiene la interactividad nativa, la accesibilidad para lectores de pantalla y la indexación de motores de búsqueda.
- Elimina la necesidad de usar librerías externas de capturas de pantalla para integrar interfaces web en entornos gráficos complejos.
Durante muchísimo tiempo, quienes nos dedicamos al desarrollo web nos hemos visto obligados a elegir entre dos caminos bastante cerrados cuando montábamos aplicaciones visuales potentes. O nos apoyábamos en el DOM para aprovechar su estructura semántica y accesibilidad, o nos lanzábamos de cabeza al elemento canvas para ganar un rendimiento bruto en gráficos de bajo nivel. Básicamente, era elegir entre comodidad estructural o potencia visual, sin término medio.
Pero aquí es donde entra en juego la API experimental de HTML-in-Canvas, que ya está disponible mediante pruebas de origen. Esta herramienta es una auténtica joya porque nos permite pintar contenido del DOM directamente en un canvas 2D o incluso en texturas de WebGL y WebGPU, pero con un detalle brutal: la interfaz sigue siendo interactiva y accesible. Ya no hace falta elegir bando, porque ahora podemos fusionar lo mejor de los dos mundos para crear experiencias que hasta hace nada eran sencillamente imposibles de programar.
El eterno dilema: DOM frente a Canvas
Para entender por qué esto es un cambio de paradigma, hay que mirar qué aporta cada uno. El DOM es el pilar de la web; nos da soluciones de maquetación de texto ya listas y permite que el usuario haga cosas naturales, como seleccionar texto para copiarlo o hacer clic derecho en una imagen para guardarla. Además, se lleva de lujo con herramientas de accesibilidad, el modo lectura, las extensiones del navegador y el zoom.
Por otro lado, el Canvas (y sus hermanos mayores WebGL y WebGPU) nos da el control total sobre cada píxel, algo vital para juegos o aplicaciones pesadísimas como Figma o Google Docs. El problema es que, al ser básicamente una rejilla de píxeles, cualquier cosa que pongamos dentro queda atrapada en una imagen estática. Si querías un texto adaptable, tenías que programar toda la lógica desde cero, lo que hinchaba el tamaño del código y rompía por completo cualquier función nativa del navegador.
¿Qué ganamos al meter el DOM en el Canvas?
La API de HTML-in-Canvas actúa como ese puente necesario. Al colocar HTML dentro del canvas y sincronizar su transformación, conseguimos que el contenido sea plenamente interactivo. Entre las ventajas más destacables tenemos un maquetado de texto simplificado, incluyendo soporte para idiomas bidireccionales o varias líneas mediante CSS, sin complicaciones.
Además, los controles de formulario funcionan de maravilla y son mucho más fáciles de personalizar. Pero lo más potente es que el contenido renderizado en el canvas se expone al árbol de accesibilidad, permitiendo que los lectores de pantalla interpreten la interfaz. Incluso el buscador nativo del navegador (Ctrl+F) puede localizar y resaltar texto que está dibujado dentro de una textura de WebGL, algo que suena a magia pero que ahora es realidad.
Tampoco podemos olvidar que los rastreadores web y los agentes de IA pueden indexar el contenido, y que las extensiones del navegador funcionan de forma nativa. Por ejemplo, si tienes una extensión que traduce palabras, esta actualizará el texto renderizado en tus mallas 3D automáticamente. Incluso desde las DevTools de Chrome podemos inspeccionar y cambiar estilos CSS en tiempo real y ver cómo afectan a la textura 3D.
Casos de uso y aplicaciones reales
Esta tecnología abre puertas increíbles. Para aplicaciones basadas en canvas muy pesadas, permite renderizar componentes de interfaz complejos de forma nativa, lo que reduce el peso del bundle y mejora la accesibilidad. En el mundo de los videojuegos y la WebXR, es oro puro: podrías crear un libro en 3D cuyas páginas sean HTML real o una terminal de comandos dentro de un juego que permita copiar y pegar texto nativamente.
Implementación técnica: Paso a paso
Actualmente, la API se encuentra en una fase temprana (Chrome 148-150). Para probarla, hace falta usar Chrome Canary y activar el flag chrome://flags/#canvas-draw-element. El proceso de uso se divide en tres fases principales.
1. Configuración del Canvas
Lo primero es añadir el atributo layoutsubtree (o content="drawable" en versiones más recientes como Chrome 157+) a la etiqueta canvas. Esto avisa al navegador que hay elementos anidados que deben participar en el maquetado. Para evitar que el contenido se vea borroso, es fundamental ajustar la rejilla del canvas al factor de escala del dispositivo usando un ResizeObserver.
2. El proceso de renderizado
En un contexto 2D, utilizamos el método drawElementImage dentro del evento onpaint. Este evento se dispara cada vez que el elemento necesita redibujarse, por ejemplo, cuando el usuario resalta un texto. Para WebGL, la función equivalente es texElementImage2D, y para WebGPU se emplea copyElementImageToTexture. En los tres casos, el objetivo es trasladar el DOM a una textura o superficie gráfica.
3. Sincronización de la transformación CSS
Este es el punto donde muchos fallan. Una vez renderizado el elemento, hay que decirle al navegador dónde está físicamente en la pantalla para que los clics y los hovers funcionen. En 2D, aplicamos la transformación devuelta por el método de dibujo a la propiedad style.transform del elemento. En 3D es más complejo, ya que requiere convertir la matriz MVP de WebGL a una matriz DOM, normalizar el elemento y mapearlo al viewport del canvas.
Soporte de librerías y limitaciones
Afortunadamente, no tenemos que hacer todo a mano. Three.js ya ha implementado soporte experimental a través de THREE.HTMLTexture, encargándose de la sincronización pesada. PlayCanvas también permite asignar fuentes HTML a sus texturas a través de su propia API. No obstante, hay que tener en cuenta que, por seguridad, la API no funciona con contenido de iframes de otros dominios (cross-origin).
Otra limitación importante es que el desplazamiento (scrolling) y las animaciones dentro del canvas dependen de JavaScript. Esto significa que no pueden actualizarse de forma independiente al hilo principal, por lo que hay que vigilar el rendimiento al meter contenido con scroll dentro de un canvas.
Privacidad y Seguridad
El sistema está diseñado para no filtrar información sensible. El proceso de pintado excluye datos de dominios externos, colores del sistema, marcadores de ortografía o información de enlaces visitados. Lo que sí se permite es el resaltado de búsquedas internas y el aspecto de los scrollbars, ya que esto no compromete la privacidad del usuario.
Esta innovadora arquitectura permite que el contenido HTML sea tratado como una imagen dinámica pero inteligente. Al integrar el flujo de renderizado del navegador con la potencia de la GPU, se soluciona el problema de la accesibilidad en entornos gráficos y se simplifica drásticamente la creación de interfaces complejas en 3D, logrando que la web sea más inclusiva y visualmente impactante sin sacrificar la funcionalidad nativa.