Doom avec de vrais sites web intégrés : le hack Chrome le plus bizarre de l'année

Doom a tourné sur des tests de grossesse, des calculatrices et des vapoteuses. Cette fois, c'est l'inverse : du HTML tourne à l'intérieur de Doom.

Le développeur Robin (@solarise_webdev) a publié une démo qui affiche de vrais éléments HTML sur les murs de Doom. Pas une image figée, pas une capture d'écran : des formulaires interactifs avec champs de saisie et boutons fonctionnels. Le gestionnaire de mots de passe du navigateur a même tenté de remplir un champ, bloquant le personnage au passage. La preuve que le HTML était bien réel.

Comment du HTML finit sur les murs d'un jeu de 1993

La démo repose sur HTML-in-Canvas, une proposition du Web Incubator Community Group (WICG) actuellement testée derrière un flag expérimental de Chrome. L'API introduit une méthode appelée drawElementImage(). Elle permet de capturer le rendu d'un élément du DOM et de l'injecter dans un contexte <canvas>, y compris en WebGL.

Dans le cas de la démo Doom, le principe fonctionne en trois temps. Le jeu tourne via doom.wasm, un portage WebAssembly du code source original. À chaque tick du moteur, la fonction drawElementImage() capture le formulaire HTML affiché en arrière-plan. L'image obtenue est ensuite convertie dans la palette 256 couleurs de Doom, puis écrite dans le cache de textures du jeu. Le moteur de rendu fait le reste : perspective, éclairage par secteur, teinte rouge de dégâts. Le HTML subit exactement le même traitement qu'une texture murale classique.

Pour tester la démo, il faut activer le flag chrome://flags/#canvas-draw-element dans Chrome Canary. Le dépôt WICG sur GitHub propose d'autres exemples : graphique en camembert, cube WebGL habillé de HTML. Chrome continue d'empiler les API expérimentales dans ses versions bêta, entre réseaux neuronaux et rendu HTML hybride.

Derrière la blague, une brique manquante du web

L'API résout un vrai problème. Jusqu'ici, dès qu'un développeur travaillait dans un <canvas>, il perdait l'accès aux capacités du navigateur. Pas de mise en page automatique, pas de texte stylé, pas d'accessibilité pour les lecteurs d'écran. HTML-in-Canvas propose de réintégrer ces éléments dans le canevas sans les sacrifier.

Les cas d'usage envisagés vont bien au-delà de Doom. Les outils de création graphique pourraient afficher du texte enrichi directement dans leur zone de travail. Les jeux web pourraient intégrer de vrais menus accessibles plutôt que des imitations dessinées en pixels. Les applications de visioconférence ou d'export vidéo pourraient capturer du contenu HTML mis en page et l'encoder nativement.

L'API reste expérimentale. Chrome l'a approuvée pour un essai entre les versions M148 et M151. Ni Mozilla ni Apple n'ont signalé d'intention de l'implémenter dans Firefox ou Safari. La communauté Doom, elle, n'en est plus à un portage près : calculatrices, vapoteuses, serveurs DNS, le jeu a tout vu. Cette démo-ci a au moins le mérite de braquer les projecteurs sur une brique web encore confidentielle. Le portage de Doom via un serveur DNS, publié quelques jours plus tôt, relevait du même esprit. Repousser une limite technique, juste pour prouver qu'on peut.

Doom aura servi de cobaye à peu près partout. Au moins, cette fois, c'est le jeu qui a subi l'expérience, pas l'appareil.