This is often said, and almost as often misunderstood as referring to what I call the “pure canvas” approach where you throw away almost everything the browser gives you and start from scratch. Some key points about Google Docs, just to clarify (I’m not disagreeing):
① Only its document area is rendered with canvas; its chrome is all still regular HTML.
② It still uses the browser for text shaping and painting, just not for macro-layout (breaking paragraph into lines, &c.). (I expect that’s what this article’s subject would be doing too, but it’s part of common misunderstandings.)
③ Even things like scrolling are completely left to the browser: it’s not a single <canvas>, but a regular DOM scrolling area contains a bunch of <canvas> tiles.
④ The shunning of using HTML-with-contenteditable for the entire thing makes editing perform very badly (throughput, latency and jitter), and things like keyboard caret navigation behave non-natively in ways that will be very frustrating for people that actually use and care about this stuff (you get to relying on things behaving the same, like with touch typing, so things that get it wrong like Google Docs and LibreOffice (which gets it all wildly wrong) constantly grate).
⑤ They could just as easily use HTML or SVG rendering as <canvas> (while keeping their input and layout the same, so I mean still with all manual line breaks and that kind of thing). You’d get quite similar performance (though probably overall a little worse), and the same problems (since it’s the input layer that makes it slow and jittery—it just fundamentally can’t be as good in those ways as boring old contenteditable, given the current primitives). In fact, it’d mildly surprise me if they didn’t have an SVG or HTML renderer handy, or did in the past and could revive it to complete indistinguishable functionality within a day or two (even if hacky).
This is one of the best comments I've read on the much ballyhood Google Docs canvas! Favorited. I expect I'll be referencing this a good bit over the years.
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 possible before.
IMO, do the right thing for user agency & stick with higher level web stuff if you can, unless design truly compels it. Reinventing has many subtle pitfalls.
> 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 combinations. Thats not something that web browsers guarantee.
In this case, I understand google's choice to build a custom renderer. I'm sure it was a massive effort for the team, but probably not quite as massive as working around all the browser quirks they were dealing with before. (From memory, before the canvas renderer, google docs ran their own rendering code then used CSS to absolutely position every single word in the document.)
> 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.)
Ok, sure - you got me. If you mess with obscure browser options, you will successfully change how google docs renders content. But I suspect all of the people who select that option would fit in one meeting room, with a sign out front from google which says "WONTFIX".
One thing people do do all the time in word processors is mash enter until the next bit of content ends up at the top of the following page. If a user does that, then they print their document from a different computer, it should print correctly. The next content should appear exactly at the top of the next page. If the word processor does anything else, users will be frustrated and blame the software. Word and Docs both put in a ton of engineering effort to get this right.
(Educated users will insert a page break instead, but plenty of users don't know about page breaks. They still expect their documents to render correctly.)
I select that merely as the easiest way of demonstrating that it’s leaving important parts of its layout to the browser—parts that are not always consistent. There will be places where browsers in their default configurations differ, especially over time, to do with things like varying Unicode support or exotic OpenType shaping features, or even simple hinting. They won’t often be as big and flashy, but they’ll cause differences that may matter and added or removed lines from time to time.
> There will be places where browsers in their default configurations differ, especially over time, to do with things like varying Unicode support or exotic OpenType shaping features, or even simple hinting.
And my point is simply that google docs is explicitly designed to prevent any of these sort of issues from being noticable to the user. Sure, maybe individual characters or words will render slightly differently due to type hints. But as I understand it, google tries to make sure it never results in an added or removed line anywhere. The only way they can make sure of that is by shipping their own text layout engine. And hence the use of canvas to render text.
> And my point is simply that google docs is explicitly designed to prevent any of these sort of issues from being noticable to the user.
I’ve demonstrated one place where it very obviously failed at this goal, and I know enough about variation in shaping to confidently state that others do exist, though the most obvious are almost entirely historical. But there are variations that can change glyph advance, which will affect layout.
They use the browser’s shaping, so they’re subject to its quirks. In order to obtain absolutely consistent layout, they’d need to do the shaping themselves, but they have chosen not to do that (and I think they’re right not to).
Google Docs has clearly been pushing for non-pagination in more recent times, and paragraph layout largely doesn’t matter once you’re not fussing about pagination.
They reimplemented breaking paragraphs into lines, but gained literally nothing thereby in terms of actual functionality or behaviour, since the browser offers absolutely everything they wanted from it, and they still rely on the browser for the shaping.
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-rectangular crop: https://developer.mozilla.org/docs/Web/CSS/shape-outside.
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.
> 2. Google docs wants the same document to render exactly the same on all OS / browser combinations.
I think the industry needs to let go of this need for control. The browser is a user agent, not an author agent, and the same should be true of a document viewer. (Ideally, the browser itself should _be_ the document viewer.) For accessibility, if nothing else. And as for users brute-forcing a page break, let them be forced to finally let go of the print medium. We've been shackled by the print-first approach for long enough. Yes, I'm talking about accessibility again.
"Pixel perfect design" is a phrase I keep seeing from Flutter camp, from Towards A Modern Web Stack. I'm so with you though: that's an anti feature!
Developers/companies shouldn't have totalitarian control over the experience, I there should be malleability in software. Software is almost always best when it's not super hardened into form. This grasping for absolute control is poor form, in most cases.
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.
Similar journey here (yWorks, with a diagramming library, too). In our case the journey comes with drawbacks, though. Yes, WebGL allows for larger graphs, but it also does not support the flexibility (to customers) the other options offer.
Same. Working around the issues with SVG sometimes takes as long as rewriting parts of SVG from scratch.
It’s not an SVG problem so much as Canvas and SVG are not reconciled into one bigger rendering system, so when you hit an edge case that requires breaking outside out of SVG, you have no path.
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.
A long time ago a small startup used unusual tooling in the industry. The startup was small, but the tooling had some great qualities, which allowed the startup to compete with bigger teams feature for feature, spending less efforts to produce the same functionality as their industry peers. Eventually the startup had a successful exit, the founders become rich, and one of them even started sharing his experience in a rather systematic manner. Happy end.
Is it so that SVG requires to use all the features of it, or is it possible that you can mix and match, choosing what's important now and what's not, while benefiting from already existing SVG features? Is it possible that SVG followers don't do something which SVG does for them? Aren't there features, sufficiently aligned with SVG, which outperform directly working with other layers?
Figma is excellent at many things, but they struggle with accessibility. It's been a year since they wrote a blog post about their accessibility efforts so I don't know how far they've managed to solve the issues they identified - https://www.figma.com/blog/a-step-forward-in-our-accessibili...
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.
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.