Flexible data tables with CSS Grid
adamlynch.com
adamlynch.com
https://stackoverflow.com/questions/8474678/ie9-strange-tabl...
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.
https://hiddedevries.nl/en/blog/2018-04-21-more-accessible-m...
https://developer.paciellogroup.com/blog/2018/03/short-note-...
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.
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.
https://datatables.net/extensions/responsive/examples/initia...
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.
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 as an example.
https://developer.mozilla.org/en-US/docs/Web/Accessibility/A...
https://developer.mozilla.org/en-US/docs/Web/Accessibility/A...
* 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.
The draggable columns are a nice feature though.
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.
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/ 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.
Wouldn't just flex ordering and wrapping do? like this: https://codepen.io/anon/pen/QRgoOR
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!
The thing is once you "get" Grid you will never go back to any other layout. Here is one example (an extremely common layout: sidebar to the left stretching from top of the container to the bottom, header on top right, main in middle right and footer at the bottom right):
<style>
section {
display: 'grid';
grid-template-areas:
"sidebar header header"
"sidebar main main"
"sidebar footer footer";
}
aside {
grid-area: sidebar;
}
header {
grid-area: header;
}
main {
grid-area: main;
}
footer {
grid-area: footer;
}
<section>
<aside>Sidebar</aside>
<header>Header</header>
<main>Main content</main>
<footer>Footer</footer>
Notice how I did not have to define a bunch of "col-" or "row-" or explicitly specify percentages and flex properties to each child markup element to layout my grid? If I need a completely different layout, all I need to do is change the "grid-template-areas" in section style. I can swap the "sidebar" from the left side of the page to the right side without much effort. I don't even need to touch the markup at all (which I would have to if I was using Flexbox)!
Example:
<style>
section {
display: 'grid';
grid-template-areas:
"header header sidebar"
"main main sidebar"
"footer footer sidebar";
}
Flexbox feels imperative while Grid feels declarative to me. Why would I want to use Flexbox over the convenience Grid provides? Grid does everything Flexbox does and then some! With Flexbox I would have to do all the calculations myself to achieve a layout that is now set in stone. Any changes would require me to either change the markup or change the calculations in each flex element or both. Grid on the other hand can be changed declaratively! I would just need to specify my layout and the rendering engine takes care of the rest! I don't need to change the markup! After working with Grid for a few months now I have come to the realisation that I have pretty much stopped wasting time on calculating and positioning layout and fiddling with deep nested markup. I can say with conviction that no other feature has given me this level of satisfaction. Kudos to the team that conceptualised Grid! To top it all, Grid takes care of accessibility issues one would face with Flexbox. Maybe you want a Sidebar to the right for people who aren't visually challenged but with Grid you can maintain the hierarchy for visually impaired users who rely on screen readers. For them, the Sidebar would always come before the content and not after. Flexbox is heavily dependent on how you place your markup which sucks from an accessibility point of view. With Grid, the layout declaration is completely dissociated with markup order (which is very important because you don't want to be juggling with both at once while setting your layout). Flexbox is tied to markup order which means any major changes would require you to mess with the CSS styles as well as the markup. If you have deeply nested markup you are in a whole world of pain!
Just my two cents!
In theory, I agree. Grid is nice for layouts. But in practice, you often can’t actually make that decision, due to browser support requirements. (And I’m not talking about IE11—it’s typically a little painful, but you can get your -ms-grid-* properties equivalent to your grid-* properties with some autoprefixer and a little extra work, when it’s page layout rather than auto content layout that you’re using the grid for.) To use it as an enhancement if present, yes, but it’s often not acceptable to require it. Thus, you need your Flexbox fallback anyway, and if there’s no functional difference between the two, well, why would you put the Grid implementation in? (If you look at the Topicbox hero area example I mentioned earlier you’ll see it handles the absence of Grid support nicely, falling back to the single-dimensional Flexbox layout used on smaller screens. If the Grid layout is different from the fallback Flexbox layout, my remarks do not apply, and using both is reasonable.)
I also observe that two-dimensional layouts are actually not common these days, and almost all of the ones that there are are trivially reducible to nested one-dimensional layouts.
> Flexbox is heavily dependent on how you place your markup which sucks from an accessibility point of view. With Grid, the layout declaration is completely dissociated with markup order (which is very important because you don't want to be juggling with both at once while setting your layout).
When you treat Grid like this, you’re neglecting an important part of accessibility: the DOM order is still very important, because it’s what accessibility tools use, and what things like Tab navigation works on. This is why using `order` to reorder things in Flexbox is normally a bad thing to do, and why you need to be cautious with any sort of reordering with Grid.
So in a way, I argue that Flexbox’s limitations actually tend to help you maintain sanity and accessibility, not break it. It’s not always the case, and it does mean that you often end up with a little presentational markup, but in practice that’s basically unavoidable for anything serious anyway. (I say that as one who spends way too long on keeping his markup unblemished.)
Using raw flexbox you'd have to resort to hacks with negative margins on the container (https://stackoverflow.com/questions/30887071/margin-top-only...), which often affects layout of the container in unpredictable ways, making it less than ideal for building reusable layout abstractions.
A popular alternative is to resort to screen size media queries to set margins, but screen size doesn't always match whatever container you have to render content in, so you end up with very brittle layouts that need all their media queries adjusted when you move containers around and add elements that constrain the dimensions of the container like sidebars (or even worse, collapsible sidebars that change width dynamically).
My main question is how well it prints.
For example, if you want to move your navigation/controls to the bottom of the screen on mobile devices for better ergonomics, it's far easier with grid than flex because you can specify a completely different layout at each breakpoint. With flex you often have to duplicate content in different areas of the screen, then conditionally hide/show them based on the current CSS breakpoint. This can have a negative effect on page load times, SEO, and overall complexity, as well as just being kinda gross.
Another example: imagine you have a 2x2 layout, say a sidebar and top-bar that join in the top left quadrant. Keeping ([0,0], [1,0]), and ([0,0], [0,1]) the same height and width respectively, without specifying explicit heights or widths, is very difficult without grid. It might be impossible, but I'm not that great at CSS so I'm not 100%.
The only thing I can think of off the top of my head is that if you're doing something programmatically and don't know how many items will appear in a grid, then Grid is better because Flexbox doesn't handle orphans well.
Some have suggested using the margin-right: auto; trick, but it doesn't always work if you have your elements even moderately styled with padding and borders and such.
If there was something like justify-content: space-between left-hanging; or justify-content space-between right-hanging; that would be ideal.
Maybe you're overthinking grid and I'm overthinking flexbox? Cause grid is really simple to me: you define a grid and then you specify which area in the grid you want each child to span.
I love it.
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.
Besides which, there is (simplified) code provided.
Deleted comment
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?
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.