Google Docs Switches to Canvas Rendering, Sidelining the DOM – InApps 2022

Earlier this month, Google announced it was updating the way Google Docs renders documents — from the traditional HTML DOM-based approach (Document Object Model) to using a web standard called Canvas. The <canvas> element is typically used to draw graphics on a webpage, via JavaScript. So in a sense, what Google Docs will be doing from now on is painting a document onto a webpage. While this approach has technical benefits (which I’ll outline below), there are potential issues with rendering in Canvas — particularly in regards to accessibility.

Google says the change to Canvas rendering will “improve performance and improve consistency in how content appears across different platforms.” It has immediate implications for developers of Chrome extensions, however, Google has given guidance on how extensions can be ported to the new framework.

The bigger question, though, is what — if any — impact this change will have on how other web applications are built? Since Google is such a force in modern web development (Chrome being the dominant browser on the web), some are wondering if this shift to Canvas sets a bad precedent.

Let’s step back and examine this change. Up till now, Google Docs had evolved over the past fifteen years in the familiar pattern of most web applications: its interactivity largely achieved by heavy use of JavaScript code to manipulate the DOM. However, an online word processor requires a lot of precise rendering of objects on a page, which is difficult to do via the DOM. The appeal of Canvas is that it enables the developers of Google Docs to bypass all of that persnickety DOM wrangling and just “paint” the document onto the page.

What makes this intriguing is that the Google Docs shift to canvas rendering may be an early sign of a bigger change in how web applications are built. As Matthew MacDonald put it in an excellent article on the Young Coder blog:

“It now feels like the familiar pattern — downloading plaintext JavaScript code and executing it against an inspectable HTML document — might just be a brief stop in the ever-evolving road of web development.”

MacDonald pointed out that Google Maps has been doing canvas rendering for years and that it’s the default approach in Google’s cross-platform Flutter toolkit. It’s also how Google Sheets renders content. So this isn’t a brand new development, rather it is an approach that Google has iterated on over time.

Accessibility

But what about the accessibility concerns? Drawing on a canvas means you don’t have the semantic underlay that working with the DOM provides. With the DOM’s tree structure, each node is an object representing a part of the document. With Canvas, it’s more like a big blob of code than a tree.

The canvas rendering change was discussed at last week’s Google I/O, the company’s annual developer conference, in an “ask me anything” (AMA) session with Google’s Dion Almaer (Director, Web Developer Ecosystem) and Paul Kinlan (Global Lead, Chrome Developer Relations). The pair were asked by moderator Jake Archibald, somewhat tongue in cheek, “is the DOM dead?”

Almaer began by discussing an online code editor that he and his colleague Ben Galbraith launched in 2009 when they worked at Mozilla, called Bespin — which was also Canvas based. They chose to use Canvas because of the performance benefits it offered. Given the accessibility limitations, they created a “side DOM to handle accessibility.” He confirmed that this is the approach Google Docs has taken too.

“If you actually played with the [Canvas] version of Google Docs, you’ll notice that it actually works very similar to the current DOM version. That’s because they also use a side DOM tactic and put a ton of work [into] that.”

I clarified with Almaer after the AMA that he’s referring to a hidden DOM, something the end user cannot see, that caters just to accessibility. He also mentioned that Google and others are working on a W3C spec called the Accessibility Object Model (AOM), which will give developers high-level primitives to make web pages accessible.

“So you can come in and programmatically speak to the screen readers and other accessible devices,” Almaer said about AOM, “so you can take more control, especially if you’re doing these rich things [such as Google Docs].”

The side DOM approach and AOM are both being used in the new Google Docs. “They’re both coming from the same place,” Almaer said, “but the DOM structure itself is used specifically just for the visual representation. We’re doing something completely different for screen reader support. Basically just using ARIA Live regions for reasons that they were not invented, which is as a text-to-speech engine.”

What to Choose: DOM or Canvas?

Currently, the Canvas approach to rendering is probably only an attractive solution if your application requires a performance boost at scale.

In the AMA, Archibald said that not all web applications need Canvas. “When you’re writing a native app,” he said, “you don’t go straight to Assembly [language] — you only go there when you really, really need that power.” Similarly, it’s worth noting that very few companies have (or need) the scale that Google has. The performance boost that Google was looking for with Canvas might be a relatively small one for the end user, but at Google’s scale, it has a material impact.

The DOM-based approach to rendering will likely remain dominant in web development for some time (and perhaps for a very long time to come), but it’s not without issues. Perhaps with this in mind, Kinlan opined that choosing Canvas “puts pressure on the browser engineers to actually improve the DOM.” He referenced a Hacker News thread, in which one of the creators of Google Docs outlined the various DOM-related obstacles it had to overcome over the years.

Steve Newman was a co-founder of Upstartle, the startup that released an online word processor called Writely in 2005. Upstartle was acquired by Google in 2006 and Writely became one of the foundation pieces for Google Docs. In Hacker News, Newman wrote that online word processors “have extremely specific requirements for layout, rendering, and incremental updates,” which the DOM isn’t always suited to meet. One example he cited:

“[…] to highlight a text selection in mixed left-to-right / right-to-left text, it’s necessary to obtain extremely specific information regarding text layout; information that the DOM may not be set up to provide.”

Newman added that the first version of Writely in 2005 was “an unholy mess perched shakily atop contenteditable” (referring to a global attribute of HTML that allows a user to edit that content). So it required many workarounds at the time.

Conclusion

When Gmail adopted Ajax technology back in 2004, it was one of the first cross-browser web applications to send and retrieve data from a server in the background (rather than re-draw the page each time new data was received). That approach subsequently became the norm for web applications. This pattern, of Google popularizing a radical new web development approach, could replay itself with canvas rendering over the 2020s.

So it’s possible that Google Docs will be viewed in ten years as the canary in the coal mine for the DOM approach to page rendering. However, the fact that a “side DOM” is still needed for accessibility in the Canvas approach means there’s still work to do to make canvas rendering easy to implement.

Lead image via Pixabay.