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.
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.