What would you call this layout?

[@4ankers]

Kevin, I really like this format of you reacting to and talking over your thoughts on articles. If you like doing this content, you should definitely do more of it

[@ThatRobHuman]

There's an article on the chrome dev-blog that showcases the rational of the "other side" (ie: keeping it a separate display). I think I'm in favour a separate display value. I don't think doing so would preclude browsers from re-using relevant implementation details, but from a consumer standpoint, I think the fact that only a subset of grid-* properties are usable while in "masonry mode" is a strong signal that it might be better off being it's own display.

[@KevinPowell]

What do you think? Should this be something we can do with CSS? And if so, what approach makes the most sense to you? Maybe it's something that isn't even being talked about as an option right now!

[@octothorpe12]

Totally a thing that should be handled without JS. What I'm not sure of is how the current implementation handles layout versus source order. Based on Jen's article, you are not guaranteed to have the source order match the display order. I think it would align better if, for example, items 1, 2, 3, 4 would be above items 5, 6, 7, 8, regardless of the height of items 1,2,3,4. Currently, if 1 is longest, 2,3 are the same height, but 4 is shortest, 5 will go under 4, which is not how we in the west read things. It makes it very difficult to have a 'flowing' layout but also keep things in (example) a chronological order.

[@octothorpe12]

Also, 'waterfall' is still 2D, Grid is 2D. Flexbox is 1D. It's a columnar but not modular grid.

[@QwDragon]

Not an English speaker but masonry seems fine (except I forget order of letters in it). One more thing that's not mentioned in video: I'd like to be able to apply masonry to columns instead of rows too. And have to think about both at the same time. Definetly as part of the grid as it would provide more abilities.

[@stevenstraker5105]

Kevin, it might actually be a good video idea to review all the current display types, as even the MDN page can be a bit confusing. From "display: flow-root" to "display: block flow" to "display: contents" etc. I was thinking since we have display: inline, display: block, and display: inline-block, why not make masonry display: flex-grid? Though after looking at MDN, I might need to brush up my understanding of outside vs. inside flow for the property.

[@conceptrat]

I think maybe some of the thoughts should be on how this might get applied to blocks and content when composing the HTML. Used correctly it could simplify the layout of the blocks of content, not just images, within sections in HTML.

[@hoshi411]

I love "rows:off;" because then we can make this work horizontally with "columns:off;"

[@sergio9929]

I liked the idea of 'display: masonry' much more until I saw that. However, I have one issue: how can you change the flow direction from this: → 1 2 3 4 5 6 7 8 to this? ↓ 1 3 5 7 2 4 6 8 using "grid-direction: column", similar to "flex-direction"? "grid-auto-flow: column" does not work without explicitly defining rows.

[@rujor]

And if both are off 😬.

[@novamc7945]

​@@rujor Think about it. It would still work like regular flow, just a bunch of pictures stacking and taking up the screen and not having any sort of arrangement to them.

[@JaredMeadows]

@@rujor it would just fill in content diagonally 🤯

[@ChristofferLund]

Grid template rows off/omit and part of grid definitely screamed as the best one for me. And as you say leaves room for a horizontal version

[@andreasnulein782]

+1 for `display: grid, grid-template-rows: masonry`

[@Godalming123]

+1 on this as well because it allows grid and masonry to use the same properties for the numerous qualities that they share, rather than me remembering 2 syntaxes. I also wouldn't use masonry if it does not support items that span multiple columns.

[@karis7539]

it shouldn't be a grid but another display property

[@KawazoeMasahiro]

I do agree it should be part of grid. The main reason is that you can already kinda do this, with an insane performance impact, by using a dense grid with 1px tall rows and elements spanning the correct amount of rows for their height. This feels semantically similar, which gives it a good place within the grid spec. Combined with the rows off naming, it completely dodges the naming issue, which is great.

[@feldinho]

One disadvantage of having masonry and grid being the same display type is that a feature that is harder to implement in one could block development in the other. For example, imagine styling guides is tricky to implement on masonry, that could delay its implementation on classic grid. About the grid-template-rows, that could easily be renamed to template-rows to make it more general. The same already happened for grid-gap, that was replaced by the more general gap, that works on flex and grid.

[@smaza2]

it's kind of grid-y, and kind of flex-y... they should call it "display: flexgrid" and add it to the css mistakes list pre-emptively 😊

[@pepkin88]

Just like inline-block

[@smaza2]

@@pepkin88 you absolutely understand my vision

[@CrispyCircuits]

Well then, you could have both flexgrid and gridflex to make everything so much easier to learn... Help!

