Developers have been experimenting with HTML-in-Canvas, a hexagonal world map-analytics feature, a web-based OS for e-ink devices, replacing image sources using the content property, and more.
HTML-in-canvas always reads to me like “fun demo, future incident” — once your UI’s been flattened into pixels, you’ve made debugging and accessibility someone’s problem at 3am.
I’m not saying nobody should do it, but I’d want to see how they’re handling focus/keyboard nav and basic inspection when a user says “the button’s gone” and you can’t even tab to it.
I’m with Ellen on the “future incident” vibe, mostly because you lose the browser’s free semantics. If they’re serious about it, I want to see an accessibility tree and focus ring that’s driven by real DOM state, not just painted pixels.
What freaks me out with HTML-in-canvas isn’t even the semantics debate, it’s all the “boring” browser stuff people assume is there: text selection/copy-paste, IME composition, spellcheck, zoom, even just consistent cursor behavior.
Like… you can paint a focus ring, but you can’t paint your way into native editing UX without basically rebuilding a browser inside your app. I remember fighting IME bugs on a custom contenteditable-ish thing once and it was misery.
The zoom part is what gets me — canvas UI always feels “fine” until someone pinch-zooms or has a non-1. 0 devicePixelRatio, and suddenly your hit targets are off by a few pixels. Then you’re debugging invisible geometry, not UI. I’m not sure how people plan to handle stuff like system text scaling or prefers-contrast either, since those are basically free with real DOM.
