This made me laugh. To be fair, the article talks about restyling <table> and related elements using grid instead of table display, rather than building tables using a bunch of <div> elements, which was a real thing I saw people advocate for during the whole anti-layout-table backlash.

It can be better to use divs instead of tables in some situations, especially when you want to display thousands of rows inside of a relatively complex DOM structure. All browsers seem to render them faster, but in Chrome specifically there are bugs like this: https://bugs.chromium.org/p/chromium/issues/detail?id=461877 and one that can trigger a huge cascade of recursive style recalculations (which in practice freezes browsers for a few seconds). Virtual scrolling is another way of avoiding this problem but it can be tricky if you don't know the height of the rows.

Last year I had to build a UI with several thousand rows in a data grid. Of course I used a table for this, since tables are for displaying tabular data! Once I got a full set of production data into it, scrolling the page absolutely crushed the browser, running at about three frames per second. I believe the issue was actually caused by a parent element with overflow: scroll-y, but switching to divs made it run smooth as butter.

This table rendering bug still haunts me

https://stackoverflow.com/questions/8474678/ie9-strange-tabl...

I am unable to properly select the text in the “tables” in the OP in Safari on iOS. Don’t know if this is due to a problem with Safari or with the way OP did their stuff but either way it is really annoying.

Selecting works in Firefox. It even behaves as you would expect if you copy-paste to e.g. Libreoffice, because the markup is still a table.

The only thing that doesn’t work is selecting cell ranges in the browser. At least in Firefox, for regular tables, you can do that by holding ctrl or shift while selecting. I guess you could restore this behavior with some Javascript.

Also no idea how this impacts any a11y related things.

They use `display: content` which many assistive technologies will incorrectly remove from the accessibility tree (or at least they used to). So it is not currently recommended to use this this value if you want the content to be accessible.

https://hiddedevries.nl/en/blog/2018-04-21-more-accessible-m...

I'm thinking if you strip away the js and css, it's just a plain ol' table in the html .. wouldn't have thought it'd be an issue, accessibility-wise.

Actually when you have a `display` of something else then `table` you will strip away the table semantics from the accessibility tree (unless you add `role="table"` etc on the table elements).

https://developer.paciellogroup.com/blog/2018/03/short-note-...

I would hope so, but you never know.