Canvas UI Renders HTML Inside Canvas Elements

There's a specific quality to watching something that shouldn't work, work. Not a magic trick where you know there's a hinge somewhere—more like watching a building material do something it isn't supposed to do. That's the reaction David, the developer behind the React Bits library, seems to have been going for when he built Canvas UI, a component library that does something the web browser genuinely could not do until very recently: render interactive HTML inside a canvas element.

If you're not a developer, here's the short version. The <canvas> element in a browser is essentially a pixel-drawing surface. You can paint things on it—animations, game graphics, generative art—but those things are inert. You can't highlight text on a canvas, click a button, or fill out a form. It's a picture of interactivity, not interactivity itself. The DOM (Document Object Model), on the other hand, is the layer of a web page where everything is interactive—text you can select, links you can click, inputs you can type into. For decades, those two worlds didn't mix.

Chrome's recently introduced HTML-in-Canvas API is what changed the math. It's still an origin trial—meaning it's live for testing but not yet in stable Chrome—and David moved fast enough to build an entire component library on top of it. Canvas UI launched with 24 components, each demonstrating a different visual effect that now, for the first time, can wrap around fully functional HTML.

The OrcDev video walkthrough makes a reasonable case for why this matters. The host runs through each component in sequence, and the cumulative effect is genuinely strange to process: a page where the text appears to be submerged under water droplets that bead and run down your screen. A card that peels back at the corner like a sticker when your cursor approaches the edge. A cloth component that makes the entire page appear to ripple like fabric in wind—while you can still highlight, copy, and click everything on it. "We are not inside of some canvas, inside of some game where we cannot do anything," the host explains. "We are actually here like involved in these droplets."

That observation cuts to what's architecturally different here. Previous canvas-based visual effects on the web achieved their illusions by essentially faking it—drawing pixels that resembled HTML content while hiding the real DOM underneath, or layering transparent elements on top of canvas in careful z-index gymnastics. Those approaches were brittle, performance-hungry, and limited in what interactions they could support. Canvas UI's components don't fake HTML; they contain it. The interactivity isn't simulated.

What the library actually includes

The 24 components span a wide tonal range. Some are atmospheric: Blaze puts fire and heat distortion at the bottom of a page. Clouds renders drifting, customizable cloud layers with hover-responsive behavior. VHS applies a video-tape degradation filter that the host suggests could work for browser-based point-and-click games.

Others function more like interaction design tools with a surrealist twist. Magnify creates a glass-lens cursor that enlarges text as it passes over—the host flags this, tentatively, as potentially useful for accessibility. Peel lets cards fold back at their corners. Ripple generates water-ring animations from click events anywhere on the page.

The ones that generate the most visible reaction in the video are Droplets and Hex Float. Droplets renders what looks like condensation running down a glass surface, convincingly enough that the host describes the instinct to wipe the screen. Hex Float tears the page apart into geometric fragments that drift around while remaining fully readable and interactive. "We are inside of the Teenage Mutant Ninja Turtle movie and it's crazy," is how he puts it, which is a specific reference but gets the energy right.

There are also two 3D model components—Third Object and Particle Object—that accept standard GLB or GLTF files (common 3D model formats) and embed them directly into the page. The host used one to render his own avatar on his site, built in two prompts with an AI assistant. Whether or not that workflow represents something generalizable is worth a separate conversation, but as a demonstration of the component's floor-level accessibility, it lands.

The integration story

Canvas UI is registered as a shadcn/ui component—shadcn being a popular React component system that lets developers add components via a single terminal command rather than installing a full package. For anyone already working in that ecosystem, the on-ramp is minimal. For anyone outside it, there's a playground at canvasui.dev that lets you manipulate components and adjust their parameters in real time: change cloud color, resize a lens trail, swap out 3D models, toggle grayscale.

Every component exposes its behavior through props and parameters, so customization doesn't require understanding the canvas rendering pipeline underneath. That abstraction layer is worth noting because it determines who can actually use this. A front-end developer comfortable with React can drop a Cloth or Droplets component into a project without knowing anything about WebGL or pixel shaders. The host frames this as democratization; it's also fair to frame it as abstraction, which carries its own tradeoffs when things break or need to be debugged.

What to hold in tension

A few things are worth sitting with before treating this as settled territory.

The HTML-in-Canvas API is an origin trial, not a shipping feature. Origin trials are Chrome's mechanism for gathering real-world usage data on experimental APIs before committing to them. They can be extended, modified, or discontinued. Canvas UI is built on infrastructure that may still change, which means components that work today could require updates as the API stabilizes—or could be affected if the feature ships with different constraints than the trial version.

There's also the browser support question. Chrome's origin trial doesn't cover Firefox, Safari, or other browsers. For any production use case where audience browser diversity matters, Canvas UI components may currently function as progressive enhancements at best—and invisible or broken at worst for non-Chrome users. That's not a dealbreaker for every use case, but it's a real constraint the demo video, understandably, doesn't dwell on.

And the performance claims, while consistent throughout the video, are demonstrated on a single machine under demo conditions. Canvas-based rendering is GPU-dependent in ways that standard DOM rendering isn't. What feels smooth on a high-end development machine may perform differently on a mid-range laptop or a phone. The library's accessibility posture—the magnify component aside—is largely an open question.

None of this is a reason to dismiss what David built. "If you told me two years ago that something like this would be possible on a web page, I would just tell that you're crazy, and that's it," the host says, and that's an honest read. The combination of Chrome's new API and a well-executed component library has produced something that looks categorically different from what web UI has been able to do before.

The more interesting question is what this looks like in six months, when either the API ships to stable Chrome with broader browser interest following, or it doesn't—and a library built on an origin trial has to figure out what it is without its foundation. The web has a long history of features that looked like paradigm shifts in demo form and then quietly stalled in the specification process. It also has a history of the opposite.

Canvas UI is a sharp piece of work built on genuinely new infrastructure. Whether this is the beginning of something or a high-water mark for an experiment depends on decisions that aren't David's to make.

---

Leo Santana covers design and visual culture for Buzzrag.