HTML in Canvas: DOM interactivo dentro de canvas y WebGL

MundoWin » Tecnología » HTML in Canvas: DOM interactivo dentro de canvas y WebGL

Durante años, quien construía una aplicación web con mucha chicha visual tenía que decidir entre dos caminos: apoyarse en el DOM para aprovechar su semántica, sus formularios y todo el ecosistema del navegador, o lanzarse a dibujar píxeles en un elemento canvas para exprimir la GPU. Esa elección casi siempre dolía. La nueva API experimental HTML-in-Canvas, disponible en prueba de origen, propone algo bastante más interesante: dibujar contenido DOM dentro de un canvas 2D o de una textura WebGL y WebGPU sin convertirlo en una foto muerta. La interfaz sigue siendo interactiva, accesible y conectada a las funciones habituales del navegador.

No estamos ante un truco para incrustar una captura estática ni ante un remedo de lo que ya se podía hacer con soluciones caseras. La gracia está en que el DOM sigue vivo debajo de los píxeles: puedes seleccionar texto, enfocar un campo, usar el corrector, abrir el menú contextual o buscar con Ctrl/Cmd+F dentro de una escena 3D. En Chrome Canary ya se puede probar con una bandera experimental, y existe una prueba de origen para que otros usuarios puedan entrar sin tocar flags. La propuesta es prometedora, pero aún está en pañales y sus detalles pueden cambiar, así que conviene mirarla con ilusión y con los pies en el suelo.

Dos mundos que hasta ahora parecían condenados a entenderse mal

El DOM es el pilar de la interfaz web tal y como la conocemos. Trae de serie composición de texto, estilos CSS, controles de formulario, selección, copiar y pegar, menús contextuales, autocompletado y un montón de integraciones que damos por sentadas. También se lleva bien con la accesibilidad, la traducción automática, el modo lectura, las extensiones, el modo oscuro, el zoom del navegador y la búsqueda dentro de la página. Ese conjunto de funciones es precisamente lo que hace que una web se sienta como una web y no como una imagen con botones pintados.

Canvas, WebGL y WebGPU juegan otra liga. Ofrecen acceso de bajo nivel a una rejilla de píxeles y permiten juegos, visualizaciones 3D, efectos gráficos y aplicaciones muy pesadas como editores o herramientas de diseño. El problema es que un canvas no entiende de semántica ni de texto responsive por arte de magia. Si quieres texto que se adapte, formularios bonitos o internacionalización fina, acabas reimplementando lógica propia, engordando el paquete y perdiendo por el camino un montón de funciones del navegador. Cuando toda la interfaz queda atrapada en una cuadrícula de píxeles, las ayudas del navegador se caen.

La API HTML-in-Canvas tiende un puente entre ambos territorios. Colocas HTML dentro del canvas, sincronizas su transformación y dejas que el navegador siga encargándose de la accesibilidad, el texto y los controles. No se trata de convertir el DOM en una imagen opaca, sino de aprovechar el motor de renderizado del navegador para que el contenido siga siendo contenido. El resultado es una mezcla de libertad gráfica y comportamiento nativo que antes exigía malabarismos importantes.

Lo que ganas cuando el DOM vive dentro del canvas

La lista de ventajas es larga y bastante práctica. No hablamos solo de lucir efectos molones en una demo, sino de resolver problemas reales que aparecen cuando una aplicación basada en canvas empieza a crecer. El DOM se encarga de la interfaz cotidiana mientras tú te concentras en la parte gráfica.

• Composición y formato de texto con estilos CSS, texto multilínea o bidireccional incluido, sin montar un motor tipográfico propio.
• Controles de formulario más expresivos y sencillos de personalizar, con la ventaja de que siguen siendo controles reales.
• Selección de texto, copiar y pegar, y menú contextual nativo incluso dentro de escenas 3D.
• Exposición al árbol de accesibilidad: los lectores de pantalla pueden interpretar la interfaz como HTML normal.
• Búsqueda dentro de la página con resaltado directo sobre texturas WebGL.
• Indexación y lectura por parte de rastreadores y agentes de IA, que pueden extraer el texto de una escena 2D o 3D con mucha menos dificultad.
• Integración con extensiones del navegador, como una extensión que sustituye texto y actualiza lo que se ve en una malla 3D.
• Inspección desde DevTools, incluidos elementos de interfaz dibujados en WebGL o WebGPU, con la posibilidad de retocar CSS y ver el cambio al instante en la textura.

