HT︆ML-i︀n-︉Canva︎s : q︉u︄a︁nd︅ l︅e HTML entre︁ en︀fin︂ da︄ns l︋e ca︎n︎vas︌

Pour qui a déjà construit une expérience web un peu ambitieuse, le dilemme est familier. Comment créer un configurateur produit en 3D avec du texte sélectionnable, des formulaires fonctionnels et une interface accessible ? Soit on reste dans le DOM et on renonce à la 3D, soit on passe en WebGLAPI JavaScript qui affiche des graphismes 2D et 3D interactifs dans le navigateur en exploitant la carte graphique (GPU), sans plugin. et on réimplémente tout à la main : mise en page du texte, sélection, accessibilité.
Une interface de type Figma avec de vrais champs de formulaire ? Tout en DOM, et les performances s'effondrent au-delà de quelques milliers d'éléments. Tout en canvas, et les lecteurs d'écran ne voient plus qu'un trou noir là où se trouvait l'interface.

L'équipe Chrome le formule elle-même dans son annonce officielle : depuis des années, il faut choisir entre le DOM, pour ses fonctionnalités sémantiques, et le <canvas>, pour la performance graphique. HTML-in-Canvas promet d'en finir avec ce choix.

Pour tester en local, il faut utiliser Chrome Canary et activer le flag chrome://flags/#canvas-draw-element (le dépôt WICG recommande aussi chrome://flags/#enable-experimental-web-platform-features).

Pour comprendre l'intérêt de cette API, il faut revenir aux deux technologies qu'elle cherche à rapprocher.

Le DOM, ou Document Object Model, constitue la structure des pages web. Il apporte :

• un contenu sémantique, compris par le navigateur, les moteurs de recherche et les technologies d'assistance ;
• des outils de mise en page et de typographie très aboutis (Flexbox, Grid, polices, retour à la ligne) ;
• des éléments interactifs natifs : champs de formulaire, boutons, liens et zones de texte ;
• toutes les fonctionnalités intégrées au navigateur, comme la sélection de texte, le copier-coller, la recherche dans la page ou la traduction automatique.

Le canvas, à l'inverse, est une surface de dessin sur laquelle JavaScript peut générer des images. Avec son contexte 2D, WebGL ou WebGPUSuccesseur de WebGL : donne aux scripts un accès plus direct et bien plus performant à la carte graphique, y compris pour le calcul intensif (IA, simulations)., il permet de créer des animations, des jeux, des effets visuels et des scènes 3D complexes.

Mais pour le navigateur, le contenu d'un canvas est une boîte noire : pas de texte sélectionnable, pas d'accessibilité, rien à indexer. Afficher un simple paragraphe demande de calculer chaque position au pixel près et de gérer soi-même les retours à la ligne.

Attention à ne pas tout confondre. Les fonds animés en shader sont partout sur les sites créatifs, et ils n'ont pas attendu HTML-in-Canvas : un canvas WebGL dessine le décor, et le texte reste en HTML classique par-dessus. HTML-in-Canvas devient utile quand l'effet doit toucher le contenu lui-même : un texte qui se déforme, une carte qui se fissure, un formulaire plaqué sur un objet 3D.

HTML-in-Canvas fait le pont entre les deux. Le principe : on place du HTML classique à l'intérieur de l'élément <canvas>, le navigateur s'occupe de sa mise en page et de son rendu (styles CSS, polices, Flexbox…), puis le script peut dessiner ce rendu dans le canvas. En 2D, il devient une image. En 3D, il devient une texture que l'on peut plaquer sur un objet 3D ou faire passer dans un shader pour la déformer.

L'idée essentielle : conserver les avantages du HTML tout en profitant de nouvelles possibilités de composition graphique. Le contenu reste du vrai HTML. Il est exposé à l'arbre d'accessibilité et lisible par les lecteurs d'écran. Selon Google, les robots d'indexation et les agents IA peuvent lire le texte rendu dans des scènes 2D et 3D.

L'API tient en trois étapes :

1. Déclarer le contenu à dessiner. L'attribut content="drawable" sur le canvas active la mise en page de ses descendants. L'attribut drawable identifie les éléments que le navigateur peut dessiner indépendamment.
2. Dessiner le contenu HTML. Dans le contexte 2D, la méthode drawElementImage() fonctionne comme le drawImage() bien connu, mais prend un élément HTML en source.
3. Synchroniser le rendu et les interactions. Un événement paint se déclenche sur le canvas quand le contenu HTML change (saisie dans un champ, survol…).

Voici l'exemple minimal proposé dans le dépôt officiel de la proposition (WICG) : un petit formulaire, toujours fonctionnel, dessiné dans un canvas.

<canvas
  id="canvas"
  style="width: 400px; height: 200px;"
  content="drawable"
>
  <form id="form" drawable>
    <label for="name">Nom :</label>
    <input id="name" type="text">
  </form>
</canvas>

<script>
  const canvas = document.querySelector("#canvas");
  const form = document.querySelector("#form");
  const ctx = canvas.getContext("2d");

  canvas.onpaint = () => {
    ctx.reset();
    ctx.drawElementImage(form, 100, 0);
  };

  new ResizeObserver(([entry]) => {
    const size = entry.devicePixelContentBoxSize?.[0];

    if (size) {
      canvas.width = size.inlineSize;
      canvas.height = size.blockSize;
    }
  }).observe(canvas, {
    box: "device-pixel-content-box"
  });
</script>

