Canvas is a really nice vector API, very underappreciated precisely because of its elegant simplicity. Its problem is that, because it's so straightforward and well-designed, people can't easily use having had to work with it to pretend they are Big Brain.
From SVG to Canvas – A new way of building interactions
21–30 of 97 posts
Re: From SVG to Canvas – A new way of building interactions
#22Earlier quoted context omitted.
Google Docs document canvas is a tool. Most of the chrome & interface is html & works great. The switchover to canvas broke a ton of extensions. Chrome eventually went out & built a custom api to help users deal with some of the massive loss of functionality that switching off high-level html to go use lowest level html caused. But that took a ton of effort from Google, & the result is still a shadow of what was poss…
> IMO, do the right thing for user agency & stick with higher level web stuff. Reinventing has many subtle pitfalls. This is great advice 99% of the time. But the browser has two big pitfalls which hurt google docs: 1. Browser rich text editing events are famously awful and inconsistent on different browsers and platforms. 2. Google docs wants the same document to render exactly the same on all OS / browser combinati…
> 2. Google docs wants the same document to render exactly the same on all OS / browser combinations. Thats not something that web browsers guarantee.
Nor is it something Google Docs guarantees, since it still uses the browser for font shaping and rendering. The easiest way to demonstrate this is in Firefox, Settings → Fonts → Advanced → untick Allow pages to choose their own fonts, instead of your selections above, and Google Docs will layout and render the entire document using only your default font (most likely a serif). Not even doing a serif/sans-serif/monospace generic font fallback.
(I’ve had that unticked for almost a year and a half now: it makes the web so much better on average, with minimal damage, almost all on Google properties due to their Material Icons font’s stupid ligation technique.)
Re: From SVG to Canvas – A new way of building interactions
#23Earlier quoted context omitted.
I spoke to the original creator of Google Docs (from before it was Google Docs, https://www.theverge.com/2013/7/3/4484000/sam-schillace-inte... ) and he confirmed what you recall; they had to write their own text rendering code because the browser does not implement the behavior required by a word processor (one example: flowing text around an image)
That was long before they switched to canvas rendering, too: they were still just using contenteditable, though potentially with mild layout augmentation with things like absolute positioning and sizing of things (I don’t know). Flowing text around an image: the web has been able to do this for donkey’s years, it’s the float property. More recently, there’s the CSS shape-outside property that even lets you use non-re…
IIRC float is just left or right, you can't embed an image "in the middle" of text. I'm no web expert and the conversation was a decade ago, so I'm sure something got warped in translation.
Re: From SVG to Canvas – A new way of building interactions
#24Earlier quoted context omitted.
Google Docs document canvas is a tool. Most of the chrome & interface is html & works great. The switchover to canvas broke a ton of extensions. Chrome eventually went out & built a custom api to help users deal with some of the massive loss of functionality that switching off high-level html to go use lowest level html caused. But that took a ton of effort from Google, & the result is still a shadow of what was poss…
> IMO, do the right thing for user agency & stick with higher level web stuff. Reinventing has many subtle pitfalls. This is great advice 99% of the time. But the browser has two big pitfalls which hurt google docs: 1. Browser rich text editing events are famously awful and inconsistent on different browsers and platforms. 2. Google docs wants the same document to render exactly the same on all OS / browser combinati…
I have quite a lot of sympathy for Google, but I'd wager 90%+ of people heading down the Canvas path have really shoddy cases for why they're doing it.
I'd also love to see more hybridization. With something like Figma, I both am sympathetic to their use of canvas. But I'd love it if they had a hybrid renderer that could also use HTML as well, with fixed position divs and HTML text. There used to be a slow but steady stream of blog posts on combining HTML and WebGL, some even with nice css3d transforms to make HTML act like a texture, but overall I don't think we've seen much hardcore uptake or attempts.
Re: From SVG to Canvas – A new way of building interactions
#25Earlier quoted context omitted.
i'm building a diagramming tool ( https://terrastruct.com ) and still umm and ah b/t it. I'm kind of waiting for webgpu to reach 95+% browser support before switching though. If I do all the work of switching, SVG better not get gpu/hardware-acceleration support the next day
I'm confused... Figma can seemingly do all of this already, from a rendering perspective. And it's outrageously performant. It's one of the most performant web apps I've ever seen. Why don't you do exactly what Figma is doing?
It's hard to get as performant as Figma does, not as straightforward as a rendering medium switch. What if webgpu lets me get Figma performance with my little 6 person startup team without the massive engineering man-hours Figma has spent on performance?
Anyway, if it were high priority for us, we'd have done it already (switching to canvas/webgl). But right now it feels like buying a Quest when the Vision Pro is coming soon.
Re: From SVG to Canvas – A new way of building interactions
#26Earlier quoted context omitted.
That was long before they switched to canvas rendering, too: they were still just using contenteditable, though potentially with mild layout augmentation with things like absolute positioning and sizing of things (I don’t know). Flowing text around an image: the web has been able to do this for donkey’s years, it’s the float property. More recently, there’s the CSS shape-outside property that even lets you use non-re…
IIRC float is just left or right, you can't embed an image "in the middle" of text. I'm no web expert and the conversation was a decade ago, so I'm sure something got warped in translation.
Ah, in the middle. Yeah, you still can’t do that. There was https://www.w3.org/TR/css3-exclusions/ which let you do it, but it was only ever implemented in IE 10–Edge 18 (prefixed), and seems dead now.
Re: From SVG to Canvas – A new way of building interactions
#27ctrl+f "accessibility" in part 2: zero results ctrl+f "accessibility" in part 1: zero results Does anyone care about digital access to content for disabled people ? Or about the ADA ? Svg to canvas without any answer for accessibility is backwardness, plain and simple. You are letting down anyone who's deaf, blind or has trouble hearing or seeing, anyone who does not know how to read, has motor impairments, temporary…
A somewhat common approach is to maintain a parallel DOM structure for accessibility and keep it in sync with the data structures driving the canvas view.
Re: From SVG to Canvas – A new way of building interactions
#28ctrl+f "accessibility" in part 2: zero results ctrl+f "accessibility" in part 1: zero results Does anyone care about digital access to content for disabled people ? Or about the ADA ? Svg to canvas without any answer for accessibility is backwardness, plain and simple. You are letting down anyone who's deaf, blind or has trouble hearing or seeing, anyone who does not know how to read, has motor impairments, temporary…
Genuinely asking, how do you make something like their map view accessible with so many objects and layers? I'd imagine you end up with a solution that exposes various content rectangles and ignores everything else, kind of how Google Maps does it.
Re: From SVG to Canvas – A new way of building interactions
#29I've built diagram like tools several times, constantly umming and ahing between Canvas and SVG. SVG seems to get you pretty far, but I always end up with Canvas in the long run. Fun fact: Google docs is actually a canvas.
You start with SVG
Then you go to Canvas
Then you go to WebGL
Source: Early engineer at Lucidchart
Re: From SVG to Canvas – A new way of building interactions
#30It sounds like most of their problems were with using the browser SVG event handlers (or perhaps the framework).
They could have written their own event system for SVG (e.g. using event handlers on document), which would have fixed the gripes they blamed on SVG events. They wrote their own event system for canvas, so probably not much more difficulty in coding work?
Performance is the remaining issue that isn’t clear that SVG would meet. I assume SVG painting could be as fast as canvas painting. I am assuming if you attach no events to SVG elements, you remove the event performance issues (well, replace them with performance issues in your own custom event handlers, but no worse than canvas). Surely removing all the now unneeded SVG-grab-handle-elements (“DragBox”) that were only there to capture events would also improve performance (painting and event capture). Canvas is using imperative drawing primitives, and SVG can use composable primitives - both can be rendered by GPU. Canvas updates (eg. during dragging) require heavier imperative updates, while SVG primitives can theoretically be offloaded to the GPU. I can’t guess performance differences and performance delta probably strongly depends on browser, driver, and GPU.
Assuming you write your own event handling stack:
> the mouse only hits SVG elements inside their painted region
Fixed (as good as canvas)
> we could use things like pointer-events to disable certain interactions at certain times
Unnecessary (plus lowers stress on rendering?)
> Having every element produce a whole load of DOM elements for React to manage becomes a problem for performance when every element attaches event handlers, has to manage their lifecycles, observe state, etc., etc.
Fixed with document events
> Interactivity limitations. With our SVG renderer, each element managed its own interactions, which made it impossible to drag elements that were underneath other elements. This is a surprisingly common when making complex maps.
Fixed with document events
> Maintainability. However, with every element attaching its own interactions, there is a tendency for every interaction to know about every other, checking if it should be enabled or not.
Fixed with document events
> Another maintainability issue is the proliferation of event.stopPropagation() calls in the code. These are to stop events bubbling up through the complex DOM structure and allowing other components to handle events.
Fixed with document events (equivalent difficulty to canvas).
When writing complex code you learn that stopPropagation() is evil. Writing code to avoid it requires skills. IMHO stopPropagation should never be in any complex codebase (or perhaps with rules to prevent errors).
> We also have a few places where we have awkward setTimeout() calls
Oh my god, no! Terrible hack with terrible consequences, as they discovered. setTimeout() introduces very evil race-conditions, and testability issues. An alternative which isn’t much better is to use async to get microtasks, so at least you are not reordering events/tasks. IMHO in any modern codebase setTimeout should be banned or extremely restricted when it is absolutely needed.
SUMMARY
Basically, it sounds like the team needs some more experienced GUI developers.
I would bet good money they are trading one set of problems for another, and ending up with a codebase that is less maintainable.
I can only hope the article is not written by the lead developer - heaven help them if it were.
Opinions are my 10c as a custom framework developer (admittedly only one product that was not as complex as a GUI editor - that is why the inexpert mistakes sound so painful to me - although I could also avoid and detect problems because it was my own framework: depending on a third party framework makes it a heap harder to fix systematic faults).