Estas ventajas abren casos de uso muy variados. Las aplicaciones grandes basadas en canvas pueden renderizar componentes de interfaz complejos dentro de su espacio de trabajo sin perder accesibilidad ni cargarse el paquete con soluciones paralelas. Los juegos y las experiencias WebXR pueden colocar paneles interactivos, terminales, libros o menús dentro de una escena 3D usando texto DOM de verdad. La frontera entre una web rica y un escenario inmersivo se vuelve mucho más difusa.

Cómo se activa y por qué hay dos nombres rondando

La API se está probando en Chrome 148 a 150 mediante prueba de origen. Para experimentar en local, la vía rápida es usar Chrome Canary 149 o superior y activar la bandera chrome://flags/#canvas-draw-element. Para que otros usuarios puedan probarla en un sitio real hace falta registrarse en la prueba de origen. Ojo, porque estamos ante una fase temprana: los nombres, los detalles y el comportamiento pueden moverse antes de que la cosa se estabilice.

De hecho, en la documentación conviven dos formas de contarlo. La explicación más madura habla de un atributo content en el canvas con valores fallback y drawable, y de un atributo drawable en los descendientes que quieres pintar. La versión más práctica de la prueba de origen habla de layoutsubtree en la etiqueta canvas. La idea de fondo es la misma: indicar al navegador que los hijos del canvas no son simple contenido de respaldo, sino contenido que participa en el diseño y que puede dibujarse después. No conviene aprenderse una sola variante como si fuera verdad absoluta.

Cuando el canvas entra en modo dibujable, sus descendientes directos se bloquean y se colocan con posicionamiento estático. El elemento drawable implica aislamiento y actúa como bloque contenedor para sus descendientes. Los elementos drawable pueden anidarse, y el subárbol dibujable de uno excluye a los drawable que tenga dentro y a sus respectivos subárboles. En la versión con content=drawable, esos descendientes se comportan como DOM normal a efectos de accesibilidad y respetan cosas como aria-hidden=true, aunque al principio no tengan información de geometría. La geometría se añade cuando actualizas su posición, no por el mero hecho de existir.

El hit testing también empieza con matices: los descendientes dibujables no son clicables desde el primer momento. El canvas mantiene una lista ordenada de descendientes para probar impactos, y esa prueba va directamente del canvas a cada descendiente, saltándose clips y transformaciones intermedios. Además, el evento paint debe dispararse cuando la instantánea de un elemento cambiaría de aspecto, justo después de los pasos de Intersection Observer dentro de la actualización de renderizado. Las implementaciones pueden dispararlo aunque nada haya cambiado, pero deberían evitarlo. Todo esto está pensado para que el DOM y los píxeles no se desincronicen.

Primeros pasos con un canvas 2D

La implementación más sencilla pasa por colocar el atributo layoutsubtree en el canvas y meter dentro el HTML que quieras convertir en interfaz dibujada. Ese atributo hace que el navegador tenga en cuenta el contenido anidado, lo prepare para mostrarse dentro del canvas y lo exponga a los árboles de accesibilidad. Un formulario con su etiqueta y su campo de texto puede servir perfectamente como primer experimento. La clave es que ese formulario no desaparece: sigue estando ahí para el navegador.

Antes de dibujar conviene ajustar la rejilla del canvas al factor de escala del dispositivo. Si no lo haces, el contenido puede verse borroso. Lo suyo es usar ResizeObserver y leer devicePixelContentBoxSize cuando esté disponible; si no, tirar de contentRect multiplicado por devicePixelRatio. También puedes observar el canvas con la caja device-pixel-content-box cuando el navegador la soporte. Un canvas mal dimensionado arruina la nitidez por mucho DOM que lleves dentro.

Para un contexto 2D se usa drawElementImage dentro del evento paint. Ese evento se dispara cuando el elemento se vuelve a dibujar, por ejemplo al resaltar texto o al escribir en un campo. En la llamada puedes indicar la posición y el tamaño de destino, y el método devuelve una transformación que después hay que aplicar al estilo del elemento HTML. Ese paso es fundamental para que el navegador sepa dónde está colocado el elemento y pueda mapear bien los clics y los hovers. No basta con pintar: hay que decirle al navegador dónde ha quedado pintado.

