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

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

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 😊

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.

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.

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.

I would call it display:stacks

Here's my issue with referring to it as a masonry layout. Masonry typically stacks bricks on top of each other with the sizing offset being horizontal. What is sometimes referred to as a "horizontal masonry" gallery, I think should just be "masonry" gallery. "Waterfall" fits the vertical layout much better, imo.

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.

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

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 KZfaq 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.

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!

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`

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.

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.

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!

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

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.

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.

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

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.

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.

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

I would totally use masonry on my website!

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.

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.

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.

Masonry is very descriptive. Works for me

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

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

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

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.

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.

*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😬 ).

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"?

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;

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 }

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!

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.

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

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.

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.

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)

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??

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.

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’

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.

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

I’d propose grid-template-rows: collapse;

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 ?

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.

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

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

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

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?

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.

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

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

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.

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 😊

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.

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

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

what about grid-template-rows: none; ?

Sir Powell has spoken! Masonry for all!!!

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.)

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)

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

Just in time when i am building a gallery app and need that knowledge. Thanks Kevin!

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

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

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;"

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?

Maybe I'm missing something but I don't really get why this is an issue. You can achieve this payout with a dozen or so lines of CSS. Lazy loading through the HTML attribute loads images based on whether they are in the viewport (or proximate to the viewport) rather than their position in the HTML. So the only issue I can see is that images are allocated vertically rather than horizontally. But this is a fundamentally vertical layout. If you want images to appear in a set horizonal order I'm not sure why you're using this layout in the first place. Would it be cool if that was an option? Sure. More options are always better. But with a horizontal layout your images are going to get out of order to some degree because of the varying aspect ration of the images. So if order is critical use a different layout. I might be missing something but it seems like people are over thinking it. This is columnar layout. Not a grid layout. There are no rows. And even if there were each column would invariably end up with a different number of rows. Rendering them not rows at all. Because they aren't rows. And if you've only got columns and no rows you don't have a grid. Some people refer to this as a "stacked" layout which I think is more accurate. But that name is itself an acknowledgment that you are stacking content but creating some sort of grid. So why not just extend the capability of the columns property to allow for horizontal allocation of content? I know people use JavaScript for more complex lazy loading behaviours, but again, why not just add those behaviours to an HTML attribute? And while we're at it why not make it so lazy-loading attributes can be assigned at a container level instead of having to have it on every image? But again, maybe I'm missing something.

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.

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 🫠

3rd-party masonry librarian: "uh oh"

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;

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

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

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

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

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.

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

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

"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

"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.

How about grid-template-rows: stagger?

grid-template-rows: auto-height;

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

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.

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

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

masonry. a) waterfall makes not much sense. but also b) really because masonry has been a javascript library for a long time, to achieve exactly this. i find it okay to call it masonry, just like i "google" for things.

WebKit team? ❤ they get some love

Grid-template-rows:flow; Just to throw another hat in the ring

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.

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.

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"

I'd name it "grid-template-rows: dynamic".