HTML-in-Canvas : proposition d’une nouvelle API pour rendre du contenu HTML directement dans le canvas

 (github.com/WICG)
6 points par GN⁺ 2025-08-07 | 1 commentaires | Partager sur WhatsApp
  • HTML-in-Canvas est un projet WICG qui propose une nouvelle API standard permettant de dessiner directement des éléments/contenus HTML à l'intérieur de l'élément <canvas> sur le Web.
  • Né pour résoudre les problèmes de mise en page de texte complexe, d'accessibilité, d'internationalisation, ainsi que de qualité/performance, il permet d'utiliser directement le style HTML dans divers cas d'utilisation de Canvas comme les graphiques, l'UI ou les menus de jeux.
  • Grâce à de nouvelles méthodes comme drawElement, texElement2D, setHitTestRegions, il devient possible de rendre et de texturer directement des éléments HTML dans un contexte Canvas 2D ou WebGL.
  • Les zones d’interaction, l’amélioration de l’accessibilité, l’UI 2D dans des scènes 3D, les mises en page basées sur CSS/HTML… intègrent des besoins concrets des développeurs web.
  • Disponible via un flag expérimental dans Chrome Canary (138.0.7175.0 ou supérieur), avec les retours et rapports de bugs bienvenus.

Vue d'ensemble et enjeux

  • Propose une nouvelle API pour dessiner directement des éléments HTML dans <canvas>.
  • Auparavant, il n'y avait pas de méthode simple pour rendre facilement des mises en page complexes, du texte et des contenus basés sur HTML dans <canvas>, ce qui limitait l'accessibilité, l'internationalisation, la performance et la qualité.
  • HTML-in-Canvas répond à ce manque en prenant en charge le rendu HTML en Canvas 2D et WebGL, augmentant son applicabilité à des outils de graphiques, des boîtes de texte riche, des interfaces de jeu, etc.

Cas d'utilisation

  • Représentation dans le canvas de texte et de contenu de mise en page stylisé
    • Exemples : légende de graphique, axes, zones d'éditeur de texte enrichi, menu de jeu, etc.
  • Amélioration de l’accessibilité
    • Résout la discordance entre le contenu alternatif du canvas existant et le rendu réellement affiché.
    • La nouvelle API permet de synchroniser les informations d'accessibilité.
  • Association de HTML et de shader WebGL
    • Répond à la nécessité de combiner HTML avec des shaders WebGL standard au-delà des effets CSS filter.
  • Rendu HTML dans un contexte 3D
    • Permet d'insérer du contenu 2D riche dans des zones 3D de jeux ou de sites web.

API proposée et principales fonctionnalités

  • L'attribut <canvas layoutsubtree> active la mise en page des éléments HTML enfants du canvas (par défaut, il n'est visible que visuellement, non exposé aux algorithmes de navigation de l'UA).
  • CanvasRenderingContext2D.drawElement(element, x, y, options)
    • Rend un élément HTML enfant du canvas à la position indiquée.
    • options.allowReadback contrôle la prévention des fuites de données personnelles (application d'une politique de tainting prévue ensuite).
    • Les paramètres dwidth et dheight permettent de redimensionner à la taille voulue.
  • WebGLRenderingContext.texElement2D(...)
    • Dessine directement un élément HTML spécifié en texture WebGL pour un usage dans une scène 3D.
  • setHitTestRegions
    • Associe les éléments dessinés sur une zone au hit test du canvas pour rediriger automatiquement les événements souris/toucher.
  • Option fireOnEveryPaint (ResizeObserver)
    • Déclenche un rerendu en détectant automatiquement le bon moment lors des changements/repositionnements HTML pour redessiner le canvas.

Fonctionnement et limites

  • Lors d'un appel à drawElement, la matrice de transformation du canvas (CTM) est prise en compte, et l'image est clipée uniquement dans la border box de l'élément.
  • L'image dessinée sur le canvas est statique (si l'élément change après le rendu, il faut rappeler drawElement).
  • Non pris en charge pour les canvas hors écran ou non présents dans le DOM (limitation technique).
  • Les éléments interactifs (boutons, formulaires, etc.) peuvent être dessinés, mais ne deviennent pas interactifs automatiquement.
  • Les iframes cross-origin, SVG foreignObject, etc. ne sont pas pris en charge.
  • Les questions d'accessibilité, de sécurité et de confidentialité (PII) restent en discussion.

Exemples de démo

  • Exemple de texte complexe : dessin direct sur le canvas de texte et boîtes HTML stylés avec une mise en page complexe via drawElement.
  • Exemple WebGL : création d'une texture WebGL à partir de contenu HTML avec texElement2D, puis mappage sur un cube 3D.
  • Exemple text-input : affichage de zones interactives pour les formulaires via setHitTestRegions et fireOnEveryPaint.

Essai développeur et précautions

  • Activez via le flag de Chrome Canary --enable-blink-features=CanvasDrawElement.
  • Le contenu du canvas pouvant ne pas être tainted, il faut impérativement rester vigilant face aux risques de fuite d'informations personnelles.
  • L'API et son comportement évoluent en permanence, et les cas de tests HTML à grande échelle sont encore insuffisants.
  • Les retours sont bienvenus : signalez les questions de compatibilité, les cas d'échec de rendu et les problèmes d'accessibilité en créant une issue sur GitHub.