En el caso 2D, drawElementImage actualiza automáticamente la geometría del elemento mediante updateElementGeometry. Ese comportamiento se puede desactivar pasando preserveElementGeometry como true. El método dibuja la última instantánea del elemento y su subárbol drawable, empieza en el border box antes de las transformaciones CSS y admite rectángulos de origen y destino. Los rectángulos de origen permiten aplicar outsets para recortar o incluir desbordamientos de tinta que sobresalen del border box; los de destino sirven para posicionar y escalar. Se lanza una excepción si el elemento no es drawable, si aún no hay una instantánea inicial o si pertenece a otro canvas. Los detalles importan cuando estás mezclando layout real con dibujo acelerado.

El evento paint también trae su propio ritmo. Se integra en la actualización de renderizado, puede dispararse después de los pasos de Intersection Observer y contiene una lista de los descendientes drawable que han cambiado. Los comandos de dibujo que ejecutes en paint aparecen en la actualización actual, pero los cambios de DOM que hagas dentro de paint no se verán hasta la siguiente. Para evitar líos de orden, los eventos paint se disparan en orden inverso al documento, con los marcos hijos antes que los documentos padres, y en orden inverso dentro de cada documento. Así los descendientes se pintan antes que sus ancestros. Es una coreografía pensada para que no se cuele un frame viejo por sorpresa.

Para aplicaciones que necesitan refrescos continuos existe requestPaint. Esta llamada provoca que el evento paint se dispare una vez en la siguiente oportunidad de renderizado, aunque ningún descendiente del canvas haya cambiado, de forma parecida a requestAnimationFrame. Es útil cuando tienes animaciones o lógica propia que no depende solo de cambios en el DOM. Te da un control fino sin tener que inventar un bucle paralelo.

WebGL, WebGPU y el baile de matrices

En WebGL se usa texElementImage2D. Funciona de manera parecida a texImage2D, pero acepta un elemento DOM como origen. Así puedes subir el contenido renderizado de un formulario, un panel o cualquier subárbol drawable a una textura y usarlo como material de una malla. El evento paint sigue siendo el lugar adecuado para mantener la textura al día. La textura deja de ser una imagen externa y pasa a ser una ventana a tu propio DOM.

En WebGPU se recurre a copyElementImageToTexture sobre la cola del dispositivo, de forma análoga a copyExternalImageToTexture. La idea es la misma: tomar el contenido de un elemento y copiarlo a una textura que luego utilizará el pipeline gráfico. La diferencia está en que WebGPU tiene su propio modelo de recursos y sincronización, así que toca respetar sus tiempos. El DOM se convierte en una fuente de textura más, pero con todas sus tripas vivas.

Con WebGL y WebGPU hay un matiz que no aparece en 2D: la posición en pantalla del elemento depende de cómo use la textura el shader. No se puede deducir sin más del contexto del canvas. Por eso, si tu programa usa una típica transformación model view projection, puedes usar getElementTransform para calcular una transformación equivalente a la que devuelve drawElementImage. El proceso pasa por convertir la matriz MVP de WebGL a DOMMatrix, normalizar el elemento HTML de píxeles a cuadrado unitario, mapear al viewport del canvas y multiplicar en orden Viewport por MVP por Normalización. Después aplicas el resultado al elemento HTML. Si te saltas la normalización, un botón de 200 píxeles puede acabar pareciendo 200 veces más grande.

1. Convierte la matriz MVP de WebGL en una DOMMatrix para poder operar con ella en el mundo DOM.
2. Normaliza el tamaño del elemento HTML: pasa de píxeles a un cuadrado unitario y ajusta el eje Y, que en WebGL apunta hacia arriba y en CSS hacia abajo.
3. Mapea ese espacio unitario al viewport real del canvas, estirando y trasladando según sus dimensiones.
4. Multiplica las matrices en el orden correcto: viewport, MVP y normalización.
5. Aplica la transformación final al elemento HTML para que la capa DOM quede justo encima de sus píxeles y los clics acierten en el sitio correcto.

Además de la transformación, updateElementGeometry permite ajustar el orden de hit testing con preserveHitTestOrder, fijar la transformación del elemento respecto al canvas mediante una DOMMatrix y establecer un clip con un DOMRect. La transformación y el clip no se usan para renderizar, así que cambiarlos no provoca un nuevo evento paint en la siguiente actualización. Eso sí, cuando fijas la transformación, la información de accesibilidad del elemento pasa a incluir geometría. clearElementGeometry borra ese estado. Son herramientas para afinar la interacción sin repintar por capricho.