[@basiccoder2166]

Thanks Kevin I was the one who requested this video a few months ago in the discord, I'm the one who created nasa clone, I learned way more from this video that I didn't knew Thank you

[@tobiasalexander4491]

Given the impact of changing one element to force a complete reflow of every other item within the grid, a good name might be "grid-template-rows: cascade;" It also has synergy with the waterfall idea.

[@gabrielhartley5213]

I'm not deeply enough into the details to say anything substantial about the issues you brilliantly lay out here; but I do want to say two things off the bat: one, I love your KZbin editing style here in which you leave in (demonstrate) your own moments of pauses and thinkings (thoughtful yet tentative considerations) as part of the presentation here without the need to edit it out into some prematurely-finished and authoritative statement; and two, I had been searching for any word from Jen Simmons off and on since she left Firefox Grid way back when-I knew she had gone to Safari but I hadn't yet stumbled upon her later and current statements on Grid. I'm so glad to see both of you at work here (even if only tangentially). I also remember Wes Bos doing a video about five years ago on his magical use of javascript to create what I think is exactly what you are talking about here (except, of course, via javascript rather than "pure" CSS Grid-"CSS GRID: Image Gallery Exercise - 20 of 25"). Thanks for your videos, Kevin.

[@hack_nug]

1. waterfall is more idiomatic for css (cascade, flow layout...). 2. yes to this being part of css grid (hopefully this will remove the 999 rows limit if that's still a thing). 3. of course. anything clients design with this particular layout in mind. 4. only the regular stuff built with masonry.js and similar libraries. i did write my own implementation years ago though, and explored using multi-column, flexbox, and grid to avoid the js overhead when resizing the window and all that. iirc i ended up settling for having multiple copies of the items and pre-calculating positions for each of my breakpoints using the image size from my cms (maybe i did deduplicate the elements somehow but i can't recall, my focus was on preventing jumpy elements on resize and having the correct layout show instantly to the user). please note i wasn't using this layout for arbitrary content, only images. 5. we should be able to use this for horizontal layouts without resorting to `writing-mode` or similar properties. turning off columns or rows would allow for this so perhaps if this gets implemented outside of the grid spec, i think `grid-template-` should be renamed to `template-` just like we did for `gap`

[@Ufphotography]

Masonry layouts combined with a native lightbox that is customizable would be my dream. Up until now I always have to rely on third party plugins for these things which is annoying and unnecessarily bloats wordpress. Thanks so much for being part of this team and working on stuff like that to make CSS easier and more functional! I really enjoy your content and have learned a bunch from it!

[@mahadevovnl]

I don't think it needs to be a grid at all, because it's not a grid. It's a flexible type of boxes, one might call it a "flex box"! It's a new type of flow from left to right. The first row would have elements that are different heights, and the next row would be the same... but then there are gaps. So instead of `align-items: center;` I would prefer `align-items: compress;` of sorts. Let the next row of items, each item individually, move up to its element above it, taking into account `gap` and `margin` and such. What if the first "column" (it's not a grid after all) only has tall items? Well, sucks. It means one column will be larger because items will still go from left to right in their respective rows, they'll just skooch up to the element above them. So it would be: display flex, align items compress, flex-wrap, and only work with block or inline-block children.

[@novamc7945]

The brilliant thing about this idea is that when I was reading the article the first thing that came to mind was "I feel like this is (or should be) already possible with flex..? Why would it not" then I realized I was wrong in understanding the problem So from an intuitive pov i think making it a part of flex box does actually makes sense, a whole lot more than people give it credit for. I wonder how no ones talking about flex box

[@mahadevovnl]

@@novamc7945 Thanks, I think what inspired me was an experiment I once did where a vertical flexbox would look like 1 column of a masonry layout, and you could just repeat that. I was hoping that the `columns` property (used in CSS for text blocks) would work nicely with multiple vertical flexboxes, but it didn't. The CSS grid, to me, should remain as a kind-of table-like rigid structure, not something that's flexible like what a masonry layout would require. If not flexbox, then definitely not grid, but perhaps a 3rd option: flex-grid? :) Anyway, I think they're already stuck in their way of thinking. Target fixation in a way; they already decided "it must be grid!" so it's not gonna change I'm afraid. `align-items: compress;` just sounds too intuitive, perhaps ;)

[@novamc7945]

@@mahadevovnl The first part of your reply is exactly what I was thinking. And you're right. It's probably going to be grid now anyways. And I haven't seen anyone else talking about using flex and not grid, flex-grid, or a new display type other than you, so it's probably not happening anytime soon