Attention : HTML-in-Canvas évolue rapidement. La documentation initiale utilisait notamment l'attribut layoutsubtree, depuis remplacé par content="drawable" dans les versions récentes de la proposition. Les méthodes WebGL et WebGPU ont également changé de nom et de signature. Il est donc préférable de consulter la documentation officielle de Chrome avant de reprendre un exemple de code.

Côté écosystème, les bibliothèques suivent déjà : Three.js propose un support expérimental via une fonction HTMLTexture, et CanvasUI rassemble des composants open source pensés pour HTML-in-Canvas et WebGL.

C'est là que ça devient intéressant pour nos clients. HTML-in-Canvas permet de combiner des interactions belles et fonctionnelles, sans sacrifier l'une à l'autre.

Des configurateurs 3D avec de vrais textes. Imaginez un canapé en 3D que l'on fait tourner sur son téléphone, avec des étiquettes de prix et de matières lisibles par un lecteur d'écran, traduites automatiquement par Chrome pour un visiteur allemand, et surlignées quand on cherche « cuir » dans la page. Aujourd'hui, ces trois fonctions échouent en silence dès que le texte est dessiné dans une texture WebGL.

Démo

Des interfaces intégrées dans des objets 3D. Un formulaire de contact affiché sur l'écran d'un vieil ordinateur, comme ce clin d'œil au Commodore 64, ou posé sur une feuille de papier dans une scène 3D (démo Arrival Space). Dans un jeu WebGL, le terminal d'ordinateur du décor peut enfin être un vrai <textarea> : autocomplétion, annuler/rétablir, copier-coller et saisie dans toutes les langues fonctionnent sans rien recoder.

Démo Arrival Space

Des effets visuels sur du contenu réel. Texte qui se déforme comme à travers un prisme (démo Fluid Prism Text), page qui se fissure (démo de Felix Turner), effet loupe, page incurvée… Le genre d'effets qui plaisent aux jurys Awwwards, mais appliqués à un contenu qui reste accessible et référencé.
Pour une marque, ces possibilités peuvent enrichir une page de campagne, un site événementiel ou une expérience immersive, sans obliger à transformer chaque texte et chaque composant en simple image.
L'enjeu est de trouver le bon équilibre : un effet spectaculaire doit aussi rester lisible, utilisable et pertinent pour l'expérience proposée.

Source

Des graphiques et visualisations plus riches. Le dépôt WICG montre un camembert dont les étiquettes sur plusieurs lignes sont de simples blocs HTML, mis en page par le navigateur au lieu d'être calculées à la main.

Démo

Des scènes 3D lisibles pour le SEO. C'est l'aspect le moins commenté, mais Google le met en avant : puisque le texte reste dans le DOM, il peut être lu par les robots d'indexation et les agents IA. Un site immersif n'a plus à choisir entre l'effet « waouh » et le référencement.

Malgré son potentiel, HTML-in-Canvas doit encore franchir plusieurs étapes avant de pouvoir être envisagé comme une solution courante pour les sites en production.

C'est encore expérimental. Au 19 octobre 2026, HTML-in-Canvas reste en phase d'expérimentation dans Chrome. Google a prolongé son Origin Trial jusqu'à Chrome 160, et les détails de l'API continuent d'évoluer.
Comme on l'a vu, les noms changent d'une version à l'autre : les démos de mai 2026 sont déjà en partie dépassées.

Chrome uniquement, pour l'instant. Aucun autre navigateur ne l'implémente à ce jour. Firefox et Safari ne se sont pas engagés, et l'adoption du sélecteur CSS :has() nous a appris que ces délais peuvent être longs. En production, il faudra donc toujours prévoir une version de repli.

Les performances. Dessiner du HTML dans un canvas reste bien plus coûteux que de dessiner un rectangle. C'est fait pour des éléments d'interface et du texte, pas pour animer des milliers d'objets à 60 images par seconde. Les effets les plus impressionnants demandent un GPU puissant : ces usages se généraliseront à mesure que le matériel suivra.

La sécurité et la vie privée. Dessiner du HTML en pixels que le script peut ensuite relire ouvre la porte au fingerprinting (identification de l'appareil) et à la fuite de données. La proposition prévoit donc un mode de rendu « respectueux de la vie privée » : le navigateur filtre ce qui est peint pour que les informations sensibles de l'utilisateur ne se retrouvent pas dans les pixels. Le contenu des iframes provenant d'autres origines, par exemple, n'est pas pris en charge.

Les effets GPU ne sont pas sans risque. Un shader mal écrit (ou malveillant) peut aller jusqu'à geler la machine, comme l'a montré la démonstration Deathray sur macOS. Raison de plus pour garder ces effets légers et bien testés.

Une API encore perfectible. Certains développeurs, comme Andrew Prifer, jugent la gestion du pointeur trop simple pour des scènes 3D complexes. C'est justement le rôle de cette phase expérimentale : faire remonter ces retours avant de figer la spécification.

HTML-in-Canvas est l'une des annonces les plus prometteuses de l'année pour le web créatif. Elle ne résout pas tout et reste réservée à Chrome, mais elle met fin à un compromis qui pesait sur chaque projet ambitieux : choisir entre une expérience spectaculaire et un site accessible, traduisible et bien référencé.

Il reste à voir si l'API sortira du stade expérimental, et sous quelle forme. En attendant, c'est le bon moment pour prototyper, imaginer des usages et se tenir prêt.

Vous avez un projet d'expérience interactive ou innovante ? Parlons-en avec l'équipe Wesign.

Démo HTML-in-Canvas par Wesign