También existe captureElementImage, que devuelve una referencia a la instantánea más reciente de un elemento drawable en forma de ElementImage. Esos objetos se pueden transferir a un worker y dibujar en un OffscreenCanvas. En un worker no hay acceso síncrono a las APIs del DOM, así que las actualizaciones de geometría se acumulan en una cola interna, se agrupan mediante un microtask y se envían al hilo principal. Cuando terminan las actualizaciones, los elementos aplican sus cambios y se dispara un evento elementgeometryupdate en el HTMLCanvasElement asociado con la lista de elementos actualizados. Si un elemento ya no existe cuando toca disparar el evento, se omite. El objetivo es que las actualizaciones se apliquen de forma atómica y sin tareas intercaladas.

Accesibilidad, internacionalización y calidad de texto

Uno de los mayores logros de esta API es que el contenido dentro del canvas puede seguir presente en el árbol de accesibilidad como si fuera DOM normal. Los sistemas de asistencia pueden analizar la interfaz, los lectores de pantalla pueden leerla y los indicadores de foco o de cursor se renderizan con drawElementImage y APIs similares. Eso no significa que puedas olvidarte de la accesibilidad: si un elemento no actualiza su geometría, se informa al árbol de accesibilidad sin información geométrica, y las tecnologías de asistencia pueden filtrarlo. La semántica no se pierde, pero la geometría hay que mantenerla al día.

También hay que cuidar lo que dejas dentro del canvas. Vistas ocultas, contenido que ya no se dibuja o restos de estados anteriores deberían eliminarse del DOM o marcarse con primitivas de accesibilidad como aria-hidden=true o inert. Si no, puedes acabar con contenido fantasma que estorba a las tecnologías de asistencia. La accesibilidad no va solo de que el árbol exista, sino de que refleje lo que de verdad está en pantalla.

La internacionalización sale ganando por otro lado. El navegador lleva décadas perfeccionando la forma del texto, las ligaduras, el texto bidireccional y los idiomas que se escriben de derecha a izquierda. Reimplementar eso en canvas es un dolor de muelas importante. Al delegar en el motor del navegador, el texto se renderiza con calidad y sin tener que integrar un motor tipográfico de terceros. El texto complejo deja de ser un problema y vuelve a ser una ventaja nativa.

El rendimiento y la fidelidad visual también se benefician. Los navegadores están muy optimizados para pintar HTML y CSS, a menudo con aceleración por GPU. Las bibliotecas caseras de texto en canvas rara vez igualan esa eficiencia. Al descargar la composición de texto y los diseños complejos en el navegador, la API libera ciclos para los efectos gráficos que de verdad necesitan potencia. Es una forma de dejar que cada parte haga aquello para lo que está diseñada.

Librerías y frameworks que ya están jugando con la API

Actualizar matrices a mano puede ser un peñazo, así que algunas bibliotecas ya han empezado a ofrecer soporte experimental. Three.js incorpora HTMLTexture, que permite pasar un elemento DOM como mapa de un material y colocarlo sobre una geometría 3D. La idea es sencilla: creas el material, le asignas la textura HTML, construyes la malla y la añades a la escena. El DOM se convierte en un material más dentro del grafo de escena.

PlayCanvas usa su propia API de texturas. Espera al evento paint para fijar la fuente, llama a requestPaint cuando haga falta y mantiene la textura actualizada con un listener de paint. Después asigna esa textura como diffuseMap de un material estándar. Ahora mismo el soporte está orientado a WebGL, y el soporte WebGPU queda pendiente de que la API del navegador correspondiente esté disponible. Para detectar si el dispositivo puede usar texturas HTML existe device.supportsHtmlTextures, que devuelve false en navegadores que no implementan la API. Siempre conviene tener una ruta alternativa preparada.

Babylon.js ofrece BABYLON.HtmlTexture, que envuelve el elemento DOM y se asigna como diffuseTexture de un material. PixiJS dio soporte en su versión 8.19.0 con HTMLSource, importado desde pixi.js/html-source, que permite añadir el elemento HTML como hijo del canvas de Pixi, envolverlo en un Sprite y sincronizar su transformación en el ticker. También existe CanvasUI, una biblioteca de componentes de interfaz que usa HTML-in-Canvas. Y si trabajas con un agente de programación, Modern Web Guidance incluye instrucciones actualizadas sobre esta API y otras prácticas modernas del navegador. El ecosistema se está moviendo, aunque todavía con pasos cortos.

