Hacker News new | ask | show | jobs
by maxov 1860 days ago
The synchronicity of this showing up on the HN front page at the same time as Google moving Docs to canvas-based rendering (https://news.ycombinator.com/item?id=27129858) is kind of funny.

More seriously, this looks really cool, and I do actually wonder if it could ease some of the problems Google is looking to solve by using canvas-based rendering, although I'm not super familiar with the challenges of rich-text editing. It would be much more preferable for me (and I think for most developers and users) if web apps still used the DOM to render text boxes, and you could hook into the rendering and layout engine for more complex operations. The layout and painting hooks offered by Houdini seem very useful for this.

The one issue is I'm not sure how text selection works here - the order of elements in selection is already kind of obtuse for more complicated layouts, and this adds even more configurations. I don't know if the APIs offer some sort of ability to control the order of selection or if that's somehow a feature of the box model.

2 comments

In Google Docs they value consistency of the rendering output over performance, while complex documents might even see some performance benefits.

CSS Houdini is a way to get performance out of complex and custom layout or animations.

I might be misinterpreting, but are you saying the two are mutually exclusive? Google Docs does need custom layout and rendering which may be tough/finicky to implement with the existing css layout, as well as consistency.
Why do you assume canvas will have bad performance? Sheets moved to canvas from HTML, and got a massive perf boost.
It's not totally mutually exclusive. But canvas operations aren't hardware accelerated, and rendering of HTML potentially is.

It's still possible to make the DOM complicated enough that moving to canvas has performance advantages. I don't know the details, but I'm guessing that is achieved by skipping updates the browser would usually make.

Webgl is tho. But even in 2d context api, you have bigger control over how your content is being printed than in html. Which means that a lot of operations that DOM performs unnecessarily in the context of Google docs can be simply discarded.
Yes, which is why in general, DOM rendering is faster, while in special cases, with a lot of manual optimization, canvas rendering is more performant.
My guess is that this comes down to browser support. A canvas based solution probably has pretty wide support today while these new CSS features will be subject to the long tail of browser versions.