html-in-canvas
A live HTML contact form rendered inside a playing copy of DOOM.
An HTML form, rendered into a canvas texture, mapped onto an in-game surface inside a JavaScript port of DOOM running in the browser. You can click into it, type, submit it. All while the demons keep advancing. Pointer events are routed back through the canvas to the right input field.
Once you accept that the rendering surface of a web page can be anything (a Three.js scene, a WebGL canvas, an emulator, an embedded game engine), the question becomes: how far can you push HTML into that surface and have it still behave as HTML? Forms are the strongest test, because they have to accept focus, take typing, and submit. DOOM is the loudest possible host.
An html-in-canvas pipeline: render the form to an offscreen canvas, project that canvas as a texture onto a polygon inside the game,
and route the inverse pointer transform back through so a click at screen-space (x, y) becomes a click at form-space (u, v). The
form itself is a stock <form>; nothing about it knows it is being projected onto a wall in DOOM.
The loudest possible demonstration of html-in-canvas: arbitrary, fully-interactive HTML can live inside any rendering surface a browser can produce. Three.js scenes, simulations, even an embedded game engine. The "edge of the form" is wherever you want it.
More practically: if your product UI needs to escape the rectangle (configurators, immersive marketing, anything where the interface should react to a scene rather than sit on top of it) the same pipeline applies.
All experimentsIf your product needs UI that escapes the rectangle, the same pipeline applies.
Misbehaving stack? Codebase that won't play fair?