Demos que devuelven la fantasía a la web

La web lleva un tiempo bastante hambrienta de fantasía. Muchos sitios parecen salidos de la misma plantilla, y los generados por IA a veces acentúan esa sensación de uniformidad. Las experiencias que priorizan la función sobre el deleite dejan al usuario con ganas de algo distinto. HTML-in-Canvas ha llegado en un momento en el que apetece recuperar el juego. No todo tiene que ser un formulario gris con un banner de cookies.

Han aparecido demos tan absurdas como memorables. Una obliga a jugar al pinball para darse de baja de una lista de correo. Otra permite navegar por Twitter desde un escritorio virtual dentro de una escena. Hay sliders con física, efectos de gelatina, tipografías que se deforman con un cursor 3D y siguen siendo seleccionables, y libros en 3D cuyas páginas usan texto DOM real. La creatividad vuelve a sentirse como una parte del producto y no como un adorno peligroso.

El libro 3D es un ejemplo muy claro: las páginas usan composición HTML, se puede cambiar la fuente con CSS, la traducción integrada funciona al instante y los agentes de IA pueden extraer el texto con menos complicaciones. El slider de gelatina de WebGPU refracta la luz según un modelo 3D subyacente y sigue respondiendo a los atributos de un input type range normal. La textura animada de un billboard 3D puede mostrar un lápiz SVG animado usando el DOM directamente en una textura WebGL, sin montar un bucle de animación propio. Son demos, sí, pero apuntan a formas de interfaz que antes eran un dolor de cabeza.

También hay experimentos con horarios en vivo, como un panel del metro de Londres integrado en una escena Three.js que actualiza sus datos y su reloj sin que el desarrollador tenga que reconstruir la textura a mano. Creadores como Alyx, Dominik y Sawyer han mostrado prototipos que van desde efectos de seguimiento ocular hasta entornos virtuales que responden a la entrada del usuario. La fantasía no está reñida con que los controles sean reales y accesibles.

Rendimiento, errores y límites que conviene conocer

La API tiene un potencial enorme, pero no es magia. Las primeras implementaciones se describen como bastante mejorables, sobre todo con contenido HTML complejo o que cambia muy rápido. Renderizar DOM vivo como textura exige recursos de GPU y puede llevar a tasas de fotogramas poco alegres en interfaces intrincadas. Esa sobrecarga es conocida y todavía no está optimizada para un uso generalizado y de alta fidelidad. Si metes una tabla de 500 filas dentro de un cubo giratorio, prepárate para sudar.

También hay errores concretos que han aparecido en las pruebas. drawElementImage a veces pinta un fotograma tarde, lo que produce una desincronización visible entre el elemento HTML y su representación texturizada. Además, renderizar elementos con barras de desplazamiento nativas puede provocar cuelgues inesperados del navegador, un problema serio para muchos componentes web habituales que exige soluciones provisionales. Estamos en fase experimental y se nota.

Hay límites de diseño que probablemente sigan ahí. El contenido de iframes de otro origen no funciona por seguridad y privacidad. Los iframes del mismo origen sí se pintan, pero el contenido cross-origin que lleven dentro no. Tampoco se puede olvidar que HTML-in-Canvas se dibuja con JavaScript, así que el desplazamiento y las animaciones no pueden actualizarse de forma independiente al hilo principal como ocurre fuera del canvas. Meter contenido con scroll dentro de un canvas tiene consecuencias de rendimiento que hay que valorar frente a dejar que sea el canvas entero el que haga scroll. No todo lo que se puede dibujar conviene dibujarlo de la misma manera.

A nivel de implementación se barajaron varias colocaciones para el evento paint dentro de la actualización de renderizado. Una opción era hacer una instantánea síncrona del paso de pintado, pero puede ser caro y tiene complicaciones arquitectónicas en algunos motores. Otra era usar marcadores de posición y un búfer de comandos que se rellena después, pero en WebGL muchas llamadas requieren un flush y eso puede provocar bloqueos o renderizados inconsistentes. Por eso se necesita ejecutar paint cuando ya se dispone de la lista completa de dibujo del elemento. La sincronización fina entre DOM y GPU no sale gratis.