[@sllkevin8885]

Should be part of grid. I was just doing something where this would have helped. I had a grid of company employees where each card is stacked image over name+jobtitle. Then employee page opens to 2-col name+jobTitle over paragraphs bio with the image on the right. The problem switching to columns from stacked is that the image needs to row-span-2 or there’s a huge gap between bio and name. So having the ability to just add “masonry” to the parent is easier than having to manually manage row/col spans to each child at every break point. Essentially, masonry could just ignore rows all together. Having grid and flex separate is already not convenient to swap between and masonry is just a property of grid.

[@FlorimonR]

Great news ! Love the ideas of names and reasons behind❤

[@conceptrat]

The extra thinking when you're were explaining grid vs flexbox goes with my thoughts that grid should be something possible using flexbox and drop grid. Then masonry becomes a definition within flexbox and flexbox then fulfills it's purpose, to provide a flexible box/block layout.

[@kushaagr]

When people were excited for container queries and subgrid, I was getting excited for Masonry layout. This is the one feature I still want till today! 🫰🤞 Just image dropping lot of pictures, turn lazy loading on, and with one line of CSS the layout looks professional. No performance considerations, no thinking required for layout planning.

[@justingolden87]

As someone who has written CSS for a decade, but also as someone who is a simpleton and is far from perfect at flex and grid, I like the idea of setting `display` to either `flex`, `grid`, or `masonry` and still using common properties like `gap` etc. This sounds simplest and most intuitive to me. It's like you have a 1d layout, a 2d layout, or a masonry 1d layout. It's intuitive given you understand flex/grid, which aren't going away and will be taught regardless. As for naming, between masonry and waterfall, I prefer masonry, which I think is more common, but we should do not whatever is most common now, but what is most logical for the long term, since this will exist for decades. People will be googling this millions of times and writing it millions of times, so we should think of other languages, cultures, semantic overlap, etc. and get something intuitive and simple for the most people.

[@CrispyCircuits]

Well, having to write "grid-template-columns" and such long names is a PITA. Let's go old school Unix and have fewer letters g-t-c, msnry, flx, grd, bkgd-clr. OK, that's mostly a joke.

[@emp5920]

This is useful even for very simple applications without images. e.g, at my work we built a responsive one or two column grid of form fields, but because the form fields are not all the same height (e.g., some form fields consist of multiple 'sub fields' underneath), css grid generates extra empty space to align the fields neatly along rows. We need to keep forms compact, so we don't want this extra space, and afaik the only chrome-supported way to fix this is to add negative margins to sort of 'break the grid' and hide the extra space with judicious z-indexing. This results in a small but tedious chunk of magic-number-filled css that makes the grid 'compact'. OTOH, testing with grid-template-rows: masonry on safari just auto-magically works without any additional css... wish we could have made use of that! Also, just for the sake of adding another suggestion for consideration (though I'm still leaning for display: masonry): the comment about the 1-dimensional nature of masonry made me think that this could be implemented inside `display: flex` under property `flex-template: 1fr 2fr 1fr` (e.g.). This property could determine the size of wrapped columns in the cross-axis direction.

[@TheLollercaster]

oh wow, just realised you have 900k subscribers! Well done! I still remember when it was around 100k

[@CirTap]

I'm fine with grid and was fine with "off" in the Github discussion but watching this here I remembered "avoid". That's what it'd eventually do: avoid creating rows -- or columns if this layout type runs horizontally (like many brick walls actually do) This would prevent layout contraints from being created on the opposite axis. In horizontal mode it'd be a bit like "text-align: block" or a more controlled "justify-items" thing, with aspect ratio control and other stuff thrown at these "inline boxes"... "avoid" is also a keyword for the page and column layouts aka the "CSS Fragmentation Module" to avoid page and column breaks of elements or their contents -- with mixed browser support but working for page layout tools like Prince XML. We (webdevs that is) should keep in mind that CSS is not exclusive to style and layout web pages based on HTML. It is also used for XML data and doing print layouts. Screen based render engines -- aka browsers -- really suck at doing nice and proper page layouts and control page breaks etc. but dedicated apps like Prince XML don't and they have their own (proprietary) CSS extensions to control stuff on printed pages.

[@Bughi04]

I literally did something like this yesterday. ( Most likely very un-optimal -- but nonetheless it works-ish ). Support for something like this would be amazing and i think it would help developers save time in answering the question: "Why does something like this take so long to build? I made it in "insert favourite design platform here" in 10 minutes". I'm really curious if this will get implemented . Thank you @KevinPowel for sharing this.

[@tinusg]

