Depends on the use case. If the grid's items have varying widths then masonry is the better option. However, for a grid with equal width items, I'll definitely go with magic grid. It's just so much lighter (2.3kb minified) than masonry (23.5kb minified).
I really don't see what's lacking with CSS Grids for equal-with items. Even accommodating different sizes, and allowing reordering for packing, works fine with just CSS.
When the components in a grid have different heights, a single longer or shorter component stretches the whole row or leaves unpleasant whitespace at the bottom.
You can use auto-flow: dense to have the grid backfill gaps. I haven't had much chance to test its limits cross browser yet though but trivial examples have worked for me so far.
It isn't as optimal a layout system as you can get with javascript but generally so long as all elements are at least half the height of other members of a row it doesn't look offensively bad. And there is room for more sophisticated layout algorithms in the future.
And it generally isn't that hard to pad grid items to be multiples of a common height so they can organically fill consistently.
+1 - I recently went looking for a CSS framework (I was still in the “Bootstrap” mindset), and ultimately decided on vanilla CSS grid + flexbox. If anyone is looking for a resource to learn CSS grid, I highly recommend Grid Garden: http://cssgridgarden.com/
I just started this tutorial. Thats is a "why", not a "how"... So maybe I can ask here. Why grid-column start include the value and grid column end exclude it... In fact where there is a ressource for understanding css logic on the internet?
> Why grid-column start include the value and grid column end exclude it
All CSS grid properties are defined in terms of grid "lines", not cells. If you have a grid of 2x2 cells, there are actually 3 vertical lines and 3 horizontal lines:
1 2 3
1 ┌─┬─┐
2 ├─┼─┤
3 └─┴─┘
"grid-column-start: x" means "this area starts the x vertical line"
"grid-column-end: y" means "this area ends at the y vertical line"
As you can see, there is no possible ambiguity here on whether you mean "inclusive" or "exclusive" like there would be if you referred to cells (which is why you had this question). That's the reason they chose to go with the "lines" model.
> In fact where there is a ressource for understanding css logic on the internet?
Usually each CSS spec has a rationale and some introduction to the "why" and the "thinking model" of the spec. For CSS grid you may look at [1].
For those wondering why not just use CSS Grid -- it's not build for that[0] (see @rachelandrew's comment). It's not explained on the repo README but the author goes into it on the explanation blog post.
As mentioned, Masonry[1] is the other famous library for doing this. Magic Grid also has a Vue port[2] if you're into that.
[EDIT] - PR just got merged, explanation of this stuff is on the Github README now
I'd much rather drop in a library like MagicGrid or Masonry and deal with it from there, to be honest, instead of trying to hack grid to do it. I think grid could be extended to handle this kind of design but until it is...
I'm not sure -- the problem is that the height is determined across the whole row -- as soon as you have one item bigger than others in a row it falls apart.
Some of the auto sizing features of grid make it seem like it could work but I haven't seen too many examples, and rachelandrews saying "it's not built for that" is more than enough to discourage me from trying to hack around it.
How about a grid of equal-height items, but intersperse something between each row- can this library do that?
For example, consider a bookshelf design where the books are the items and each row has an element underneath it (the element would itself be composed of say 3 images for left and right ends plus the middle)
afaik that's not possible with CSS grid either since grid doesn't have an `nth-row` selector
I spent some time trying to build a simple grid layout with dynamic width and height items in order for the layout to naturally flow responsively. Most libraries—like this one—require fixed width items or fixed width containers with fluid items.
Fully responsive turned out to be a lot harder than I thought it would be due to lots of rabbit holes, but the algorithm was fairly straightforward. My first approach was to try CSS Flex and Grid, but they didn't cut the mustard since they're not really designed for this sort of thing. I then found CSS Columns and had that working, but it proved too unstable for production use with issues with the sort order of items, wrapping across columns, and cross-browser support.
I've experimented with fully responsive layouts too for my website (http://www.uptopnews.com) but at the end I just used css flex gird. I almost build a comment section where the comments are cards in a grid but that rabbit hole was too deep.
If you are looking for a more flexible solution with support for any layout and support for animations, something like iOS' UICollectionView or Android's RecyclerView, have a look at https://github.com/turbolent/collection-view.
The visual lines. I seem to remember a few frameworks i saw a while back which allow you to control these grid lines and help you do them according to the golden means.
Why do you need yet another library? Not invented here syndrome? A simple Github search gives me literally thousands of results: https://github.com/search?utf8=&q=css+grid
Correct me if I'm wrong, but using window.addEventListener("resize", () => (), 200) is no good, you probably should consider window.requestAnimationFrame() and debouncing. Otherwise, your library will drain battery juice, despite it's really lightweight. Say, on Android, actions like typing into an input field, changing orientation, scrolling backward and triggering url bar appearing, all of them do trigger costly document reflow.
You're right requestAnimationFrame is more efficient than using the resize listener with a delay. I'm actually working on an update to change that. It'll be fixed soon.
40 comments
[ 2.8 ms ] story [ 85.3 ms ] thread[1] https://github.com/desandro/masonry
It isn't as optimal a layout system as you can get with javascript but generally so long as all elements are at least half the height of other members of a row it doesn't look offensively bad. And there is room for more sophisticated layout algorithms in the future.
And it generally isn't that hard to pad grid items to be multiples of a common height so they can organically fill consistently.
https://flexboxfroggy.com/
All CSS grid properties are defined in terms of grid "lines", not cells. If you have a grid of 2x2 cells, there are actually 3 vertical lines and 3 horizontal lines:
"grid-column-start: x" means "this area starts the x vertical line""grid-column-end: y" means "this area ends at the y vertical line"
As you can see, there is no possible ambiguity here on whether you mean "inclusive" or "exclusive" like there would be if you referred to cells (which is why you had this question). That's the reason they chose to go with the "lines" model.
> In fact where there is a ressource for understanding css logic on the internet?
Usually each CSS spec has a rationale and some introduction to the "why" and the "thinking model" of the spec. For CSS grid you may look at [1].
[1] https://www.w3.org/TR/css-grid-1/#grid-concepts
As mentioned, Masonry[1] is the other famous library for doing this. Magic Grid also has a Vue port[2] if you're into that.
[EDIT] - PR just got merged, explanation of this stuff is on the Github README now
[0]: https://github.com/rachelandrew/cssgrid-ama/issues/19
[1]: https://github.com/desandro/masonry
[2]: https://github.com/imlinus/Vue-Magic-Grid
https://jsfiddle.net/cbjzped2/
The problem with that is that the grid rows are determined dynamically:
I'd much rather drop in a library like MagicGrid or Masonry and deal with it from there, to be honest, instead of trying to hack grid to do it. I think grid could be extended to handle this kind of design but until it is...So do you mean this is a less complex, more sane way, or did you mean it enables things that couldn’t be done with grid/flex?
Of course sanity is good but it’s an important distinction, say if a simple scenario could avoid a library dep without much extra complexity.
Some of the auto sizing features of grid make it seem like it could work but I haven't seen too many examples, and rachelandrews saying "it's not built for that" is more than enough to discourage me from trying to hack around it.
For example, consider a bookshelf design where the books are the items and each row has an element underneath it (the element would itself be composed of say 3 images for left and right ends plus the middle)
afaik that's not possible with CSS grid either since grid doesn't have an `nth-row` selector
Fully responsive turned out to be a lot harder than I thought it would be due to lots of rabbit holes, but the algorithm was fairly straightforward. My first approach was to try CSS Flex and Grid, but they didn't cut the mustard since they're not really designed for this sort of thing. I then found CSS Columns and had that working, but it proved too unstable for production use with issues with the sort order of items, wrapping across columns, and cross-browser support.
I ended up building our own library: https://github.com/heydovetail/react-masonry-responsive
There's a nice brief writeup about using CSS for masonry layout here: https://regisphilibert.com/blog/2017/12/pure-css-masonry-lay...
Anyone know of a good grid layout library/framework.
With grid i don't mean the css syntax version but the actual visual design grid that gives you something like:
https://cl.ly/a01ae1db0240
It really looked like you would have been referrring to the text overlapping multiple columns, is that not related to what you meant?
Something like this https://www.pcscoreboards.com/footballscoreboardpro/scoreboa...
Notice the red 8 seems to need to overlap between rows.