[microcolonel]

> My (probably naive) view is that browsers are pretty good at table-ish layouts so it’d be great to know why canvas was chosen.

The browser certainly makes this convenient... until you have more than a few thousand cells. At some point even just having the whole table loaded into the DOM is too layout and memory intensive (except on servo, sometimes).

When you try, then, to work around those limitations, continuing to use the DOM for it becomes impractical. This gets especially difficult with a spreadsheet, where row and column size is user defined, and thus a scroll offset is a sum of all of those sizes.

I've done this several times, so I eventually settled on a bucketed, run-length encoded cache of row and column sizes, but keeping this data structure current was a mess. The mess further escalated since eventually I worked on an application where the row and column sizes could change in a different chunk with a network update, and that would need to be reconciled somehow.

[tobyhinloopen]

You don’t have to render 1000s of table cells. You only render the visible cells and replace the content when scrolling.

[Technetium_Hat]

Tables are also extremely performant in internet explorer, where table rendering is gpu accelerated.

[microcolonel]

Yes, if you can determine the natural height of every preceding row, the position of the next cell is a vector reduction of the previous heights. You still run in to memory limitations though (unless they've produced some incredible magical compaction scheme which can extract hidden classes from DOM structures, which I can't imagine happened without my knowing it since last I looked at tables in IE [spring 2017]).

[myliang]

good