Valeur d'usage et perspectives

  • En chartes, dataviz, UI in-canvas, HUD/menus dans les jeux 3D, etc., cette API améliore la capacité d'expression et de productivité du web.
  • Là où la conversion HTML→Canvas (style, mise en page, support multilingue, accessibilité) était auparavant complexe, elle peut désormais être traitée directement via une API standard.
  • Attendue comme une technologie puissante pour les développeurs de graphismes, de jeux et d'applications web.

À lire aussi

1 commentaires

 
GN⁺ 2025-08-07
Commentaire Hacker News

  • Il y a beaucoup d’inquiétudes sur l’accessibilité et les abus, mais il faut aussi regarder un autre côté de cette discussion. J’ai vu récemment un fil intéressant sur X, où l’on disait que 90 % des bonnes choses qui pourraient se faire sur le web ne sont pas faites parce qu’on ne peut pas utiliser le rendu de polices et les métriques en JS. Le web est une plateforme conçue pour afficher du texte, pourtant certains ont fait remarquer qu’il n’y a pas de fonctionnalités pour le manipuler en détail ; les réponses évoquaient aussi que c’était regrettable de devoir implémenter de force des mesures de texte dans tldraw (fil X : https://x.com/_chenglou/status/1951481453046538493) Puisque le web est une plateforme de développement d’applications, le rendre facile et puissant est bénéfique pour tout le monde. À mon avis, les API web devraient descendre plus bas au niveau système ; une API de métriques de polices et de texte dédiée au canvas serait vraiment bienvenue. En même temps, le moteur de mise en page de texte du web est incroyablement performant : si cette fonctionnalité pouvait aussi être utilisée à l’intérieur du canvas, cela ouvrirait d’excellentes possibilités. Le cas que je reviens sans cesse depuis des années, c’est l’édition de texte enrichi paginée : Google Docs a dû créer son propre moteur de mise en page car contenteditable ne permet pas une implémentation au niveau produit. Si cette proposition est adoptée, on aurait à la fois la puissance de contenteditable et la possibilité de contrôler une mise en page de type page/impression. J’espère que cette fonctionnalité sera intégrée au navigateur.

    • Je suis sceptique sur le principe selon lequel « la plupart des belles choses à faire sur le web sont impossibles faute d’accès au rendu de polices et aux métriques ». J’aimerais voir des exemples concrets d’innovations emblématiques. De toute façon, JS fournit déjà pas mal d’informations sur les polices et les métriques, et la plupart des cas d’usage peut être contourné sans régression de performance majeure. En outre, HTML-in-Canvas ne change pas fondamentalement ce point.

    • Je suis aussi, chez Nutrient, en train d’utiliser Harfbuzz avec un moteur de mise en page maison basé sur WASM, un peu comme Google Docs. Démo : https://document-authoring-demo.nutrient.io/ Si cette API était fournie officiellement par la plateforme, le développement serait bien plus simple. WASM fait que ce n’est pas une impasse réelle. J’ai appris qu’il y avait des travaux de synchronisation chez ElectricSQL, donc salutations à Oleksii.

    • Quand tu dis « j’espère que ça arrivera dans les navigateurs », je ne comprends pas pourquoi on veut étendre vers le canvas l’un des moteurs de layout/UI les moins efficaces du monde. Cela ne ferait que figer le problème actuel du manque d’accès à de bonnes API. Figma fonctionne justement en créant une sorte de navigateur dans le navigateur pour dépasser les limites du DOM (voir : https://www.figma.com/blog/building-a-professional-design-tool-on-the-web/) Si contenteditable ne permettait pas une implémentation produit et que Google Docs a donc dû créer son propre moteur, cette nouvelle proposition aura du mal à aider concrètement la mise en page riche.

  • Je pense que c’est utile, mais la structure HTML-in-Canvas, avec du HTML dedans, me semble assez étrange et un peu mal accordée. Selon moi, le canvas devrait devenir un format de premier ordre indépendant dans le navigateur pour être bien intégré. Ainsi, ce serait naturel soit d’insérer du canvas dans une page orientée HTML, soit d’insérer des éléments HTML dans un contexte orienté canvas. Bien sûr, c’est juste mon avis.

    • Ton raisonnement me paraît cohérent. Pour rappel, on peut déjà imbriquer du HTML dans du SVG puis à nouveau dans du HTML. Si le canvas est l’élément le plus haut d’une page, où stocke-t-on le titre ? On finit donc par devoir utiliser une balise , par exemple :

      
My canvas site

      Il suffirait de permettre d’insérer réellement du contenu dans la balise canvas pour résoudre ça proprement :

      
  Canvassing

    • Les sites centrés sur le canvas ont beaucoup d’inconvénients. On ne peut pas utiliser l’ensemble des services système (autocomplétion, accessibilité, etc.) et il y a aussi des questions de vie privée. Par exemple, il devient difficile d’utiliser la correction orthographique système, et comme l’accessibilité système n’est pas fournie, chaque application doit implémenter une accessibilité UI complètement différente.

    • Si tu suis cette architecture, c’est un peu comme réinventer Flash. Mais intégrer Flash au web n’a d’ailleurs pas été une mince affaire.

    • Il arrive de vouloir ajouter du layout ou du styling au texte dans un canvas présent dans une page HTML. Changer le mode de layout de toute la page serait une complexité inutile.

    • On a déjà vu des gens refuser l’accès DOM via WASM. J’y vois donc une évolution inévitable de cette direction.

  • On en est déjà à compiler un navigateur entier en WASM et à l’exécuter dans un élément canvas du navigateur principal.

  • Dans le document https://github.com/WICG/html-in-canvas/blob/main/security-privacy-questionnaire.md, un TODO indique qu’il faut ajouter davantage sur le risque de « fingerprinting ».

    • J’ai vérifié dans le texte : cette partie doit vraiment encore être ajoutée (elle pourrait peut-être référencer aussi le TODO: Don't be evil).

  • L’idée d’utiliser la balise foreignObject de SVG permet déjà d’obtenir des résultats proches de HTML-in-Canvas. Par exemple, il existe des projets comme https://github.com/zumerlab/snapdom, qui copient le DOM avec des styles inline, l’insèrent dans un foreignObject du SVG, puis rendent le tout dans un canvas.

    • Cette proposition ressemble à une manière plus simple de dessiner des foreignObject dans le canvas. Elle apporte en plus des fonctionnalités nouvelles comme la mise à jour automatique du canvas quand le contenu change, et des interactions.

  • Je pense, sans vouloir être totalement sûr, que rendre du HTML au-dessus d’un canvas avec du JS pur est déjà suffisamment possible. Le canvas sert à dessiner ce qui ne peut pas l’être en HTML, il n’a pas vocation à remplacer le DOM.

    • À titre d’exemple,

      1. on veut afficher un modèle 3D d’une statue de musée ;
      2. il faut ajouter des annotations sur les caractéristiques importantes du modèle, et si ces annotations dépassent de simples mots ou chiffres, elles doivent passer derrière le modèle 3D quand il la recouvre, ce qui est extrêmement difficile à gérer en HTML uniquement, avec des calculs de position complexes et des soucis de latency. Avant, en surimposant les annotations au canvas HTML, on ne pouvait pas vraiment afficher/cacher plus que la totalité des annotations. 3D text ou SDF... si on construit un système de rendu dédié, on perd l’accessibilité et doit tout réimplémenter, pour des UI complexes (vidéo, listes, sélecteurs, etc.), on doit revenir au HTML.

    • Si les éléments HTML sont au-dessus de tout ce qui est canvas, c’est correct, sinon il faut en plus poser un canvas au-dessus du HTML ; c’est répétitif couche par couche sur les niveaux z. Avec ce changement, je pense qu’on pourrait enfin corriger cette « pile inversée des couches de rendu » des navigateurs. Je pense que tout le rendu navigateur devrait s’empiler sur une API canvas universelle.

  • On va sans doute finir par avoir besoin, dans HTML-in-Canvas lui-même, de faire du rendu canvas à nouveau.

    • Si les canvas imbriqués utilisent la même approche, ça marcherait déjà. Mais ce n’est pas une vraie récursion : pour obtenir un canvas réellement récursif, il faut dessiner manuellement le contenu du canvas parent dans le canvas enfant.

  • Ça fait penser au meme Pimp My Ride : comme si quelqu’un disait : « Je me suis dit que tu aimais HTML, donc je t’ai mis du HTML dans du canvas, puis du canvas dans du HTML ».

  • Je me demande s’il ne vaudrait pas mieux ajouter un attribut au body comme ça :

    Du coup, toute la page devient une surface de dessin identique à celle d’un canvas, et on peut continuer à rendre des éléments DOM normalement. Il serait peut-être préférable d’exposer aussi la rasterisation du DOM. L’architecture ferait du rendu DOM et du rendu canvas des couches totalement équivalentes. Par exemple, une action qui trace une ligne sur la page pourrait déclencher, ou non, un reflow d’élément DOM.

    • Je vois tous les lecteurs d’écran hurler en même temps.

    • Avec cette approche, le redimensionnement automatique du canvas pourrait aussi devenir possible ; si c’est le cas, ce serait une nouvelle ère de composition HTML, on pourrait dépasser les iframes.

  • C’est maladroit, mais je suis plutôt favorable à cette proposition. Quand il faut dessiner quelque chose, on a souvent besoin de réutiliser des éléments HTML existants. Avant, on les rendait en bitmap en offscreen pour les copier ensuite dans le canvas, ou on bricolait du z-index et des position: absolute, mais le canvas finissait toujours par recouvrir visuellement (cela s’est d’ailleurs pas mal amélioré récemment). Cette approche n’est peut-être pas une solution parfaite, mais je la trouve bien meilleure que les anciens contournements. C’est une solution utile, comme html2canvas : quand c’est vraiment nécessaire, c’est faisable.