Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Google Docs will now use canvas based rendering

workspaceupdates.googleblog.com

Post reply on HN
Print view View original

791–800 of 953 posts

Re: Google Docs will now use canvas based rendering

#791

Post by flowerlad »

nine_k wrote: post #241

The Web started as a document display and delivery framework. Now it has turned into an application delivery framework, which uses the old document-rendering abilities to display the UI, with many quirks and workarounds, because DOM was never intended as a performant dynamic medium. With canvas and WebGL taking more and more, it will turn back into an X terminal, with more advanced network capabilities. If most impor…

> With canvas and WebGL taking more and more, it will turn back into an X terminal, with more advanced network capabilities.

For some specialized apps this will be great, but for apps in general this is not a good idea at all. If it was, we'd be using Java applets today. HTML+CSS based apps are highly constrained. But that's a positive, not a negative, because it is the constraints that makes HTML based apps predictable, consistent and usable.

Re: Google Docs will now use canvas based rendering

#792

Post by Graffur »

snewman wrote: post #680

Speaking as one of the original three authors of Google Docs (Writely), but zero involvement in this project (I left Google in 2010): I'm seeing a lot of comments asking how JavaScript-on-Canvas could possibly outperform the highly optimized native code built into the browser engines. It's been a long time since I've really been involved in browser coding, but having written both Writely and, farther back, several na…

Out of curiosity, what have you moved on to now that you don't do browser coding?

Re: Google Docs will now use canvas based rendering

#793

Post by devongovett »

This is very bad for accessibility. Rendering things in canvas means there is no DOM, which means nothing for screen readers to read. To be fair, the old google docs editor was also very bad for a11y, but at least there was potential to improve it. This removes that option. They could have worked with the Chrome team to help improve standards for everyone, but decided to reimplement the rendering engine from scratch without regard for accessibility. I'm very disappointed that this wasn't flagged at a company the size of Google.

Re: Google Docs will now use canvas based rendering

#794

Post by ska »

larodi wrote: post #775
ska wrote: post #598

Earlier quoted context omitted.

> It was indeed a very strong marketing move for... decades to convince people, like smart people, that document editing can be a web-based thing. I think this is overly reductive. There was a technical problem driving some of this; namely - document collaboration sucked (to some degree still does). Moving documents online was a tradeoff - making the editor web based solves a bunch of problems but causes some other o…

The way that word processors are designed, essentially as very smart linked-lists of objects, would've actually allowed for the document collaboration very early on. We can perhaps speculate dozens of reasons why dis did not happen, but I guess it was for strategic reasons. But it will and is happening. Is about right making the point that IMHO the desktop office processor is far from dead, actually I would imagine a…

> Question is did people really needed the collaboration feature so much, or as much as it was praised for decades... When it shows that source code (which IS one very important content) is being developed not collaboratively in real-time in the browser, but with the aid of various version control systems (CVS, SVN, GIT etc.)

This is a good point. I don't think realtime collaboration is so important, but multiple author collaboration is. And "track changes" is a sort-of good-enough solution, but painful.

I've had good luck collaborating on documents (research papers) using latex and source control, but that assumes (a) participants are comfortable with both and (b) the storage format is amenable to revision control. Most word processing doesn't work well like this because you can get the document into a broken state in ways that are hard to recover from, and many of the users have no mental workflow map for "source control"

TeX/LateX or orgmode/Markdown type approaches have an advantage here for complicated collaboration.

These days a lot of collaborative stuff is being done outside of spreadsheets and word processing docs, the lines are blurrier and the collaboration is broader. In the "old days" a wiki might have done the trick for this but people want richer environments too. Not sure what he answer really is.

Re: Google Docs will now use canvas based rendering

#795

Post by progval »

azinman2 wrote: post #786
progval wrote: post #774

Earlier quoted context omitted.

