logoalt Hacker News

The HTML-in-Canvas API origin trial

35 points • by andrewstuart • yesterday at 7:54 PM • 11 comments • view on HN

Comments

artpar • today at 8:35 AM

I wanted to implement a whole canvas native workspace, I started with a html only implementation and "fake canvas" approach but even for moderate number of panels (~50) the responsiveness dropped quite a lot. So I went with a new implementation with "real canvas" and worked out the panels/interaction.

In terms of performance this approach worked out much better (able to easily handle 1000+ panels/nested panels at 60+ fps) but the complexity goes very high in the implementation of each panel. As in I cant just use for eg a markdown rendering js library or any third party ui component. And frequently make a change would result in massive performance degradation.

https://canaster.in/

Currently I have text/markdown/image/audio/video and pdf panel (you can drag and drop files)

I wonder if i should take another go at it and implement using html-in-canvas api. Afraid of the api being not maintained if they dont see benefit or usage?

chrismorgan • today at 7:36 AM

(May 2026.)

Related bunch of comments from that time: https://news.ycombinator.com/item?id=48201222

dvh • today at 7:03 AM

Wouldn't it make more logical sense to add canvas to html elements? I.e. checkbox.getContext("2d").fillRect(...)

➕ show 2 replies
prathje • today at 7:50 AM

I would use it to render HTML elements such as inputs or a website in videos. Even though HTML is powerful the control over every pixel is important for high quality videos.

hackyhacky • today at 8:39 AM

Honestly, I think the push to constantly add browser features (and thereby expand the already massive web API) is misguided. This feature, in particular, seems like it should be solved with library, rather than by further bloating the browser.

If I put on my conspiracy hat, it looks like Google is pushing to expand the web API as a means to maintain its lead in the browser market by making it harder for other browsers (i.e. Firefox) to maintain feature parity.

avaer • today at 6:40 AM

Back in the WebVR days the sentiment was we can never do this because security.

In my experience with standards bodies/Chrome, anything outside of the owning company's product goals is "no, because security", and then then they flip-flop on that when the browser feature becomes a dependency for something an internal team is working on (which happened many times with WebVR, now WebXR).

So I'm curious what is Google working on that has this as a dependency, now that they've 180'd on it?

➕ show 3 replies
chews • yesterday at 9:42 PM

Yo dog, we put a DOM in your Canvas in your DOM.

➕ show 1 reply