Chromium clears HTML-in-canvas for shipping

Chromium will ship HTML-in-canvas, a set of primitives that let developers draw and lay out real HTML inside a canvas while keeping the browser’s built-in formatting, interactivity, and accessibility.

High-performance web apps often move rendering to canvas for finer control, but that choice has long meant abandoning styled multi-line text, copy-and-paste, form controls, text selection, and the platform’s accessibility tree. Developers either rebuilt those behaviors in JavaScript or shipped a poorer experience. HTML-in-canvas is meant to end that trade-off by adding layout management, drawing hooks, rendering events that keep the DOM and canvas in sync, and geometry updates that flow the other direction.

The proposal sits in a WHATWG HTML pull request and has an explainer under the WICG. It already ran as an origin trial focused on API shape. WebKit has given a positive standards position and started early implementation work; Mozilla has not yet signaled. The W3C TAG review remains pending. Proponents note a modest interop risk because the API can expose pixel-level details of gradients and form controls.

On the blink-dev list the intent received rapid approval. Alex Russell wrote, “I regret that I have but one LGTM to give,” followed within minutes by further LGTMs from Rick Byers and Yoav Weiss. Developer feedback from the trials has been positive.

Once the feature reaches stable Chromium builds, canvas-centric editors, design tools, and games will be able to host genuine HTML UI without leaving the canvas rendering path.