Chrome 157 Brings HTML-in-Canvas to Interactive DOM Content in Graphics Scenes

HTML-in-Canvas has arrived in the stable release of Chrome 157. As Habr reports, following an origin trial, the browser can display interactive HTML elements inside a canvas in 2D, WebGL, and WebGPU. Text and forms remain part of the DOM even when they become part of a graphics scene. Before adopting the API, developers need to check for support and prepare a fallback interface.

Why put HTML inside a canvas?

Until now, teams building complex graphical interfaces had two main approaches. The first was to draw text and controls using canvas. This gave them control over the visuals, but the browser saw the result as pixels. To make such an interface readable by a screen reader, they had to build and maintain a separate DOM version. Page search, text selection, and copying also required additional solutions.

The second approach was to position regular HTML elements over the canvas. That preserved the browser’s built-in features, but the elements’ positions had to be kept in sync with the graphics. When scrolling, zooming, or moving the camera, the HTML and the scene could drift apart. An overlay is also hard to place behind a 3D object or include in a reflection within the scene.

HTML-in-Canvas combines these approaches: the browser displays a designated HTML element in the canvas while continuing to treat it as DOM content. Text gets CSS styling and normal browser layout. It can be selected, copied, found on the page, and translated; elements retain context menus and form features, including autofill.

The content appears in the accessibility tree for screen readers, and element styles can be inspected and changed in Chrome DevTools. The article also says that DOM content inside a graphics scene is available to search crawlers for indexing. Text drawn directly with fillText() has none of these properties without a separate implementation. Chrome previously tested the HTML-in-Canvas API; now it has reached the browser’s stable release.

How rendering works and what to check

First, the canvas gets a content="drawable" attribute, and a child HTML element is marked with the drawable attribute. What happens next depends on the rendering context. In 2D, the element is drawn with drawElementImage(), and the browser syncs its position with the image by default. In WebGL and WebGPU, the developer calculates the transform and passes it to updateElementGeometry().

This differs from placing HTML over a canvas: there is no need to write new CSS transforms on every frame to keep the layers aligned. But the team still has to handle scene geometry. If an element is in 3D, its transform must still be calculated and passed to the browser so the DOM and graphics line up.

The result can be saved as an image using toDataURL() or toBlob(), or captured as a video stream with captureStream(). Potential uses include editor workspaces, interactive elements in 3D scenes, and HTML typography combined with shader effects. For example, text can remain selectable even when it is visually part of a graphics composition.

A stable Chrome release does not mean every browser supports the API. The article recommends checking for it first. If it is unavailable, developers can show an alternative HTML interface, use overlays on the canvas, or turn to third-party libraries. For teams already working with graphics libraries, it describes integrations with Three.js, PlayCanvas, Babylon.js, and PixiJS. Three.js support is described as experimental.

What this means for projects

For developers building editors and visualizations, this offers a way to put text and controls in a workspace without reducing them entirely to pixels. It may reduce the need to maintain a separate, invisible DOM for accessibility. But HTML alone does not make an interface usable: its structure, form behavior, and interaction with the graphics still need to be designed and tested.

For a website owner or marketer, the main question is whether the project needs a scene where people interact with text and forms as part of the graphics. If a regular page can do the job, there is no reason to move it into a canvas. The API is more useful where the existing overlay approach is already getting in the way: for example, when elements need to move with objects in a 3D scene or appear in an exported composition.

When planning such a feature, it is worth accounting for a scenario without HTML-in-Canvas from the start. That way, access to important content will not depend on support for the new API, and the team can choose a graphics approach based on the task rather than the capabilities of a single browser.

My take

I like that this new browser API addresses a clear problem. I’m especially keen to try it in tools where text previously had to be drawn as pixels or manually kept in place over a moving canvas. Preserving DOM features right in the scene seems more useful than another graphics trick.

But I would not move a regular interface into a canvas just because it is now possible. For a page without complex graphics, that would add work. And if motion does not help someone complete a task, it consumes their attention—even when the browser can render the scene quickly.

Sources

Where the news comes from. The text is a retelling in the author’s own words; the facts come from the source, the opinion is the author’s.

1. [Перевод] HTML-in-Canvas в Chrome 157: интерактивный DOM в 2D, WebGL и WebGPU habr.com

About the author

Borislav Ganev

senior frontend developer

I build interfaces with TypeScript and gradually bring successful team practices into my own side projects. I especially like new browser APIs—when they solve a clear problem rather than just looking good in a demo.

All posts by the author