I would call it display:stacks

[@tgd-613]

If we're already using grid, why not use grid-auto-flow: dense (or column dense), after setting the grid-template-columns / grid-template-rows, and maybe having some of the images span more than one column (or row), if needed?

[@kevinfisher7032]

It’s great that we have such a responsive community (css humor :-) I agree with your observation about masonary-template. What’s the down side…for developers? This is an option, the more options we have the better. I probably would never use it but I still appreciate the fact that it’s available. Half my job is keeping up with what's possible and then going to look it up if I need it.

[@qpn6ph9q]

grid-template-rows: elide; would be my preference. This layout fits both definitions of the word elide.

[@matthewfowler6577]

The principal structure of this layout is the content ‘cell’ and not the row or column, which suggests a flexbox solution not a grid solution. For each ‘cell,’ we would want an ‘align-items’ option that allows it to have its own independent size - maybe just ‘flex-cell’. Then on the main structure HTML tag, i.e. a div tag, it can have the CSS of ‘display: flex’ and a way to define the amount of ‘cells’ wide the tag would be. This structure would also have the CSS class of ‘‘flex-wrap:wrap’. This would give us the defined ‘column’ look and give you the option to flex an ‘cell’ over several of those ‘columns’ i.e. flex-span: 2. Super simple CSS callup example: HTML: div: .flex-cell | .flex-cells-3 | > div: .flex-cell-item CSS: .flex-cell {display: flex-cell, flex-wrap: wrap;} .flex-cells-3 {flex-cell: 3 }

[@madebylewis]

"vertical masonry", and save thought for "horizontal" and maybe "best-fit" for a less rigid bento layout

[@denoww9261]

That's a good point, there's no reason that this should have to be about only rows. And what about e.g. vertical writing modes?

[@madebylewis]

​@@denoww9261 Usage of "block" & "inline" can definitely be applied

[@PeterHebert]

display: bento;

[@LukeDorny]

After hearing your thoughts, I agree that it’s more like flexbox than grid because flowing columns. But, if you swap the direction (if that is to be a feature) of the masonry layout then it’s no longer a “waterfall”. I know. Silly, but these are all metaphors. I’ve rarely seen this called waterfall, for what it’s worth. It’s similar to both grid and flexbox in many ways, but it breaks things about grid and flexbox, too. So it should be its own thing. Call it bricks. Castle. Whatever we like. We’ll adapt and adopt.

[@adriankerrison]

Is there a reason they went for "masonry" instead of "mosaic"? Though I do like the approach of making it an aspect of grid-template-rows instead. Or "align-items:mosaic"?

[@SimonJessey]

I would 100% support having this as an extension of Grid and I would suggest grid-template-rows: dynamic

[@timreed9722]

Just catching this 3 months after you uploaded it, but I ran into a situation in which I needed this layout. I watched your video from 3 years ago and was like "Hey... this is from 3 years ago. Surely browser support is good today!" Then I check on Can I Use and nope. lol Needless to say, I was a little disappointed. lol However, I came across a different method for implementing this that worked really well. Someone on a forum or a blog somewhere mentioned column count. It lays out my images without aligning them the same way on the next row. Added some gap and it worked. BUT, I'm definitely hoping that support for this starts to roll out soon.

[@timreed9722]

Hadn't finished watching your video all the way through, but noticed that you did mention the css columns. They worked well for me in the situation I needed this layout.

[@EvanEdwards]

I actually rather like the idea of: { display: flexbox; flex-order: masonry; flex-wrap: 3; } Items then wrap exactly as flexbox, except the order is auto-calculated across all wrapping areas. It can go inline or block (traditional top down would simply have flex-direction: column), and flex-wrap would have similar syntax with clamp, etc as grid. Basically, it is extended from wrap/nowrap/wrap-reverse to add a count of wrapping. flex-flow would be extended with flex-order. Alternatively, flex-direction could have masonry added as a keyword: { flex-direction: column masonry; flex-wrap: 9rem repeat(auto-fill, 6rem); } I do tend to like Google's over mine, for the spanning. But mine as an addition to flex gives some nice wrap options that are "flex-like" rather than trying to turn flex into grid. It controls what happens when it wraps, but doesn't dictate that it wrap.

[@nomadshiba]

i liked `grid-template-rows: off` it describes what it does without giving it a layout name you can also use align-content to tell where everything should fall over. so if i say `align-content: start` everything falls to block start, and if i say `align-content: center` everything falls to center. can also say `grid-template-columns: off` "masonry" is a layout name, we shouldnt give a layout name to a behaviour of grid, i think "off" explains what it does.