I don't know about iOS, but on Firefox Desktop, the right-click menu is emulated by the canvas, and it uses the clipboard API to copy it. > If the text wasn't available, it would also completely break any kind of screen reader / accessibility feature so something has to be supporting this at a native-browser level. When using a screen reader, it tells you you press Ctrl+Alt+Z, which loads an iframe containing (only?!…

It looks like on Safari on macOS they also hijack right-click menu, but text selection works such that I can go to Edit>Copy and it works. What tells you to press Ctrl+Alt+Z? That's not a great experience for you to interactively edit a document if you have accessibility needs.

> What tells you to press Ctrl+Alt+Z?

Invisible text inserted in the DOM with Javascript (forgive the French, it ignores browser settings and seems to use geolocation):

    Pour activer la compatibilité avec le lecteur d'écran, appuyez sur Ctrl+Alt+Z Pour connaître les raccourcis clavier, appuyez sur Ctrl+barre oblique

Re: Google Docs will now use canvas based rendering

#796

Post by chromanoid »

pwdisswordfish8 wrote: post #370
Ajedi32 wrote: post #213

I think this is actually one of the few cases where canvas-based rendering makes sense as a replacement for the DOM. Docs is a full-featured application which already has to re-implement a lot of DOM-like features in order to fulfill its primary function (things like text formatting and layout, spell checking, etc). Doing it all in canvas doesn't sound significantly more difficult than what they're already doing. The…

This is a great example of a comment written by a developer or some otherwise technical person who is so used to thinking and speaking in terms of trees that they can't see the forest, let alone the village it's situated next to and the people inhabiting it. Google Docs may be an app, but a big part of the app, and confirmed to be one of the reasons for the migration here, is the part that renders the document to the…

It's about producing PDF vs producing HTML.

Google Docs produces printable documents not hypertext. Print was never a priority of HTML. And I guess it shouldn't be either. Just look at the complexities of DocBook, LaTeX or Open Office XML.

Re: Google Docs will now use canvas based rendering

#797

Post by lhnz »

beaconstudios wrote: post #590
ctoth wrote: post #512

Earlier quoted context omitted.

Let's start with accessibility, because this is a field I am forced to be an expert in. Native "binary blobs" have access to the operating system accessibility APIs, and consequently any native app is a lot more likely to be accessible out of the box than something rendered to a canvas. People have spent literally decades building out APIs for the native platforms [0] [1] [2]. To think that a native app is equivalent…

it's viable to make accessible apps in DOM though - it's just canvas apps that can't be made accessible, and I agree with the GP that Google should not be trying to circumvent the DOM for the Docs interface.

Canvas apps can be made accessible.

The example that Google shows in their post has accessibility features [0], although currently these need to be switched on with a keyboard shortcut (⌘+Option+Z).

Pay attention to `document.getElementById('docs-aria-speakable')`.

[0] https://docs.google.com/document/d/1N1XaAI4ZlCUHNWJBXJUBFjxS...

Re: Google Docs will now use canvas based rendering

#798

Post by sanxiyn »

aloer wrote: post #683
snewman wrote: post #680

Speaking as one of the original three authors of Google Docs (Writely), but zero involvement in this project (I left Google in 2010): I'm seeing a lot of comments asking how JavaScript-on-Canvas could possibly outperform the highly optimized native code built into the browser engines. It's been a long time since I've really been involved in browser coding, but having written both Writely and, farther back, several na…

How would you recommend someone to get started learning about the architecture of Text editors / word processors? I think Monaco from vscode is probably an interesting read but I’ve never looked at such a big open source code base before. Is there something you can recommend to understand better how it works architecturally?

There is no substitute to building one yourself, but The Craft of Text Editing book has a lot of accumulated wisdom. It is Emacs-centric, but basics are same.

http://www.finseth.com/craft/

Re: Google Docs will now use canvas based rendering

#799

Post by cxr »

jd3 wrote: post #706
lol768 wrote: post #701

Earlier quoted context omitted.

Yeah it's a real shame it's all moving to HTML/JS for the chrome & e.g. devtools, even if it's more "maintainable".

I use the modern Firefox HTML5/JS dev tools on a daily basis and love the featureset that they provide, though it is equally shocking to compare the feel to that of the old DOM Inspector[0] (and Venkman[1], the old JS debugger), which was a XUL add-on for DOM inspection that used to run in Firefox, Thunderbird, and SeaMonkey. What feels snappy and instantaneous in DOM Inspector feels somewhat muddy and laggy in the m…

Thanks for the shoutout to the legacy DOM Inspector (which I used to maintain) and Venkman (which I have both admired and used in anger). When Mozilla decided to put together a devtools team for Firefox 4, I was disappointed when I realized that they weren't going to take any effort to make sure the fruits of their labor sidestepped any of the performance issues that Firebug had exhibited for most of its lifetime. I do want to quibble, though, about the suggestion that this is a matter of XUL+JS versus HTML+JS. I say this even as someone with strong feelings about what a joy XUL was in comparison, and a long-lasting bitterness over the decision (among many) that Mozilla made in mishandling its own future.

WebKit's Web Inspector has for a long time gone with HTML, and in all its incarnations I've ever tried out, it has always been snappier than either Firebug and or the devtools that ships with Firefox.

When making comparisons like this, it's important to keep in mind that you're comparing/contrasting teams and their output, and it's not just a matter of the building blocks they're using. Some teams do better work than others.

Re: Google Docs will now use canvas based rendering

#800

Post by lhnz »

devongovett wrote: post #793

This is very bad for accessibility. Rendering things in canvas means there is no DOM, which means nothing for screen readers to read. To be fair, the old google docs editor was also very bad for a11y, but at least there was potential to improve it. This removes that option. They could have worked with the Chrome team to help improve standards for everyone, but decided to reimplement the rendering engine from scratch…

The example that Google shows in their post has accessibility features [0], although currently these need to be switched on with a keyboard shortcut (⌘+Option+Z).

Pay attention to `document.getElementById('docs-aria-speakable')`.

[0] https://docs.google.com/document/d/1N1XaAI4ZlCUHNWJBXJUBFjxS...

Post reply on HN