The HTML-in-Canvas API origin trial
developer.chrome.com
developer.chrome.com
Since then I've actually met these two and had to conclude that:
- They didn't have any use-cases in mind that weren't cosmetic
- They don't quite understand how being part of an advertising company shapes how they build and conceive of web tech
- They react quite poorly to reactions that aren't cheerleading
The answer for curved elements was handwaving and "just approximate it with flat projective transforms" which tells you this is not a serious attempt to expose mature UI internals, but just another shiny epicycle on the creaky leviathan that is the HTML5 web api.
The list of features that "automatically work" rests on assumptions that are only valid for minor visual adjustments. The moment you try to use HTML-in-Canvas as a more basic building block, a lot of that falls away.
e.g. Suppose I render a piece of text and then use that as a mask for visual effects. If the browser now draws a text selection highlight into that mask, the text becomes unreadable.
I've read your blog enough times to recognize it instantly, yet it's the first time I notice that you blog header is an animated and interactive 3D demo. Very cool!
As a point of comparison: Win32 has APIs that let you draw things like buttons and text input fields without having to instantiate windows (~= DOM elements) for them. Though I'm not quite sure what you can do in the way of input handling without having an actual window. Regardless, browsers manage to contort native controls into funny shapes on behalf of web pages, so the API there definitely offers more possibilities.
The DOM is a slow annoying pile when you want to make actual applications.
Which GUI toolkits over internet do you refer to?
My point is there is no GUI toolkit for the browser and there should be. They should stop trying to morph the document object model into a platform for delivering applications, let it do documents, and give us something else/new. It'd also be the proper path to the new thing having accessibility support. Instead people raw-dog the GPU for UI and you get no screenreader support.
What they're doing here is a half-assed attempt: letting people draw but using the DOM for accessibility. The worst of both worlds I guess?
Our only hope is for AI to supplant screen readers, and then we can just ship WebGPU apps.
> isn't adaptive enough to meet the needs of your users
I imagine if this conversation continues this will be quoted and argued against. My point is that it's not working well. People find workarounds to do amazing things with the browser, but they shouldn't have to. Give developers what they've wanted for 15 years. The various committees and working groups keep missing the mark, by a lot. See WASM, WebGPU shader language, etc., etc.. I'm sure it's more complicated than I realize, but if all you do is fail and disappoint, maybe your governance model and the people involved need some adjustment. Is anyone happy with WebGPU? Is anyone happy with Web Components?
/rant
Can you be more specific? Because to me the DOM is one of the simplest conceptual representations of UI one could imagine, a tree of nodes.
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?
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.
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?
If you can get by with canvas rendering, you could instead use HTML and eliminate tons of CSS and layout cost by using CSS containment and absolute positioning:
#my-container > * {
contain: strict;
position: absolute;
}(116 comments)
When activated in chrome, nesting currently works, but somehow breaks events.
Related bunch of comments from that time: https://news.ycombinator.com/item?id=48201222
Or maybe I'm behind the times; I've not done serious webdev for a long time.
https://github.com/WICG/html-in-canvas/#read-back-allowed-re...
Imagine being able to declare a list of paths with fill/stroke-paints to draw, filled in from attributes, variables and `calc()` values... one can only dream.
What I really want is something along the lines of...
@declare-some-shape MYSHAPE (ARGS) {
/* tree of draw commands */
/* can reference css animations, timelines, variables, etc. */
}
#my-div { content: draw-some-shape(MYSHAPE ARGS, TRANSFORM); }
/* or, as some kind of pseudo-element: */
#my-div::draw-some-shape(MYSHAPE) { ??? }
Doing all that is a colossal PITA, since SVGs aren't built to act as "fragments" I can arbitrarely draw with CSS or Canvas.
This new html-in-canvas API will alleviate the pain a bit, at least.
What you described is the CSS painting api (part of CSS Houdini)
You've committed to building your app using canvas but realize you actually wanted the DOM. Now you can dig yourself deeper rather than fixing the original mistake!
...all the advantages listed under "The advantages of bringing the DOM to Canvas" apply to using the DOM generally.
Actually, I can see the case for having a primarily canvas-based app that, nevertheless, sprinkles in some DOM. It's the presentation here that rankles.
(Extra points lost for using "intractable" where interactive could be used; intractable isn't an English word while interactive is. Now, since I'm not a purist, interactable can be used as a noun in contexts like game programming that need such a word, since no such English word exists. But using it as an adjective only seems OK when not a native speaker and when not making an announcement. It just reinforces the impression that they don't know what they are doing.)
The word bothering me is: interactable
WebGPU is too low level for most users so it needs a framework on top, and that would mean changing the way code distribution works (from bundling to packages) if you want it to be efficient.
Skia is at the right level but then you need to maintain two very different graphics APIs in parallel and somehow make them work together. You can't just give up WebGPU because games and graphics editors are starting to require it.
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.
This kind of stuff just puts even more distance between established engines and smaller projects like Servo.
Why? The browser is effectively already rendering HTML in a “canvas”, via tiled rendering etc. This isn’t a whole new rendering path, just a redirection of the existing one.
The browser API has become so big because the implementers are quite tenacious, with multiple parties doing “extend” in parallel…