
Flexible data tables with CSS Grid - adamlynch
https://adamlynch.com/flexible-data-tables-with-css-grid/?1
======
leokennis
Now we’ve gone full circle from using tables for layout, to using layout for
tables.

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

~~~
ceeessess
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](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.

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

------
parhamn
Great writeup. I found the defensive FAQ at the end funny -- really speaks to
the prematurely critical culture of software dev in these forums.

On related note, does anyone else prefer panning desktop-sized pages on mobile
devices? Given that they're usually touch devices it feels natural to pan
around the regular desktop-sized page and pinch in to zoom on parts you're
interested in. Like in this case I'd probably prefer panning to the single row
collapsing and taking most of the screen space on mobile. Generally
mobile/tablet screens feel like they're really good at exploring a larger-
than-device canvases so its not obvious to me why so much effort goes into
mobile-only views.

~~~
rezz
Completely agree. There’s also the issue of users who browse the web at more
than 1x zoom. Zooming triggers breakpoint changes and we’ve received a ton of
user feedback claiming they prefer to scroll horizontally in general (not just
tabular data), as opposed to getting a mobile “optimized” view.

------
Theodores
That is a nice tool you have built there. It is important to remember that
people who will be looking at this screen every day are expert users, they
will have dual screen desktops with a mouse, not be fumbling on a phone having
not seen the interface before. You did well to make it so they can perfect the
information they have on their screen and these efforts will be appreciated in
day to day usage.

Also it is cool that you have stuck with the semantically correct element in a
table.

What you can also do with CSS Grid is a table that does not have the extra
markup for empty cells, i.e. a sparse table. With some autoflow for the
columns and an element name or class setting a column number, you can make a
table from other data such as a definition list with the 'display: contents'
trick giving grid access to the content in a data definition elements. So you
can fully model a contact card for someone using the same markup for pretty
contact cards or in the 'table view'. You can also do all of the column
reordering without changing the document, the rows or cards can always be
written in the same logical order, regardless of whether the columns are
rearranged or hidden.

There is actually a rendering slowdown with CSS Grid although I have only
found this after nesting a few grids and having some transparency on each,
going to an older layout technique fixed that. It would be interesting to know
if there is a slowdown here, if hundreds of off screen rows are in the
document.

------
onesmallcoin
I find it hard to differentiate between rows when it is in portrait mode one
under another. When I've had to do projects with modular tables ect; I've used
an awesomelibary called datatables. They have heaps of plugins that let you do
things like load from json, filtering and sorting, pagination, export etc.
I've found it a very feature complete product off the shelf.

~~~
mythrwy
Datatables actually has a plugin to also vertically space some content with a
reveal button on smaller screens.

[https://datatables.net/extensions/responsive/examples/initia...](https://datatables.net/extensions/responsive/examples/initialisation/className.html)

Modern frameworks make a bunch of datatables needless at this point, but I
still often use it (with Vue) just because it's so complete with so many
plugins.

------
d--b
Designers always a slightly different vision of what data-heavy means...

[https://images.app.goo.gl/goKeqhU8oHCTxiHK7](https://images.app.goo.gl/goKeqhU8oHCTxiHK7)

------
robin_reala
I wouldn’t do this, or at least I’d do a bunch of accessibility testing before
implementing this (something which wasn’t mentioned in the article).

Assistive tech allows column and row access to tables that have the default
display:table styling. Setting them to display:block (a common approach for
mobile historically) typically removes the ability for people to navigate in
this way. I would imagine that changing to display:grid does the same.

More info at [https://vimeo.com/139062429](https://vimeo.com/139062429) as an
example.

~~~
Macha
Would setting the appropriate aria roles help here?

~~~
gedy
Yes I believe so, there are ARIA roles for tabular data:

[https://developer.mozilla.org/en-
US/docs/Web/Accessibility/A...](https://developer.mozilla.org/en-
US/docs/Web/Accessibility/ARIA/Roles/Rowgroup_Role)

~~~
robin_reala
That relies on assistive tech supporting them. I’m not saying they don’t, but
historically it’s been lacking. Great if they do, but testing would absolutely
be needed.

------
SimeVidas
Version with minimal CSS:
[https://codepen.io/simevidas/pen/OYgdjm?editors=1100](https://codepen.io/simevidas/pen/OYgdjm?editors=1100)

~~~
popotamonga
now that with the first column also fixed. i failed

------
gatherhunterer
I don’t see what benefit the table elements are providing. It’s just
convoluting the grid with hidden CSS rules. Why not just use a div for the row
and spans for columns? The inline and block behavior of those elements is what
defines and distinguishes them. Paired with CSS reset there are no hidden CSS
rules affecting their behavior.

~~~
aeontech
Accessibility.

~~~
gatherhunterer
As another user pointed out, there are ARIA roles for this. At this point we
are way past being forced to use clumsy elements just for accessibility
reasons and the roles are preferred by screen readers.

[https://developer.mozilla.org/en-
US/docs/Web/Accessibility/A...](https://developer.mozilla.org/en-
US/docs/Web/Accessibility/ARIA/Roles/Rowgroup_Role)

~~~
runarberg
In my experience developers are really bad at implementing accessible
components from scratch. There are a lot of nuanced edge cases that is easy
for a mere human to miss. Like:

* Tabbing order, trapping the tab order (but still allow tabbing to the URL bar)

* Keyboard navigation, and keyboard controls, esc and arrow key behavior etc.

* Submit behavior and change events

And many more. Setting the correct `role` only adds the semantics for
assistive technologies and is by no means sufficient to make things
accessible.

When you just use `<table>`, `<details>`, `<button>`, <select>, `<dialog>`,
etc. you get all accessibility correctly implemented for free.

Sure you can find a library that implements the component. But these are too
implemented by mere humans and are likely to miss some of the nuanced edge
cases. Also by that point you might as well just use the standard elements.

------
sfc32
It sounds good, but the examples are not responsive on mobile ... they don't
stack as mentioned in the post but instead shrink. Eg:
[https://s.codepen.io/adam-lynch/debug/XwKWdG](https://s.codepen.io/adam-
lynch/debug/XwKWdG)

The draggable columns are a nice feature though.

~~~
chrismorgan
I’d say it’s all working as described and intended: the examples are all
simplified examples demonstrating particular aspects of the solution, and none
of those examples are of the stacking business.

------
narraturgy
Not the point of the post, but Adam's site is beautiful to me. Simple,
accessible, and yet still handsome. Whenever I try to make a website it ends
up looking like a mid-90s burnout. Is there anywhere besides a graphic design
school to go about learning some principles of what makes things look good?

------
amenod
I have tried using CSS grid a few times, but my impression of it was... meh.
The oppurtunities to use it are few in between, it doesn't bring much more to
the table than (nested) flex, and worst of all, I had huge problems
understanding what I did a few months later, even though I have tried to do it
properly (and after deciphering it, there was nothing that I would change).

Did anyone have opposite experience?

EDIT: OP's experience is of course different, for such customizable tables CSS
Grid probably makes sense. My opinion applies more to generic layout.

~~~
chrismorgan
My experience is that almost all of the early “CSS Grid lets you do _this_!”
examples were either: ⓐ actually achievable with Flexbox in a non-contrived
way; or ⓑ outright weird things that will seldom actually be desired, being
more related to art direction than layout or similar.

Since then, I have come across a _few_ cases where Grid was used to advantage
in a way that Flexbox couldn’t have matched—I’ve even written a couple myself.
The main case I’ve found is responsive layout, where you want to do something
like interleaving rather than just stacking of elements, as you scale down a
two-dimensional layout. This is the use for one I’ve written: see the
responsive design of the hero area on
[https://www.topicbox.com/](https://www.topicbox.com/) and how the video moves
from the right into the middle of the content from the left column, which
would be exceedingly painful to handle well without Grid, probably requiring
absolute positioning and/or float.

But mostly, I find Flexbox to be sufficient, with Grid very occasionally
offering a _nicer_ way of doing something that was already possible.

It’s not uncommon for me to do things with Grid now, for work or in my own
projects, but I confess that I normally have to lean heavily on docs on the
grid-* properties when I’m getting started, which I don’t for Flexbox. I know
its capabilities and thus when it might be applicable, but the actual syntax
is too powerful and flexible, with too many ways of achieving similar and
different results, and so it will take more use to internalise than most
features, but Grid’s just not useful enough that I think most are likely to
reach that threshold.

~~~
SahAssar
> This is the use for one I’ve written: see the responsive design of the hero
> area on [https://www.topicbox.com/](https://www.topicbox.com/) and how the
> video moves from the right into the middle of the content from the left
> column, which would be exceedingly painful to handle well without Grid,
> probably requiring absolute positioning and/or float.

Wouldn't just flex ordering and wrapping do? like this:
[https://codepen.io/anon/pen/QRgoOR](https://codepen.io/anon/pen/QRgoOR)

~~~
chrismorgan
It depends on how thoroughly the widths and heights are known. In various
constrained cases, what you suggest can work, but it’s always fragile and
depends on certain layout constraints being met. I do like your use of the
column direction and vertical wrapping; for some reason, I had always had in
mind rows, which prevents you from doing things like vertical centring of the
columns relative to one another. So I never did try that combination. I think
it would narrowly meet our requirements now (which includes other landing
pages with somewhat different hero content), but I don’t think it would have
the first iteration of the design when I started using Grid, due to greater
flexibility and variation of the heights of elements.

At the least, the Grid solution is more robust. But I will downgrade my
“exceedingly painful” judgement to “somewhat icky and fairly fragile”.

Thanks for also supporting my point that most cases where Grid is used can be
done with Flexbox!

------
tlrobinson
One issue with using use pure CSS for data table layout is if you have to add
windowing/virtualized scrolling for very large tables it tends to break down
(you need to know the row/column size so you can’t use breakpoints etc).

------
2819b
For the most part I've found flexbox to solve 90% of the pain of working with
CSS.

------
dvh
I switched from css grid to absolute positioned layout 2 days before release
and it'll take at least 2 years before I give grid another try. Support on
Android is spotty.

~~~
rimliu
You chose the second worst option. (The first being tables for layout).

~~~
postalrat
People used tables for layout because it worked.

------
appleflaxen
is there source code for this?

it's a really cool project, but in the end if there's no source code, then the
post is just so much of an advert for teamworkCRM.

~~~
chrismorgan
There’s enough technical detail about how it works that it’s useful—if you
will, it’s like a patent drawing that says “this is how you can make such a
thing”, and you can copy it. It’s a moderately novel implementation technique,
well explained.

Besides which, there _is_ (simplified) code provided.

------
kstenerud
CSS has always been confusing to me. Every year there are a new set of "best
practices" that seem to only serve to work around how CSS works (hacks,
basically). Now we have CSS grid, which looks like tables, which were supposed
to be bad (although I never understood why).

If CSS can't do the layouts we need without a bunch of hacks and bashing your
head against the table, why is it still a thing?

~~~
goto11
HTML tables were not bad. They are fine when used for their appropriate
purpose.

Anyway the pure CSS equivalent to tables is display:table, it is not CSS grid.
CSS grid behaves quite different from tables. For example CSS grid can adjust
the number of columns to the available space. This makes sense for say textual
columns but would not make sense for a data table.

