HTML-in-Canvas

Original Article ↗ Hacker News Discussion ↗

Use cases and motivations

  • Need for “DOM screenshots” / rendering arbitrary HTML into bitmaps, with native APIs instead of heavy JS libraries (e.g., html2canvas) and hacks.
  • Strong interest from 3D / WebGL / WebXR: putting rich HTML UIs, annotations, and MDX-like content onto 3D surfaces or inside VR scenes, with proper occlusion and interaction.
  • Desire for robust, paginated rich-text editing and document-style layout (Google Docs–style) using the browser’s own layout engine instead of reimplementing it in JS/WASM.
  • Canvas-based apps (games, creative tools, charts) want styled, internationalized, accessible text without writing their own layout engines.

Existing workarounds

  • Use of SVG foreignObject to embed HTML into SVG, then draw SVG to canvas; projects already do “DOM screenshots” this way.
  • Libraries and engines (custom layout engines, Sciter-like APIs, canvas layout libraries) attempt HTML-like layout and text inside canvas with significant complexity.
  • Common hack: render HTML over or behind a canvas and synchronize positions/z-order; this fails for true 3D occlusion and is brittle for interaction.

Security, privacy, and fingerprinting

  • Many expect the feature to be constrained or blocked due to fingerprinting: different engines render HTML slightly differently, and pixel readback gives a high-entropy fingerprint.
  • Past abuse of canvas (e.g., steganography in ads) and potential to capture sensitive iframe content (like banking UIs) are cited.
  • Some argue the real problem is readback APIs (ImageData), not drawing, but others see this as another “big fingerprinting target.”

Accessibility impacts

  • Some fear “RIP accessibility,” especially if it encourages canvas-first Flash-like sites.
  • Proposal defenders say accessibility is a core motivation: mapping HTML elements drawn into canvas to the accessibility tree and ensuring fallback content matches rendered content.
  • Debate over whether full-page canvas modes or canvas-first UIs can ever match system-level accessibility and user services.

Architecture and philosophy

  • Mixed reactions: some see it as cursed recursion (“browser in a browser”), others as simply exposing the existing layout engine in another context.
  • Several suggest focusing instead on lower-level text/font/metrics APIs for canvas.
  • Broader debate on HTML-first vs canvas-first models, and on whether lack of direct WASM–DOM APIs is pushing the ecosystem toward these kinds of solutions.