---
title: "Comment by Steven Mock on \"HTML-in-Canvas: what it is, how it works, and how to use it\" | Hashnode"
description: "The part that stood out to me is that this is not a replacement for HTML — it is a way to keep the good parts of HTML inside the places where canvas already mak"
url: "https://hashnode.com/posts/html-in-canvas/6aec82e4dce36c6085de1b0e/comment/6aeeaf4051134f1647c7cc53"
---

[Discussion](https://hashnode.com/posts/html-in-canvas/6aec82e4dce36c6085de1b0e)

Comment [HTML-in-Canvas: what it is, how it works, and how to use it](https://hashnode.com/posts/html-in-canvas/6aec82e4dce36c6085de1b0e)

[Steven Mock](https://hashnode.com/@stevenmock)

[4d ago](https://hashnode.com/posts/html-in-canvas/6aec82e4dce36c6085de1b0e/comment/6aeeaf4051134f1647c7cc53)

The part that stood out to me is that this is not a replacement for HTML — it is a way to keep the good parts of HTML inside the places where canvas already makes sense. Keeping real DOM elements, with proper fallbacks and tests, means you do not lose text selection, focus, or accessibility just because one piece of a page needs to be drawn rather than laid out normally.

For the kind of sites I work on, most pages should stay plain HTML. But for an interactive map, a 3D view, or a complex visual where a rich HTML label would otherwise be hard to draw, this looks like a genuinely useful middle ground — as long as it is used sparingly and the fallback is tested, not just assumed to work.