De cara al futuro se está considerando un modo de canvas autoactualizable. drawElementImage registraría un marcador de posición de la última representación, y el canvas guardaría un búfer de comandos que se reemplazaría tras cada actualización de scroll o animación. Eso permitiría volver a rasterizar con placeholders actualizados sin bloquear el script y mantener efectos visuales sincronizados con el scroll nativo o las animaciones, independientemente del hilo principal. El diseño es viable para 2D y podría serlo para WebGPU con algunos añadidos pequeños. Es justo el tipo de pieza que falta para que la experiencia se sienta realmente nativa.

Privacidad y fingerprinting: el dilema de enseñar el DOM a la GPU

Renderizar HTML vivo en una textura abre una puerta enorme a la creatividad, pero también a preocupaciones de privacidad. El fingerprinting del navegador consiste en recoger características únicas del dispositivo, el sistema o el software para crear un identificador difícil de borrar. Si una web puede pintar elementos DOM reales y leer píxeles, podría capturar detalles que normalmente no están expuestos a las APIs estándar. Imagina un div oculto que contiene fuentes del sistema, colores de enlaces visitados o partes del tema de la interfaz. Convertir eso en textura podría dar un caramelo muy goloso a quien quiera rastrear usuarios. La potencia de la API exige un cortafuegos de privacidad bien pensado.

La propuesta habla de un renderizado que permite lectura de píxeles pero excluye información sensible, conocido como read-back-allowed rendering. Tanto el pintado, mediante lecturas de píxeles o ataques de temporización, como la invalidación, mediante onpaint, podrían filtrar datos. Para evitarlo se deja fuera de la pintura y de la invalidación todo lo que se considera delicado: datos cross-origin en iframes, imágenes o referencias de URL; canvas contaminados con datos de otro origen; SVG con use, pattern o feImage; colores y temas del sistema; preferencias; marcas de ortografía y gramática; información de enlaces visitados; datos pendientes de autocompletado; antialiasing de texto subpíxel; controles de vídeo y subtítulos; y popups del IME con su formato distintivo. La idea es que la textura no se convierta en una cámara indiscreta del sistema operativo.

Hay información que sí se considera aceptable. Los marcadores de búsqueda dentro de la página y de fragmentos de texto, la apariencia de barras de desplazamiento y controles de formulario, el parpadeo del cursor y los estilos de forced-colors no se excluyen. Algunos ya eran detectables de otras formas, y forced-colors ya está disponible mediante media queries y colores del sistema. El equilibrio consiste en mantener la utilidad sin abrir un nuevo agujero de huellas digitales. No se trata de esconderlo todo, sino de no regalar información que el usuario no espera compartir.

Hacia una API estable y un ecosistema que la adopte

El camino desde un experimento en Chrome Canary hasta un estándar web completo pasa por mucha prueba, mucho comentario y bastante paciencia. La propuesta se está incubando en un grupo comunitario, y los desarrolladores están invitados a llevar la API al límite, reportar fallos y compartir demos. Cada error de rendimiento, cada fallo de sincronización y cada duda de privacidad ayuda a afinar el diseño. La retroalimentación de los primeros usuarios influye de verdad en hacia dónde va la API.

Para seguirle la pista conviene estar atento al repositorio de la propuesta y a la página de estado de la plataforma Chrome, donde se ven los cambios de banderas y las etapas experimentales. No es una tecnología para producción todavía: hay errores conocidos, el rendimiento no está afinado y los detalles pueden cambiar. Pero las demos y los prototipos ya enseñan suficiente como para entender que hay algo grande aquí. La web puede recuperar parte de la experimentación que parecía haberse quedado en los márgenes.

Queda claro que HTML-in-Canvas no viene a sustituir al DOM ni a Canvas, sino a quitarles hierro a sus peores limitaciones. Permite que una escena 2D o 3D tenga texto real, formularios reales, accesibilidad real y funciones del navegador reales, mientras conserva la libertad de píxeles de la GPU. A cambio, exige cuidado con el rendimiento, la sincronización, los orígenes cruzados, el scroll y la privacidad. Es una herramienta experimental con un potencial enorme, ideal para prototipos, demos y aplicaciones que quieran explorar nuevas formas de interfaz sin renunciar a lo que hace grande a la web. Merece la pena probarla con curiosidad, medirla con rigor y no prometerle a producción más de lo que hoy puede dar.