Chrome's HTML-in-Canvas Experiment Might Make the

There's a weird explosion happening on dev Twitter right now, and for once it's not people arguing about semicolons. Developers are dropping interactive HTML elements into 3D scenes, making jelly sliders that actually work, and building websites where you have to play pinball to unsubscribe. It's chaotic, it's experimental, and honestly? It might be exactly what the web needs.

The catalyst is HTML-in-Canvas, a new Chrome experiment that's currently available in Chrome Canary behind a flag. The pitch is simple but potentially game-changing: take real, interactive DOM elements and render them directly inside WebGL or 2D canvas scenes. Not fake them. Not rebuild them from scratch. Just... put them in there.

What Canvas Has Been Missing

Here's the tension that HTML-in-Canvas is trying to resolve: Canvas is incredible for custom UIs and visual effects that CSS can't touch. Want physics-based interactions? Particle systems? Game-like interfaces? Canvas is your tool. But canvas has always been terrible at the stuff HTML does effortlessly—complex text layouts, forms, accessibility, internationalization.

The Better Stack developer in the video explains it clearly: "Canvas can enable some awesome UIs and customizations... things that are harder to do, if not impossible in CSS. But what canvas can't do is easily render complex layouts of text and HTML content. You tend to have to rebuild them from scratch internally."

That rebuilding is where things get messy. Developers have spent years recreating text rendering, form inputs, and interactive elements inside canvas contexts, and the results are usually worse than just using HTML. Worse accessibility. Worse performance. Worse everything except the specific visual effect you wanted.

HTML-in-Canvas proposes a different approach: keep your HTML as HTML, but make it available as a texture inside your canvas scene. It's still real HTML—it's in the accessibility tree, it can receive focus, it updates live—but it renders inside your 3D world or custom canvas layout.

How It Actually Works

The implementation is cleverer than I expected. You start by putting your HTML elements as children of the canvas element itself. Normally, these would just be fallback content for browsers that don't support canvas. But with HTML-in-Canvas, you add a [layoutSubtree](https://html-in-canvas.dev/) attribute to your canvas, which tells the browser to treat those children as real layout participants.

Here's where it gets interesting: those elements are still invisible. They're in the DOM, they're accessible, but they're not painted to the screen. To actually see them, you convert them into textures using functions like textElementImage2D for WebGL or drawElementImage for 2D canvas.

The video demonstrates this with a London Underground timetable that gets embedded into a Three.js scene. The HTML element updates live—the clock ticks, times change—and those updates automatically flow through to the canvas texture. "You can think of this as essentially just looking at what this element would be, taking a screenshot of this, and then placing it in the texture's place," the presenter explains.

It's basically live screenshotting, but optimized and built into the browser.

The Demos Are Wild

Once developers got access to Chrome Canary with the flag enabled, Twitter exploded with experiments. Wes Bos built something. Matt Rothenberg's demo kicked off the wave. Someone made a jelly slider that's still a real input element underneath—just rendered with physics effects on top.

The variety is what's striking. Some demos are practical: better form interactions, 3D data visualizations with real HTML tooltips. Others are pure whimsy: floating eyes that follow your cursor, interfaces that bounce and squish while remaining fully functional.

There's even a dark pattern demo where you have to play pinball to unsubscribe from something. Which is terrible UX but also kind of proves the point—you can make web interactions feel like anything now, not just rectangular boxes.

The Current Reality Check

This is an experiment for a reason. The proposal's GitHub page is honest about the current limitations, and they're not trivial.

Performance is "a little bit wonky," as the video puts it. There are timing bugs where drawElementImage can be a frame late compared to the DOM state, causing visual desyncing. And apparently if you try to put a scrollbar inside your canvas children, Chrome just crashes. Not "doesn't work"—crashes.

These aren't fundamental problems with the concept, though. They're the kind of issues you'd expect from an early experimental implementation. The Chrome team is actively looking for this feedback.

More interesting are the privacy concerns. HTML-in-Canvas could theoretically leak information for fingerprinting—system colors, themes, spelling and grammar markers, visited link states. The proposal includes privacy-preserving measures to exclude this sensitive data, but it's a legitimate tension. Adding new browser capabilities always creates new vectors for tracking.

Why This Matters Beyond the Gimmicks

It's easy to look at jelly sliders and bouncing eyes and think this is just developers playing with toys. And sure, some of it is. But underneath the whimsy, there's a real accessibility story here.

Right now, if you want a custom canvas-based interface, you often have to choose: make it beautiful and inaccessible, or make it accessible and constrained by HTML's visual limitations. HTML-in-Canvas suggests you might not have to choose. Your screen reader can still read your 3D interface because it's still real HTML underneath.

That's not guaranteed—developers can still make inaccessible garbage with any tool—but at least the path of least resistance now includes accessibility by default.

The video's presenter admits their enthusiasm: "I like what I've seen so far, so I would love if this could break out of just being an experiment." Same, honestly. The web has felt increasingly same-y, with every site using the same component libraries and design patterns. Some of that's good—accessibility and usability matter. But we've also lost some of the weird, experimental energy that made early web development fun.

HTML-in-Canvas won't single-handedly bring back web whimsy, but it removes a technical barrier that's been there for years. Whether developers use it to build genuinely better interfaces or just make everything wobble unnecessarily is up to us. Both seem fine, actually.

Tyler Nakamura is Buzzrag's consumer tech and gadgets correspondent.