What would you call this layout?
VloĆŸit
- Äas pĆidĂĄn 19. 05. 2024
- Read the full artcile here đ webkit.org/blog/15269/help-us... and Chrome has put out an alternate proposal I didn't mention in the video, which has the opposite point of view: developer.chrome.com/blog/mas...
đ Links
â The full article: webkit.org/blog/15269/help-us...
The alternate proposal by the Chrome team: developer.chrome.com/blog/mas...
â The CSS Working Group discussion: github.com/w3c/csswg-drafts/i...
â The list of CSS mistakes: wiki.csswg.org/ideas/mistakes
â Timestamps
00:00 - Introduction
00:35 - They want our help!
01:35 - What do we mean by masonry?
03:32 - The questions that need answering
06:02 - The current spec
09:06 - Should it be a part of grid or a new display value?
16:14 - What they want from us
18:16 - What should it be called?
#css
--
Come hang out with other dev's in my Discord Community
đŹ / discord
Keep up to date with everything I'm up to
â www.kevinpowell.co/newsletter
Come hang out with me live every Monday on Twitch!
đș / kevinpowellcss
---
Help support my channel
đšâđ Get a course: www.kevinpowell.co/courses
đ Buy a shirt: teespring.com/stores/making-t...
đ Support me on Patreon: / kevinpowell
---
My editor: VS Code - code.visualstudio.com/
---
I'm on some other places on the internet too!
If you'd like a behind the scenes and previews of what's coming up on my CZcams channel, make sure to follow me on Instagram and Twitter.
Twitter: / kevinjpowell
Codepen: codepen.io/kevinpowell/
Github: github.com/kevin-powell
---
And whatever you do, don't forget to keep on making your corner of the internet just a little bit more awesome!
+1 for `display: grid, grid-template-rows: masonry`
+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.
it shouldn't be a grid but another display property
I love "rows:off;" because then we can make this work horizontally with "columns:off;"
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.
And if both are off đŹ.
â@@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.
@@rujor it would just fill in content diagonally đ€Ż
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
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 đ
Just like inline-block
@@pepkin88 you absolutely understand my vision
Well then, you could have both flexgrid and gridflex to make everything so much easier to learn... Help!
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!
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.
Also, 'waterfall' is still 2D, Grid is 2D. Flexbox is 1D. It's a columnar but not modular grid.
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.
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.
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.
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
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 CZcams 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.
Dynamic or uneven grid sounds like a better name to me! Masonry or waterfall are creative but not really descriptive 2:10
I love this idea! Simple terms often are the best
@@Colnup I'm a firm believer that simplicity is the ultimate goal in programming :)
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.
Well as Kevin pointed out, that's really just "modern masonry" right? Older/ancient masonry (the stone wall Kevin shows, for example) aren't just offset horizontally. Personally, I'd want a CSS masonry layout to support both horizontal and/or vertical offset in the same layout. Perhaps that's why it's hard to define.
I like to call it, "adaptive masonry."
@@marklnzThat refers to tiles of equal dimensions. OP is referring to the aligned axis. A different thing.
Masonry is not just stacking bricks.
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.
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
@@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 ;)
@@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
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
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.
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.
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!
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.
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.
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`
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.
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.
*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đŹ ).
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.
I would 100% support having this as an extension of Grid and I would suggest grid-template-rows: dynamic
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.
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.
"vertical masonry", and save thought for "horizontal" and maybe "best-fit" for a less rigid bento layout
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?
â@@denoww9261 Usage of "block" & "inline" can definitely be applied
display: bento;
For me it also makes sense to have it within grid. My suggestion would be "grid-template-rows: omit"
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;
Bento fits in the current grid. Nothing to do with masonry.
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)
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.
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 }
Masonry is very descriptive. Works for me
3rd-party masonry librarian: "uh oh"
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.
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.
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 was shocked by template-rows: off and then I was like ⊠DAMN! That is smart
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.
The favorite pick in the issue about the name is currently `grid-template-rows: collapse`
I would totally use masonry on my website!
Hot take: "grid-template-rows: flex"
Just in time when i am building a gallery app and need that knowledge. Thanks Kevin!
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
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â
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.
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.
Iâd propose grid-template-rows: collapse;
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 guess it would still have rows, in that the row gap would still apply. So maybe something like grid-template-rows: separate
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.
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.
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"?
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.
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;"
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??
Bro why are you in my brain.... lol been using grid for this...
i would call it: display: maze; (four letters like grid, or flex, looks like a Maze when we do Masonrys ^^
I have seen this kind of layout on Frontend Mentor. I have always wondered how they made that
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 đ
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
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)
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.
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
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.)
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.
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
Sir Powell has spoken! Masonry for all!!!
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;
On the lines of 'masonry', a 'stone-wall' layout is fitting.
Hey Kevin, any plans to cover View Transitions on your channel?
Grid-template-rows:flow;
Just to throw another hat in the ring
grid-template-rows: wonky
Because the cells are still laid out horizontally (= in rows), the rows are just really irregular.
Âœđ
WebKit team? †they get some love
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 like "Masonary". People saying it's not brick don't get that brick is one type of many "Masonary" techniques.
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.
I don't understand why the whole discussion is vertical when we most encounter this as horizontal masonry
.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.
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"
How about something like grid autotiles flow vertical/horisontal/circular/spiral/zigzag ?
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?
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.
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.
flex-flow is just a combination of flex-direction and flex-wrap. Grid already has grid-auto-flow that handles its direction.
What about
grid-template-rows: auto-fill; ?
How about grid-template-rows: stagger?
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?
Row and column based masonry layouts.
Columns without defined rows and rows without define columns. Seems intuitive enough.
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.
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.
Flex-direction column!đ
Edit:
...in a grid with n columns and just 1 row, of course...!
"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
Display: grid, template rows: off
"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.
grid-template-rows: auto-height;
I'd name it "grid-template-rows: dynamic".
Staggered Grid