[@paul_subtirel]

Some people call it Bento Grid from the bento box look that you would see on the Japanese lunch trays, very nice anyway, thank you for this video, i will definitely try it out what about display: grid; grid-bento-columns: repeat(auto-fill, minmax(14rem, 1fr)); grid-bento-rows: off;

[@mihai10stoica]

Bento fits in the current grid. Nothing to do with masonry.

[@gingered]

I had just started on a personal project where I added grid-template-rows:masony as something that would apply as soon as it reached full support, and let it default behavior until then. I think masonry is a nice enhancement for grid and doesn't need to be its own display. For naming the row- off doesn't make sense to me- maybe collapse, or condense makes sense if not masonry? Though I can turn it on in Firefox right now and it works fine (as far as I can tell on my small project) so maybe this is overthinking a bit? Good questions to ask before full browser support, makes it pretty hard to change after!

[@KelseyThornton]

This is kind of like a vertical flexbox. The only problem I have with this is that, unlike flexbox, the 'end' is undefined. Having said that, I think that it fits nicely in grid, especially if you consider subgrid (which in itself is awesome). Reading the existing comments, I like the idea of Grid-template-rows: omit, as this allows for the use of 'off' in the future.

[@helw7]

I had to decide what name to use when I developed Gridzy.Gallery . Although at the time I only knew the term "Masonry" for such layouts, I called it "Waterfall" because I think it describes the vertical orientation much better.

[@markboots_]

For me it also makes sense to have it within grid. My suggestion would be "grid-template-rows: omit"

[@kushaagr]

One great usecase I can think of this feature would be in Github Readmes... I have to sometimes put 3 or more screenshots of my webapp in the readme file, and then there is no way other than custom styling to make it look good. It would be great if I can just wrap all images in a div and add `style="display: masonry"` (or whatever syntax they end up with)

[@Pfoffie]

I was shocked by template-rows: off and then I was like … DAMN! That is smart

[@deatho0ne587]

I want both the row and columns to be based on the size of the lower boxes. Meaning it can deal with multiple image/card sizes and it just fits them together like a real stone wall. Do like the concept of the prices always being in one location but again more options are better. If it is part of display: grid or display: stone_wall (/jk) I do not really care as long as it makes sense to use and is flexable enough to cover enough.

[@ittixen]

Hot take: "grid-template-rows: flex"

[@BrunoMussoi]

Isn't masonry just flexbox but vertically instead of horizontally? lol Maybe there is a hacky way there to be discovered. Also, i find it strange this need to make mansonry. It is like hardcoding a layout trend. Isn't up to the dev to make their layouts? What if later on there is a diagonal trend, or hexagonal tiling, etc... will we get a display (or whatever other solution) for every type of layout?

[@matthewmullin6042]

It's pointed out in the video that this layout can't be done currently in CSS, you need JS for it. I agree with Kevin that layouts should be in the realm of CSS.

[@LokiDaFerret]

I would agree with you that the naming convention should mirror grid. But it should also be its own display type So the two can diverge. It would be uber confusing if some property was created that only applied to grid or only masonry which would inevitably happen. So keeping them as two independent display types avoids that confusion.

[@TyroneMitchell]

what about grid-template-rows: none; ?

[@peteharrison3241]

I think this type of layout has been achieved for a long time using JavaScript masonry scripts, so masonry is a well known and understood term. This is just a CSS version of something we've been using for a long time. As for the rows off or whatever, what about rows flow ?

[@AdarshSingh-mm9lh]

