Durante años, el desarrollo web ha tenido dos vertientes: por un lado estaba el DOM, la base tradicional de las interfaces web; por otro, Canvas, WebGL y WebGPU, tecnologías pensadas para gráficos avanzados, visualizaciones complejas, juegos, editores visuales y experiencias interactivas de alto rendimiento.
Pero claro, si una interfaz se construía con HTML, CSS y JavaScript sobre el DOM, podía aprovechar funciones nativas del navegador como la accesibilidad, la selección de texto, la búsqueda dentro de la página, la traducción automática, el autocompletado o la indexación del contenido. Pero si esa misma interfaz se renderizaba dentro de un canvas, en una cuadrícula de píxeles , era difícil de interpretar para usuarios, buscadores y herramientas externas.
La nueva HTML-in-Canvas API, presentada por Google, intenta unir esos dos mundos. Su objetivo es permitir que contenido HTML real pueda dibujarse dentro de un canvas 2D o 3D, utilizarse como textura en entornos WebGL y WebGPU, manteniendo al mismo tiempo la interacción, la accesibilidad y las funciones propias del navegador.
Dicho de forma sencilla: HTML-in-Canvas quiere que las interfaces visuales más avanzadas no tengan que renunciar a las ventajas del HTML.
Y eso puede tener implicaciones importantes y nuevos retos para desarrolladores, el diseño web, el SEO técnico, la accesibilidad digital y la forma en la que los agentes de inteligencia artificial leen e interpretan las páginas web.
Qué es HTML-in-Canvas API
HTML-in-Canvas API es una nueva API experimental de Chrome que permite renderizar elementos HTML dentro de un elemento <canvas>. Hasta ahora, el canvas funcionaba principalmente como una superficie de dibujo basada en píxeles. Podías pintar líneas, formas, imágenes, texto o gráficos complejos, pero el navegador no entendía ese contenido como una interfaz HTML normal.
Con HTML-in-Canvas, Google propone que determinados elementos del DOM puedan vivir dentro de un canvas, dibujarse en él y seguir conservando parte de su comportamiento nativo.
Esto significa que un formulario, un botón, un bloque de texto, una etiqueta, un menú o una interfaz HTML podrían formar parte de una experiencia renderizada en Canvas, WebGL o WebGPU sin quedar completamente desconectados del navegador.
La API se apoya principalmente en tres piezas técnicas:
<canvas layoutsubtree>
<div>
<label for="name">Nombre:</label>
<input id="name" type="text">
</div>
</canvas>
- El atributo
layoutsubtree, que permite que el canvas tenga contenido HTML anidado. - El método
drawElementImage(), que dibuja un elemento HTML dentro del canvas 2D. - El evento
paint, que se activa cuando el contenido necesita volver a renderizarse.
En el caso de WebGL y WebGPU, la propuesta incluye métodos equivalentes para utilizar elementos HTML como texturas dentro de escenas gráficas más avanzadas.
El problema que intenta resolver: DOM vs Canvas
El DOM es el modelo tradicional sobre el que se construyen las páginas web. Permite crear estructuras HTML que el navegador entiende: títulos, párrafos, formularios, enlaces, botones, tablas, imágenes, listas y todo tipo de componentes interactivos.
Gracias al DOM, el navegador puede ofrecer funciones que parecen normales, pero que son fundamentales:
- seleccionar texto;
- copiar y pegar;
- hacer clic derecho sobre elementos;
- usar lectores de pantalla;
- traducir una página;
- buscar texto con Ctrl/Cmd + F;
- aplicar zoom correctamente;
- usar autocompletado;
- inspeccionar elementos con DevTools;
- interpretar semánticamente el contenido.
Canvas, trabaja de otra manera. Es una superficie gráfica. El navegador ve un lienzo, pero no entiende necesariamente qué significan los píxeles dibujados dentro. Eso lo hace muy potente para gráficos, juegos, visualizaciones, animaciones y experiencias 3D, pero también introduce problemas importantes.
Si escribes un texto dentro de canvas, ese texto puede verse en pantalla, pero no es interpretable como texto real. Si dibujas un botón dentro de canvas, visualmente puede parecer un botón, pero el navegador no lo entiende como un <button> estándar.
Ahí aparece la oportunidad de HTML-in-Canvas: usar canvas para lo visual, pero sin abandonar por completo las ventajas del HTML real.
Qué cambia con esta nueva API
HTML-in-Canvas no significa simplemente “poner HTML encima de un canvas” mediante capas absolutas con CSS. Eso ya podía hacerse de forma limitada con posicionamiento, overlays y trucos de interfaz.
Lo realmente interesante es que la API permite dibujar elementos HTML dentro del propio flujo gráfico del canvas, sincronizando además su transformación para que el navegador sepa dónde se encuentran físicamente esos elementos en pantalla.
Esto abre una puerta nueva: construir interfaces visuales complejas donde el contenido sigue siendo HTML y que el navegador entiende.
HTML dentro de Canvas
Por ejemplo, podríamos tener un formulario, una tarjeta de producto, un bloque de texto o un componente de interfaz y dibujarlo dentro de una escena 2D o 3D.
Esto puede reducir mucha complejidad en proyectos donde antes había que crear sistemas personalizados para representar texto, menús, controles o interfaces dentro de Canvas o WebGL.
Interfaces interactivas sin perder accesibilidad
Uno de los problemas clásicos de Canvas es la accesibilidad. Si toda la interfaz se convierte en píxeles, los lectores de pantalla y otras tecnologías de asistencia tienen más difícil interpretar qué está ocurriendo.
HTML-in-Canvas intenta mejorar este punto porque el contenido renderizado dentro del canvas puede seguir estando expuesto al árbol de accesibilidad.
Esto es especialmente importante para experiencias visuales avanzadas. Una interfaz 3D ya no será una barrera para usuarios que dependen de tecnologías de asistencia.
Texto seleccionable, buscable e indexable
En una experiencia canvas tradicional, el texto puede estar visualmente presente, pero no se comportar como texto real. Con HTML-in-Canvas, el objetivo es que el texto renderizado pueda seguir aprovechando funciones del navegador como la selección, la búsqueda en página o la interpretación por parte de herramientas externas.
Si una página tiene contenido importante dentro de una experiencia visual compleja, ese contenido no queda atrapado en una imagen o en una textura opaca. Puede ser ser leído, encontrado y comprendido.
Integración con WebGL, WebGPU y Three.js
HTML-in-Canvas no se queda solo en canvas 2D. También se plantea para escenarios más avanzados con WebGL y WebGPU.
Esto permite imaginar interfaces HTML funcionando como texturas dentro de una escena 3D. Por ejemplo:
- un panel de control dentro de un entorno 3D;
- una pantalla interactiva dentro de un juego;
- un libro 3D con texto HTML real;
- una tarjeta de producto en una experiencia inmersiva;
- una interfaz dentro de una demo WebXR;
- una landing visual con elementos 3D interactivos.
Además, algunas bibliotecas ya están explorando compatibilidad. Chrome menciona soporte experimental en Three.js mediante THREE.HTMLTexture, lo que permitiría utilizar un elemento DOM como textura dentro de una malla 3D.
Por qué HTML-in-Canvas puede ser importante para el SEO
Aquí es donde el tema se vuelve especialmente interesante para estudios de diseño web, SEO técnico y desarrollo como Xufa.
Durante mucho tiempo, las experiencias muy visuales han tenido un coste SEO. HTML-in-Canvas puede ser una gran solución en estos casos.
El problema del contenido atrapado en píxeles
Para un usuario, un texto renderizado en canvas puede parecer perfectamente normal. Pero para el navegador, un buscador o un lector de pantalla, ese texto puede no existir.
Si el contenido principal de la página vive dentro del canvas y no existe una alternativa HTML bien estructurada, se pierde contexto semántico.
Por eso, hasta ahora, una buena práctica era acompañar estas experiencias con contenido HTML real fuera del canvas: títulos, descripciones, textos explicativos, datos estructurados, enlaces internos y secciones indexables.
Con HTML-in-Canvas, el futuro podría ser más flexible: interfaces visuales avanzadas con contenido más fácil de interpretar.
Mejor lectura por rastreadores y agentes de IA
La búsqueda ya no depende únicamente del clásico resultado azul de Google. Cada vez más sistemas intentan interpretar, resumir y reutilizar contenido web: Google AI Overviews, asistentes de IA, navegadores con agentes integrados, buscadores conversacionales y herramientas capaces de interactuar con páginas.
En ese contexto, la forma en la que una web expone su contenido es cada vez más importante. No basta con que algo “se vea bonito”. También debe poder ser leído, entendido, estructurado y relacionado con una intención de búsqueda.
Si HTML-in-Canvas permite que el contenido de experiencias 2D o 3D sea más accesible para rastreadores y agentes de IA, puede cambiar la forma en que diseñamos interfaces avanzadas. No porque sustituya al SEO técnico, sino porque puede reducir la distancia entre una experiencia visual potente y una web semánticamente comprensible.
En Xufa Estudio lo vemos como una señal clara: el futuro del diseño web no va solo de hacer webs más espectaculares, sino de hacer experiencias más visuales sin perder estructura, accesibilidad ni capacidad de posicionamiento.
Más posibilidades para experiencias visuales que posicionan
Imagina una landing page para una marca de arquitectura, un configurador de producto 3D, una experiencia inmersiva para una bodega, una web de portfolio creativo o una presentación interactiva de servicios.
Hasta ahora, en muchos casos había que separar dos mundos:
- la experiencia visual avanzada;
- el contenido HTML optimizado para SEO.
Una web podría tener componentes visuales mucho más ambiciosos y, al mismo tiempo, conservar texto real, formularios accesibles, elementos inspeccionables y contenido más fácil de leer.
Esto no elimina la necesidad de estrategia SEO. Al contrario: la hace más importante. Porque si las interfaces visuales pueden ser mejor interpretadas, también habrá más competencia por construir experiencias bien estructuradas desde el principio.
Casos de uso de HTML-in-Canvas
Aunque la API todavía está en fase experimental, sus posibles aplicaciones son muy amplias.
No estamos hablando solo de una mejora técnica para desarrolladores. Estamos hablando de una nueva forma de plantear interfaces web complejas.
Aplicaciones tipo Figma, Miro o Google Docs
Herramientas como Figma, Miro, editores visuales, pizarras colaborativas o aplicaciones de productividad trabajan con superficies gráficas enormes. Muchas veces necesitan combinar rendimiento, interacción compleja, zoom, movimiento, componentes flotantes y edición de contenido. En ese tipo de aplicaciones, Canvas aporta potencia, pero el DOM aporta funcionalidades nativas difíciles de replicar.
HTML-in-Canvas podría permitir que ciertos componentes de interfaz se rendericen dentro del entorno gráfico sin perder funciones como accesibilidad, selección de texto o formularios reales.
Esto puede reducir el peso de implementaciones personalizadas y mejorar la experiencia de usuario.
Webs 3D y experiencias inmersivas
Con HTML-in-Canvas, una escena 3D podría incorporar contenido HTML real como parte del entorno. Por ejemplo, una pantalla dentro de una sala virtual, un cartel interactivo, una ficha de producto, una navegación contextual o un bloque de texto integrado en una experiencia visual.
Landing pages interactivas y visuales
En marketing digital, diseño web y branding, cada vez hay más interés por experiencias inmersivas: landings con animaciones, escenas 3D, interacciones fluidas, storytelling visual y elementos dinámicos.
HTML-in-Canvas podría abrir una vía para construir landings más visuales sin aislar por completo el contenido del navegador. Para marcas que necesitan diferenciarse, puede ser una oportunidad.
Cómo funciona HTML-in-Canvas a nivel técnico
Aunque el artículo no pretende ser una documentación técnica completa, sí conviene entender el funcionamiento básico. La API se utiliza en tres fases principales: preparar el canvas, renderizar el elemento y sincronizar la posición del DOM con lo que se ha dibujado.
El atributo layoutsubtree
El primer paso es añadir el atributo layoutsubtree al elemento <canvas>.
<canvas id="canvas" style="width: 200px; height: 200px;" layoutsubtree>
<div id="form_element">
<label for="name">Nombre:</label>
<input id="name" type="text">
</div>
</canvas>Este atributo indica al navegador que debe tener en cuenta el contenido HTML anidado dentro del canvas.
Ese contenido no se dibuja automáticamente como una interfaz visible normal. Lo importante es que el navegador puede calcular su layout, prepararlo para ser renderizado y exponerlo al árbol de accesibilidad.
El método drawElementImage()
En un contexto 2D, el método principal es drawElementImage().
Un ejemplo simplificado sería:
const canvas = document.getElementById('canvas');
const ctx = canvas.getContext('2d');
const formElement = document.getElementById('form_element');
canvas.onpaint = () => {
ctx.reset();
const transform = ctx.drawElementImage(formElement, 0, 0);
formElement.style.transform = transform.toString();
};Este método dibuja el elemento HTML dentro del canvas y devuelve una transformación que después se aplica al elemento para mantener sincronizada su ubicación real en pantalla.Dicho de otra forma: no basta con pintar el HTML. El navegador también necesita saber dónde está ese elemento para que los clics, el foco, la selección de texto y otras interacciones funcionen correctamente.
El evento paint
El evento paint se dispara cuando el elemento necesita actualizarse.
Esto es importante porque el contenido HTML puede cambiar: un usuario puede escribir en un input, seleccionar texto, activar un estado, modificar un valor o provocar una actualización visual.
El canvas debe poder redibujar ese contenido cuando haga falta.
Transformaciones CSS para mantener la interacción
Una de las partes más delicadas de HTML-in-Canvas es la sincronización espacial.
Si un elemento HTML se dibuja visualmente en una posición, pero el navegador cree que está en otra, la interacción fallaría. El usuario podría hacer clic sobre un botón que visualmente está en un sitio, pero el elemento real estar en otra coordenada.
Por eso la API trabaja con transformaciones CSS. En canvas 2D, drawElementImage() devuelve una transformación que puede aplicarse directamente al elemento.
En WebGL y WebGPU, el cálculo puede ser más complejo porque la posición depende de matrices, cámaras, proyecciones y shaders. Para estos casos, la API contempla funciones de ayuda como getElementTransform().
Tabla comparativa: DOM, Canvas y HTML-in-Canvas
| Característica | DOM tradicional | Canvas tradicional | HTML-in-Canvas |
|---|---|---|---|
| Texto seleccionable | Sí | No de forma nativa | Sí, según implementación |
| Accesibilidad | Alta | Limitada si no se trabaja aparte | Mejor integrada |
| Rendimiento gráfico avanzado | Limitado | Alto | Alto, con HTML integrado |
| Formularios nativos | Sí | No | Sí, como elementos HTML |
| SEO e indexación | Favorable | Puede ser problemático | Más prometedor |
| WebGL/WebGPU | No directamente | Sí | Sí, con HTML como textura |
| DevTools e inspección | Sí | Limitado | Más integrado |
| Ideal para | Webs, formularios y contenido | Juegos, gráficos y visualizaciones | Interfaces visuales complejas con HTML real |
Limitaciones actuales de HTML-in-Canvas
Aunque la propuesta es muy interesante, aun está verde.
HTML-in-Canvas todavía es una API experimental. Está en prueba de origen en Chrome y no debe entenderse como una tecnología lista para usarse masivamente en producción.
Entre sus limitaciones actuales encontramos:
- no funciona con contenido de iframe de origen cruzado por motivos de seguridad y privacidad;
- depende de JavaScript para dibujar el HTML dentro del canvas;
- el desplazamiento y ciertas animaciones pueden no comportarse igual que fuera del canvas;
- todavía no existe soporte generalizado en todos los navegadores;
- la API puede cambiar durante el proceso experimental;
- requiere pruebas específicas de rendimiento, accesibilidad y compatibilidad.
Ahora mismo no estamos ante una tecnología que debamos implementar sin más en cualquier proyecto de un cliente.
Estamos ante una señal de lo que puede ser el futuro.
¿Deberías usar HTML-in-Canvas en producción?
La respuesta corta es: todavía no como base de un proyecto crítico.
Si tienes una web corporativa, una tienda online, una landing de captación, una web de servicios o un proyecto SEO, no deberías depender hoy de HTML-in-Canvas para contenido esencial.
Es mejor seguir trabajando con buenas prácticas consolidadas:
- HTML semántico;
- estructura clara de encabezados;
- contenido indexable;
- accesibilidad;
- buen rendimiento;
- diseño responsive;
- datos estructurados cuando corresponda;
- JavaScript controlado;
- componentes interactivos bien optimizados.
Sin embargo, sí tiene sentido empezar a observar esta API, probarla en demos, laboratorios internos o proyectos experimentales.
Especialmente si trabajas en:
- interfaces 3D;
- configuradores visuales;
- experiencias inmersivas;
- aplicaciones gráficas;
- juegos web;
- visualizaciones de datos;
- herramientas tipo editor;
- landings altamente interactivas.
En esos casos, HTML-in-Canvas puede convertirse en una tecnología muy relevante durante los próximos años.
Qué significa esta API para el futuro del diseño web
HTML-in-Canvas no es solo una API más. Es una pista de hacia dónde puede evolucionar la web.
Durante años, el diseño web ha ido sumando capas: primero páginas estáticas, luego CSS avanzado, después JavaScript, animaciones, frameworks, WebGL, WebGPU, experiencias 3D, IA integrada y agentes capaces de navegar o interpretar sitios.
Pero hay una tensión constante: cuanto más visual e interactiva se vuelve una web, más difícil puede ser mantenerla accesible, rápida, indexable y fácil de interpretar.
HTML-in-Canvas intenta reducir esa tensión.
Puede permitir que las webs del futuro sean más inmersivas sin convertirse en cajas negras para el navegador. Puede ayudar a que un contenido visual siga siendo contenido. Y puede facilitar que experiencias avanzadas sean más compatibles con SEO, accesibilidad y herramientas de IA.
Para estudios como Xufa, esta evolución es especialmente interesante porque confirma una idea que llevamos tiempo defendiendo: una web no puede diseñarse solo para verse bien. También debe entenderse bien.
- Tiene que entenderla el usuario.
- Tiene que entenderla Google.
- Tiene que entenderla un lector de pantalla.
- Tiene que entenderla un navegador.
- Y cada vez más, también tiene que poder interpretarla un agente de inteligencia artificial.
HTML-in-Canvas, SEO e IA: una señal importante
La llegada de APIs como HTML-in-Canvas encaja con un cambio mayor: la web se está preparando para un escenario donde los contenidos no solo se leen en pantalla, sino que también son procesados por sistemas automáticos.
Los agentes de IA necesitan páginas con estructura clara, elementos interpretables y contenido accesible. Los buscadores necesitan señales semánticas. Los usuarios necesitan interfaces rápidas y comprensibles. Y las marcas necesitan experiencias diferenciales sin perder visibilidad orgánica.
Por eso, aunque HTML-in-Canvas todavía sea experimental, su dirección es relevante. Nos está diciendo que la web visual y la web semántica no deberían avanzar por caminos separados.
El futuro probablemente no será elegir entre una web bonita o una web posicionable. El futuro será construir experiencias visuales, interactivas y técnicamente sólidas que puedan ser entendidas por personas, buscadores y sistemas de IA.
Potencia visual y HTML real
HTML-in-Canvas API es una de esas novedades que pueden parecer muy técnicas al principio, pero que esconden una idea mucho más grande: unir la potencia visual de Canvas, WebGL y WebGPU con las ventajas del HTML real.
Si esta API evoluciona y termina consolidándose, podría cambiar la forma en la que se construyen interfaces web avanzadas, experiencias 3D, aplicaciones gráficas, juegos, landings interactivas y herramientas visuales.
Su mayor promesa no es solo poder dibujar HTML dentro de un canvas. Su mayor promesa es permitir que las experiencias web más complejas sigan siendo accesibles, interactivas, buscables e interpretables. Y eso conecta directamente con el futuro del diseño web, el SEO técnico y la inteligencia artificial.
En Xufa Estudio seguiremos de cerca esta evolución, porque apunta a una dirección muy clara: las webs del futuro serán cada vez más visuales e interactivas, pero no podrán permitirse dejar de ser comprensibles.
