Before we talk about HTML-in-Canvas, indulge me for a few minutes.
Back in the early 2000s my buddy Mark had started Spark Hosting, a web hosting service. The dream was to sell hosting space to EVERYONE to fund aspirations of travel and, after finding myself a long way from home, slumming it on a sofa in Mark's parents' basement in Ohio, I decided to jump on that yellow brick road with him.
Before social media gave everyone a profile, if you wanted your own place online, you haunted web forums or built your own little corner of the internet. Everyone wanted a website. One for yourself. One for your cat. One for your aunt's tarot card reading business, even if she wasn't entirely sure what it was for.
We were so ahead of the game. We had animated Flash banners showing Spark Hosting in huge letters with flying seagulls and passing clouds, which we'd proudly slap into our signatures on every web forum we could visit. Looking back, they weren't exactly revolutionary, but at the time it felt like we were injecting a little bit of colour and fun into the Matrix.
We weren't alone either. Before YouTube, Netflix and infinite scrolling, there were websites like Homestar Runner, Joe Cartoon and Newgrounds. These weren't just animations; they were the paving stones of an interactive web. You didn't just watch Homestar Runner. You clicked around it. Strong Bad Emails hid little surprises. Joe Cartoon practically dared you to interact. Newgrounds became a place where people experimented because it genuinely felt like the web hadn't decided what it wanted to become yet.
Nobody had figured out the rules, and that was half the fun.
The quick read
The playful web: key takeaways
- The web became safer, faster and more accessible when it moved beyond proprietary plugins such as Flash.
- Standardisation solved real problems, but many websites also became more predictable.
- HTML-in-Canvas is an early proposal for drawing real HTML content into 2D and 3D canvas scenes.
- It should add delight to a usable web page, not replace the page or hide essential content.
- The opportunity is not to rebuild Flash. It is to recover its experimental spirit with better guardrails.
The web grew up
The internet stopped being a playground for enthusiasts and became infrastructure. Banks, schools, airlines, governments, shops and everyone's parents depended on it. Reliability mattered. Security mattered. Accessibility mattered. A website could no longer shrug when it flattened a laptop battery or refused to work without the right plugin.
Then the iPhone arrived without Flash. In his 2010 letter Thoughts on Flash, Steve Jobs argued for open standards, better security and performance, and interfaces designed for touch rather than mouse hover. You could take issue with the delivery, but it was hard to ignore the direction of travel.
Flash was proprietary, power-hungry and famously awkward on the open web. It created wonderful things, but it also gave us intro screens, mystery navigation, autoplaying music and loading bars that provided enough time to reconsider whether you needed the website at all.
The browser eventually caught up. HTML, CSS and JavaScript improved. Video no longer required a plugin. WebGL and later WebGPU opened routes into hardware-accelerated graphics. WebAssembly made it practical to bring more demanding software to the browser. Adobe ended Flash Player support in 2020, by which point open web standards had already become the sensible foundation.
Honestly, it had to happen.
What we gained, and what we misplaced
The modern web is better in almost every measurable way. It works across screen sizes. It is more searchable, more accessible and less likely to turn your fans into tiny jet engines. Design systems help teams build consistent interfaces. Familiar patterns mean people can buy a ticket or book a table without first solving a riddle.
Those are victories. But growing up came with compromises.
Open ten agency websites and you can often predict the next section before you scroll: enormous statement, tasteful blob, three cards, logos, testimonial, newsletter. We have become exceptionally good at assembling polished pages from interchangeable parts.
Creativity did not disappear, but it stopped being the priority. The web became a product to optimise rather than a place to explore. Every unnecessary interaction looked like friction, every surprise risked hurting conversion, and every idea eventually found itself squeezed into the same component library.
The internet rewarded exploration long before anyone started talking about engagement metrics.
Looking back, I don't miss Flash. I miss what it represented: the sense that somebody had stayed up too late making a button do something ridiculous simply because it might make another human smile.
So, what is HTML-in-Canvas?
The name makes it sound as though somebody has decided to put the whole internet inside a canvas element. That is not quite the idea.
Canvas already lets developers draw graphics with JavaScript. It is brilliant for particles, games, image tools, charts and visual effects, but ordinary HTML content is much better at text layout, forms, accessibility and adapting to different screens. Bringing the two together has traditionally meant awkward compromises: recreating interfaces as pixels, placing DOM elements over a canvas, or maintaining two versions of the same thing.
HTML-in-Canvas is an early web-platform proposal aimed at letting developers draw HTML elements into a 2D or 3D canvas while those elements still participate in layout and hit testing. In plain English, designers could use real, styled HTML as part of a richer rendered scene instead of rebuilding every label, card or control by hand.
That opens some interesting doors. A product story could move through a three-dimensional space while its content remains structured HTML. A creative tool could combine familiar controls with a high-performance canvas. A data visualisation could use readable labels and richer effects without splitting the experience into two unrelated layers.
It is important to say early. At the time of writing, the proposal is still described as a living explainer and its APIs sit behind a flag in Chromium. This is something to explore, test and influence, not a safe excuse to rebuild your checkout flow next Tuesday.
Try the experiment
Give the browser a little encouragement.
Hover over or focus the logo.Tap the logo, or watch it warm up. The familiar HTML remains in place when the experimental canvas path is not available.
Another brush, not another religion
New web technology tends to arrive with a short period in which every problem looks suspiciously suited to it. We should resist that.
Most websites do not need to become immersive worlds. A government service should be boring in the very best sense: clear, quick and dependable. The same is true for banking, documentation and the screen where somebody is trying to reset a password at eleven o'clock at night.
But some experiences are meant to create a feeling as well as complete a task. A museum exhibition, a new product launch, an educational story, a creative portfolio or a brand with a genuinely distinctive world might deserve more than another procession of rectangular sections.
That is where HTML-in-Canvas becomes exciting. Not as a replacement for the DOM, but as another brush. It could give designers and developers more room to choreograph space, motion, light, depth and interaction while keeping meaningful content connected to the page.
We have been exploring that territory at Fireplace with animated flames, embers and responsive effects that sit around ordinary web content. The useful part is not that everything moves. It is that the movement can create a moment of character without making the underlying page harder to use.
Playfulness, responsibly
If the early web taught us how memorable digital experiences could be, it also supplied an excellent list of things never to do again.
The essential content should remain understandable without the effect. Navigation should not become an escape room. Motion needs restraint and a reduced-motion option. Keyboard and assistive-technology users should not receive a second-rate version. Lower-powered devices should not be punished for visiting. If a feature is unavailable, the fallback should still feel intentional.
That is progressive enhancement: start with a solid experience and add capability where the browser and device can support it. Do not punish older or unsupported browsers. Reward the ones that can do more.
Canvas itself also needs care. Conventional canvas content is effectively a bitmap and requires useful fallback content or an equivalent accessible structure. One promising aim of the HTML-in-Canvas proposal is to improve that relationship by connecting what is drawn to corresponding HTML content. Promising does not mean automatic; designers and developers still have to test the actual experience.
Most importantly, ask why the interaction exists. Does it explain something, establish atmosphere or reward curiosity? Or did somebody discover a particle library on Thursday afternoon?
Delight is valuable. So is knowing when to leave the button alone.
The web is still experimenting
Twenty-five years ago, two friends in an Ohio basement were convinced animated seagulls could help sell web hosting to the world. They probably could not. But those banners belonged to a web that felt alive because people were constantly testing what it might become.
We should not rebuild that web. The modern one has learned too much about accessibility, security, performance and the needs of people who simply want to get something done.
But we can bring some of its curiosity forward.
HTML-in-Canvas may change considerably before it is ready for everyday production, and it may end up being useful in ways nobody has quite predicted. That uncertainty is part of what makes it interesting. For the first time in a while, the browser feels as though it may have a new corner where designers and developers can make something gloriously unnecessary, carefully considered and genuinely memorable.
Maybe the web has not finished deciding what it wants to be after all.