*masonry layout* 😃, last week I have created the same but for 2 column by using css COLUMNS property (and it's awesome😎). (although earlier i thought to use library😬 ).

[@mebamme]

I'm really averse to "display: masonry" - the display property feels like something really fundamental that something specific like a "masonry" value would feel tacked on to. Like you said, imagine explaining it to beginners.

[@xphstos_]

As an ex designer, now a front end developer, my view of a masonry layout is that of a grid layout but asymmetrical. The key word is asymmetrical for me. So my proposal would be to keep the grid as the display value and use the word ‘asymmetrical’ or ‘asymmetric’ for rows AND columns. We also have the property grid-auto-flow. Maybe we could utilize that instead of template rows. Something like ‘grid-auto-flow: row asymmetric’

[@GrahamAtDesk]

I'd be thinking wrong the line of display: stacks, or perhaps display: tracks

[@JesseJuup]

How about something like grid autotiles flow vertical/horisontal/circular/spiral/zigzag ?

[@donmorris4506]

Masonry is very descriptive. Works for me

[@toddcamnitz6164]

“Masonry” seems fine. +1 to keep it separate. Argument that although similar, it’s foundationally “not a grid” carries the day for me.

[@JaredMeadows]

how about grid-template-rows: cascade; or grid-template-rows: flow; what do you all think? I'm torn between those two! 🤔 note: I don't really like grid-template-rows: off; because it doesn't hint at what it's really doing with the rows, not to mention, it could bite them in the butt if they later come up with some other way of using weird non-defined rows 🫠

[@MyDpop]

grid-template-rows: adaptable; grid-template-rows: malleable;

[@JaredMeadows]

@@MyDpop sorry I think those are both too generic, and don't have any hint of what you'll get, that's why I suggested "cascade" or "flow" because the name implies that the rows will "cascade" or "flow" down the page! 😁 🧠

[@lumynou5]

As many comments here, I think "waterfall" describes the vertical layout better, so my opinion is -- neither "masonry" nor "waterfall". Because the keyword should be able to use in both directions, and things like "horizontal waterfall" feels weird. I think `off` is ok since I can't think of a better one. Maybe "uneven"? But I'm not sure, because it seems more like "a grid without rows", i.e. the elements in each column are not aligned horizontally, rather than having "uneven rows". Also, I saw a comment said `grid-template-rows: omit`, I think the problem of it is that "omit" sounds more like using a default or auto option (what `grid-template-rows: none` does; you omit the property and the browser implicitly handle the rows) instead of having no rows (I'm not an English speaker so this might be my misunderstanding.)

[@emanuelmilani7976]

For me something like grid-template-rows: fill / filled /auto-grow (because fill the content on height) Or not-equal / irregular / not-uniform (self explain)

[@RhythmnOfThought]

Why is that difficult? Just use column-count: 4 without any flex-layout and you have exactly what you want with age-old css. (Support on IE10!) Edit: Nevermind, that question is answered at 2:32

[@ihelpdogs]

On the lines of 'masonry', a 'stone-wall' layout is fitting.

[@barmooj]

rows: collapse is clearer to me and allows columns : collapse to have a meaning. I remember Netflix having a masonry layout … not sure if it is considered well known though 😅 I think it should not be a display type because display are already complex and carry out some bad legacy

[@troyweber569]

I'm not super invested in this, but just had a random thought. It seems like it could be nice to use masonry horizontally and not just vertically.

[@christhompson4653]

I guess it would still have rows, in that the row gap would still apply. So maybe something like grid-template-rows: separate

[@EricFressange]

What about grid-template-rows: auto-fill; ?

[@meganweber5057]

How about grid-template-rows: stagger?

[@KeithGrant]

I think it should _not_ be part of grid, specifically for teachability reasons. I don’t think most developers learn all of grid. Many learn `grid-template-areas` and basic column sizing and stop there, but `grid-template-areas` does not transfer to masonry. So now, to learn masonry, they have to do a deeper dive into grid. THEN they have to do a dive into masonry to figure out which grid principles do and do not apply. I think that makes masonry less accessible to a less experienced developer. Whereas a separate display property means you can learn it directly, and as a bonus nearly all of that will also apply to grid. Or, if they already know grid thoroughly, it’s still a reasonable lift to learn which grid properties/concepts they can apply to masonry.

[@michaelpumo83]

At the end of the day, masonry is still a "layout" based on a type of "grid". That grid just happens to behave in this compact way we know as "masonry". Therefore, I think masonry should be a part of the CSS Grid specification.

[@ahooton]

Hey Kevin, any plans to cover View Transitions on your channel?

[@pascalmaranus]

Flexbox has flex-flow, shouldn't it simply be something like grid-flow, by default set to "rows" - the current grid flow, but you can also set it to "auto", where it places it in the first column to vertically have space. You could also call the property "vertical-flow" or "vertical-align" or something like that.

[@matthewmullin6042]

flex-flow is just a combination of flex-direction and flex-wrap. Grid already has grid-auto-flow that handles its direction.

[@Stoney_Eagle]

I think we should add it as a sub property of display grid since we call it a "masonry grid". If the behavour of sub grid, template columns and all other properties would remain the same then adding another display property with its own sub properties would cause a lot of frustration, specially if you use utility css classes. .masonry { grid-type: masonry; grid-template-rows: off; } And your cards automagically flowing to fit would not be so bad right 😊

[@graysonpeddie]

3:28 I don't use JavaScript in my website! I simply pretended that JavaScript does not exist. Sure it does, but I made "JavaScript does not exist" as part of my mindset! I don't have a need for masonry layout as I tend to prefer images to be in 16x9 format.

[@DocGenius42]

I wouldn't go as far as pretending it doesn't exist. It is - currently - necessary for things like a countdown and a manual slider that is automated as well (personal examples). But I try to only use it for added functionality, not as an integral part of the layout (and then I prefer to write it myself; I also like programming). Never tried "masonry" though.

[@pascalmaranus]

That definitely depends on the types of websites you're making. For anything as simple as a contact form, I'd say it feels very clunky in 2024 to have a page refresh after submitting the form. So using JS to update it within the page feels better to me. That said, not everyone will have a need for it. I think a lot of people would love to use it - even if just occasionally. It is a type of layout that would be different, so those that have use for it, should be able to get it done. If you don't need it, nobody's forcing you to use it. For example: one client of mine is a tattoo artist. He's not a photographer, but of course he does take pictures of his work, when he's finished. On his website, he'll post some of them. But a big back or chest piece will have a different shape than something like a forearm or a leg. And if I'd force him to 16:9 images, some work would look a lot smaller than others, because they wouldn't fit the shape well. It would be a shame to have his best work to go unnoticed, just because it didn't fit within the allotted space. Personally, I'm also a photographer. Some images work better in 2:3, others in 4:5, plus there's also the difference between landscape and portrait images. Now, I've found ways to work around it. But there's just some cases where not everything fits within the same shape. You're not going to do separate pages for 2:3 and 4:5 images, for example.

[@graysonpeddie]

@@pascalmaranus Thanks, but for my usecase, Mine's just a blog that only uses HTML, CSS, and PHP for dynamic site generation. No MySQL used. So yeah I would go so far as to pretend that JavaScript does not exist, because if there's a will, there's a way. And the last thing I want is to use JavaScript as the last resort. :) Non-JavaScript web development is my hobby and my passion.

[@henrikschmidt8178]

To me this is flexbox and grid had a baby. if flexbox just did not keep each element in a row with the same height it would produce the needed result with just flex-direction: rox and wrap enabled. on the other hand it would be able to be solved in a normal grid system if rows where locked to a small value and then have the grid span of each block be calculated by the item size. then you "already" can get this effect. only thing was I could never get the span to use a calc result.

[@tebogoseshibe4518]

Personally, I lean more towards it being a part of grid, rather than it being a display type. Regarding the wording, "cascade" would work well, I think. 1) It's already a commonly known word, given the language. 2) It reasonably describes what the content does within the rows. 3) Works semantically if you plan on having the direction to be horizontal. i.e. grid-template-rows: cascade; grid-template-columns: cascade;

[@basilenordmann7356]

Okay, reasonably, it is a grid without rows. But in the look researched, it doesn't look like a grid. If it allows for more performances, I am for giving it his own display (better for the long run, especially now with new 3D techs like virtual reality, that are going to consume more and more resources). But to mitigate the mistakes, why not call it display: masonry-grid and give it the same attributes as grid (mitigating the invalids in the case of a masonry)? I think it can be somewhat intuitive to learn "masonry-grid" after "grid" for beginners. Thoughts?

[@JS-ow2ct]

The favorite pick in the issue about the name is currently `grid-template-rows: collapse`

[@CarlosAraya25]

How much harder would it make adding masonry to grid make grid to learn for beginners. Grid is very complex as it is and adding yet more syntax to learn would make it even more complicated and hard to parse

[@cervantesroger]

honestly i think having it outside of grid makes sense since most of its capabilities would not be used, and some of the properties might lose its purpose... even it it was "grid-template-rows: no rows" or something like that...could you tell a child its grid-row-start? Doesn't make sense! It should be its own display. masonry? waterfall? i would say inline-grid or mason-grid or something like that so that the rest of the useful properties that can actually be used could keep the grid naming and it makes it easier for everyone (no masonry-template-columns, please!!!) its either that or keep it inside grid and use grid-template-rows: off/omit/ignore so that it is clear that the row properties are unusable

[@planetWayne]

Being a complete outsider to modern css, (and trying to catch up watching your content) the one this that sprung to mind about the name, why not… Grid-template-rows: flex Are they not after all flexible??

[@acegear]

feels like bento grid x100 and randomized, i would call it grid-masonry , its either you code it as display: grid-masonry or grid-template-grid-masonry

[@iamtharunraj]

I have seen this kind of layout on Frontend Mentor. I have always wondered how they made that

[@claudschgi4794]

i would call it: display: maze; (four letters like grid, or flex, looks like a Maze when we do Masonrys ^^

[@lougarcia36]

what about: .container { display: flex; flex-wrap: wrap | wrap-reverse; justify-content: waterfall; } - will only work when flex-wrap is either "wrap" or "wrap-reverse"

[@lougarcia36]

one issue i can see is that you can only have equal-sized columns. Since there are no "columns" in flexbox, you can't do something like: .container .item { column-span: 2 }

[@lougarcia36]

I was reading through that css mistakes page and found this line: - The flex shorthand (and flex-shrink and flex-grow longhands) should accept fr units instead of bare numbers to represent flex fractions. maybe adding "fr" units will solve this column issue.

[@XerosXIII]

3rd-party masonry librarian: "uh oh"

[@gr81matt]

It should be called Masonry and be part of the Grid spec. :) But if it absolutely needs to be something else, maybe "grid-template-rows: collapse;"

[@euroger123]

I'm gonna be polemic, but... I think masonry should live inside flex... Think about it: If you have different fixed widths that wrap into multiple rows than the masonry layout would look exactly like that but just rotated 90deg. It might be nonsense but it made sense when I wrote hahah

[@KayinAngel]

"people use it" but should they be? i question if people are wanting it but should be using something else instead (just columns). like, i can't see many use cases for the content flow to be set up in rows, but still require a "masonry/waterfall" like stacking. An image gallery like the example, which would also work as just columns (because who cares the image orders). however, the subgrid part is what makes the most sense to me. i just want to be able to define the flow of the content > row vs column > and have wrap behave as expected.

[@matthewmullin6042]

The only issue I see coming up often for beginners, would be the column-templates needing to be the same width in masonry layouts, but not in grid. I'm guessing all the columns need to be the same width, because if they varied it would be impossible to determine all the children's heights and therefore couldn't be reorganized into a masonry order, but the small limitation would cause a lot of headaches and "why doesn't this work" from beginners.

[@peterholzer4481]

grid-template-rows: wonky Because the cells are still laid out horizontally (= in rows), the rows are just really irregular. ½😉

[@euroger123]

Here's why I think grid-template-rows: off is a BAD IDEA. My first intuition with putting masonry inside CSS Grid was to use gap,column-gap and row-gap... If we say that the rows are OFF that means that row-gap wouldn't apply, but I would expect gap-row to define the horizontal spacement between items. I'm not sure about the best approach would be, but I think this one is definitely not great.

[@stainomatic]

I like "Masonary". People saying it's not brick don't get that brick is one type of many "Masonary" techniques.

[@warkentien2]

I'd prefer grid-template-rows: start (or flex-start) over "off"

[@ss4717]

Bro why are you in my brain.... lol been using grid for this...

[@onkelhoy1]

Without watching the video, I would just have a flex of flexes and let the image ratio themselves do that, this would allow me to have some control by choosing which image is where.. but if this should be in a nice way where we only want to have images then I would have to think more. I’m curious

[@SeanCassiere]

Sir Powell has spoken! Masonry for all!!!

[@SiteStudio]

It should be called "staggered" or "offset." If you've ever had tiles of flooring installed in your home, you've heard these terms used to describe the so-called "masonry" pattern.

[@DaweSlayer]

.future-flexible-layout { display: combined; layout: grid flex; /*shortcut vertical-masonry*/ template: evenly 5, flow; /*just some cols-rows combined settings*/ } Basically beign able to set vertical and horizontal behavior of different types and combine functionality is the best what we should go for after we figure out how to do it with how it's now. And u do it by just having this and translate flex to flex flex, grid to grid grid so not even code heavy transition.

[@itsPenguinBoy]

I don't like "off" - we don't have that anywhere else. And to have a negation which is not a default feels grammatically "off". The closest thing we have is "nowrap" which is at least clear in what it does, so if it is going to be a negation I'd go for... grid-template-rows: no-rows; However I would prefer a word that is more of a verb... Like I really like values like "fill" "cover" "stretch" "shrink"... So how about grid-template-rows: flow; Fewer letters than waterfall but with some of the end imagery, and has basis in existing language around layout.

[@RobertMcGovernTarasis]

WebKit team? ❤ they get some love

[@keithmosley8843]

"grid-template-rows: off" or any other 'last' word, I think someone suggested omit, doesn't work for me since it doesn't indicate the result. Someone reading a piece of CSS will not understand what is going on. And in any documentation, the words 'masonry' or 'waterfall' will either be needed to be used to describe the result or act as a starting point for any search for the controls needed to produce the result. So I believe it iwould be far better to use the word itself. My preference would be masonry. But the working group might choose the term to be used so it becomes normalised

[@RougeEric]

grid-template-rows: auto-height;