Pendant quinze ans, mettre du texte HTML dans une scène 3D a voulu dire le redessiner à la main — et perdre la sélection, le copier-coller, le zoom et les lecteurs d’écran. L’interface de programmation (API) HTML-in-Canvas, en origin trial sur Chrome, propose de faire l’inverse : dessiner le DOM (Document Object Model) tel quel dans une texture 2D, WebGL ou WebGPU, tout en le laissant vivant. Le 22 octobre, le billet de Chrome for Developers est apparu en page d’accueil de Hacker News — 118 points et 58 commentaires au moment d’écrire. Ce n’est pas un lancement. C’est un signal.
Ce que l’API change vraiment
Le principe tient en trois primitives. Un canvas déclaré content=“drawable” accepte des descendants HTML ; les éléments à dessiner reçoivent l’attribut drawable ; un événement paint signale les changements ; puis drawElementImage(), texElementSubImage2D() ou drawElementImageToTexture() envoient le rendu vers le contexte voulu. Le navigateur ne copie pas une capture statique : il rejoue les commandes de rendu de l’élément, et c’est toute la différence.
Le point décisif n’est pas l’effet visuel, c’est ce qui reste attaché. Le texte demeure dans l’arbre d’accessibilité, répond à Ctrl+F, se traduit, s’inspecte dans DevTools et peut être lu par un agent. Un bouton dans une texture WebGL conserve son focus clavier, à condition de resynchroniser sa géométrie. Three.js et PlayCanvas ont déjà un support expérimental. C’est précisément ce que les démos de rasterisation ne savaient pas offrir.
Le DOM ne disparaît pas dans la texture : il continue d’exister, avec sa sélection, son focus et ses lecteurs d’écran.
Un signal qui monte, pas un lancement
La chronologie compte plus que l’annonce. L’explainer du WICG (Web Incubator Community Group) est derrière un flag Chromium depuis 2025 ; le fil Hacker News d’août 2025 avait réuni 222 points et 116 commentaires. En mai 2026, les démos communautaires circulent à leur tour (67 points). Fin septembre, Chrome publie une révision de l’API : renommages, préallocation explicite de la mémoire vidéo (VRAM), nouvelle synchronisation du DOM. L’origin trial, encadré pour Chrome 148 à 150, est prolongé. Puis le billet initial refait surface le 22 octobre.
La courbe est réelle, mais lente. Elle ressemble à celle d’une infrastructure qui se cherche, pas à celle d’un produit qui décolle. Les soutiens de Three.js et PlayCanvas sont un indice sérieux ; l’absence de Safari et de Firefox en est un autre, dans l’autre sens. Précocité réelle, adoption encore marginale : le sujet est à surveiller, pas à déployer en production sans filet.
Le piège : croire que le compromis disparaît
Le DOM ne devient pas gratuit dans le canvas. À chaque paint, le navigateur capture l’état de l’élément et l’envoie au processeur graphique (GPU) ; il faut dimensionner la texture, préallouer la VRAM, recalculer les matrices en 3D, puis resynchroniser les zones de clic et de focus. Le budget ne s’évapore pas : il se déplace du layout vers la bande passante mémoire et la latence GPU. Sur un site vitrine, ce déplacement peut coûter plus cher que l’effet qu’il achète.
Deuxième malentendu : l’API est encore mouvante. En quelques mois, layoutsubtree est devenu content=“drawable”, texElementImage2D est devenu texElementSubImage2D, et copyElementImageToTexture a changé de nom et de signature. Les premiers exemples publics sont déjà à moitié périmés. Le fil de discussion soulève aussi le fingerprinting : un canvas qui lit du DOM peut exposer des pixels sensibles. Chrome évoque un « rendu autorisé en lecture » ; le compromis sécurité/usage n’est pas stabilisé.
Une démo qui tourne sur un MacBook Pro ne dit rien du coût sur un Android à 250 €.
Qui gagne, qui perd
Gagnent les studios WebGL/WebGPU, les applications canvas lourdes qui reconstruisaient leur interface en pixels, les expériences WebXR et les sites où la typographie est le décor plutôt que le contenu. Perdent les bibliothèques de rasterisation type html2canvas sur une partie de leurs cas d’usage, et les bricolages d’overlays DOM dupliqués pour l’accessibilité. Ne perdent rien : les sites classiques, qui n’ont aucune raison de mettre leur texte dans une texture. C’est la majorité.
Le contre-argument tient en une phrase : la 3D n’est pas une amélioration en soi. Mal utilisée, elle ajoute du poids, des problèmes de contraste et de la fatigue visuelle. Une API graphique ne remplace pas une direction artistique ; elle rend seulement certaines idées moins coûteuses à prototyper. La différence entre un site premium et un site gadget se joue toujours dans le choix de l’effet, pas dans sa technique.
La question à se poser avant de l’utiliser
Pour un projet qui hésite, le test tient en cinq points.
- L’effet 3D porte-t-il un sens, ou décore-t-il un contenu qui pourrait rester plat ?
- Le texte doit-il rester sélectionnable et trouvable ? Si non, une image suffit.
- Existe-t-il un fallback DOM propre pour Safari et Firefox ?
- Le rendu a-t-il été mesuré sur un appareil milieu de gamme, pas seulement sur le portable du studio ?
- Le budget GPU est-il intégré au budget de performance, ou ajouté par-dessus ?
La réponse raisonnable est souvent : pas maintenant. Sur une page de vente, une scène 3D dont le texte reste lisible et indexable peut valoir l’essai ; sur un blog ou une documentation, elle n’apporte rien qu’un bon CSS ne fasse déjà. Reste une inconnue de taille : on ne sait pas encore si Safari et Firefox suivront, ni si la facture GPU tient à l’échelle. Ce qui est certain, c’est que l’arbitrage de 2010 n’est plus une fatalité. Il devient une décision de design.