[css-grid-3] Designer/developer feedback on masonry layout #10233
Comments
|
I used the Masonry jQuery plugin back in the day for a few things, and I've missed it in a number of places since then. I've even built similar systems with JavaScript and CSS Grid, by defining absurd numbers of rows and dynamically calculating a row span for each item, which allowed me to do some of the neat column-spanning and column-picking seen in Jen's examples. Extending CSS Grid with "masonry rows" seems like a great idea to me, and the right place for it. That would allow us web devs to grow our existing knowledge as the possibilities grow, and to leverage our existing code and understanding as we do so. We've already seen how flexbox and grid are (wrongly) viewed as competitors; adding yet another fundamental layout would just confuse things more. Empowering the layouts we have is the better option. |
|
I agree that masonry is a type of grid and should be implemented as such. |
|
I think masonry (or whatever it ends up being called) should be a part of CSS Grid, for a few reasons:
~ Side note: One thing we've discovered over the past 10 years has been the importance of being able to intuitively predict how a masonry grid will re-flow when content is added to or rearranged within it. Let’s say you have a Pinterest-style image grid, and you load in an additional 50 items... if all the existing items suddenly jump around and switch columns etc that gets really disorienting for users. Same goes for making an element span multiple columns... you don’t expect that to suddenly rearrange the entire grid, simply the content below that element (like upside-down Tetris). I’m hopeful CSS grid’s ability to specify a column position will help with this, which is another reason to build on the existing Grid spec. |
|
Key thoughts on this proposal:
Minor nits on the demo at https://webkit.org/demos/grid3//photos/ :
|
|
I've worked with CSS for what, twenty years, and been a web dev since 1995. Yes, we want this. Masonry layout would solve so many problems for my art and photography websites. Even today I had to fire up Gimp to resize photos for different aspect ratios. |
|
I see Jen's promotion of this in my Fedi feed, and I just tried some of her demos, especially the photos demo. I guess my concern is not particularly with 'Masonry' but with the 'modern' trend toward web pages designed for huge screens. I have two main routes (limited by lousy vision). The smallest iPhone, where after a confusing delay the photos demo reverted to a vertical scroll of single images (that didn't seem connected to the grid images I'd been able to see). And a 1920x1080 Linux view where what's left of the browser window after headers and toolbars took about a minute to fill up with one-third of the full example - many images a half-inch across. Scrolling to the other 2/3 happened painfully slowly, with the image grid filling in random order. Maybe I missed it, but is there any 'Responsive' technology being discussed to make these new web features work for people who don't have the huge screen area to take advantage of them? Or for people dependent on Alt text? WAVE shows no Alt text at all in the demo. And if there was, a grid of 51 images would be a bit much to navigate... In that vein, WAVE finds no headings! "Headings ... provide important document structure, outlines, and navigation functionality to assistive technology users." There really needs to be some rational structure within the page for those of us who can't just glance at the whole wall of images at once! If someone knows a better place to post this issue, please suggest! |
|
@DanielHeath Is that why my view loaded so slowly? Granted I'm at the far end of 30 miles of WISP radio, but my 10 Mb usually loads web pages in milliseconds, not minutes. |
|
Anyone who's been a part of the dev community long enough and who has been talking and listening to designers and developers in the community knows that we do want masonry layout. We may not all be working on "big websites", but we are the ones building the Web. I cast an additional vote to including masonry as part of the CSS Grid layout system, not a separate I have been waiting for this layout for to become possible in CSS for years. And it only makes sense that we get enough control over it like we would with other layouts. I believe one of the reasons CSS Columns are not as widely used as one would hope is because they are limited and not flexible. We do want control over column widths. And it only makes sense that Grid Level 3 be able to leverage all the capabilities of Grid Level 1 and Level 2. Thank you Jen and the Webkit team for pushing to make this feature actually usable. UPDATE: I've read Rachel Andrew's post which explains the alternative proposal for Masonry. I think this post was a much-needed clarification. Seeing that both proposals would give us the flexibility to design and implement the layouts in Jen's post, I no longer have a strong preference as to which property or spec Masonry goes into. As a developer, I want the flexibility to build creatively. Whichever way we get to do that will be welcome. I appreciate everyone involved in this discussion and who is working to push this feature forward. |
|
Masonry, however implemented, should exist. Photo albums would be a use case I would put this too. Non-symetric would be nice to have because of a mix of aspect ratio. |
|
We recently implemented a masonry grid as part of our website's dashboard, which held a list of infinite-scrolling cards, and we opted to use CSS Grid for it because we wanted control over the columns (using In general, it would also be much easier to progressively enhance too in grid. Just add a |
|
While I already agree with everything mentioned, just adding my own thoughts below: I've recently shipped a project that could have made great use of masonry layout for a "mega menu". We ended up using standard multicol to get a similar behaviour, but each group has to be manually placed to optimise how much space they take (some have 2 sub-items, other have 8), so it ends up being tedious to place all the pieces. Masonry would make that very easy and solve common layout problems on many projects. As far as the Regarding the naming, the obvious alternative is
Finally to piggyback on @DanielHeath's comments:
I am wondering about this too. While I wouldn't need it as much, I'd definitely like that flexibility. And a nitpick of my own:
Not only the lack of width/height (which, ironically, I now consistently do because of Jen's push on that some years ago 😄) but also the 1MB+ PNGs in the article can easily be optimised. TL;DR: Overall, feeling very positive about all of this! |
As part of CSS yes, but I am more agnostic about whether it should be part of grid vs. a different display mode. It seems to me the main pro for being part of grid would be that the fallback behavior would be more reasonable.
The article only discusses (and shows demos of) a column-based / vertical orientation. However, the feature should also support row-based / horizontal orientation for a use case like the Flickr gallery layout: 
Even if not supported initially, the syntax should be designed with this future possibility in mind, so
EDIT It was pointed out by @rileybathurst in a comment below that the demo includes two Horizontal options: Horizontal Masonry and Horizontal Flexbox. 
However there are nuances to the Flickr version that differ from both of these:
The big difference with the Flickr masonry is that the heights of the rows are dynamic based on the aspect ratios of the bricks in each row. The CSS masonry should also support this option to have dynamic row height (in the case of Flickr) or dynamic column width (in the case of the column-based support described in the blog post) based on the aspect ratios of the contents, so that the ends of the rows/columns are flush with the right/bottom sides of the container, respectively, and the clipping of brick contents is avoided. |
|
I think keeping everything part of grid would be simplest in terms of use with other properties. |
|
Hi 👋 Thanks for the opportunity to share some thoughts - I really liked the article and it comes at a fantastic time as we are doing redesigns of our website. This has been inspirational!
Yes.
Variable column sizes would be preferable. These allow for wider range of design options, and I would expect it to not be an uncommon design pattern. The use of subgrid would also be a fantastic capability that I would prefer to see included.
We offer users a way to curate (research) works and are looking to provide them with a visually appealing, dynamic, and scalable way to present the curated content. We want to provide them with an option to present their curated works in magazine/print quality layouts, without having to put in much work to do so. The columnar grid would be perfect for this.
I also wondered about horizontal options, similar to a previous comment raised. I can imagine this also to be an interesting design element if at all possible. I have not previously contributed to a W3C discussion, so if I missed anything in how to contribute, I am happy to expand further upon request 😊 |
|
I prefer this being part of CSS Grid too. If all the columns are intended to be the same width, it makes this feature feel very similar to the If this was to be implemented as a new display style where all the columns were the same width, it should also support the use of the In any case, if it doesn't end up being implemented as part of Grid, you can expect that authors will often embed grids inside each element to align captions, etc., which seems inherently more work for the UA to handle than a single shared base grid accessed through subgrid. Some usage scenarios that would benefit me:
|
|
Hi! Author of the Masonry JS library here 👋 . I am stoked to see Jen and the WebKit team prioritize making Masonry a first-class citizen in the browser. My heart-felt gratitude ❤️ Custom track sizing vs uniform column widthIn my experience, the vast majority of users want uniform column width. CSS grids provide so much power over layout with track sizing. I think that amount of customization over the tracks is an unwanted feature when working with masonry layouts. Typically with a masonry layout, you want the item to have the same size regardless of its position in the grid. So, if you want to be practical, go with "display: masonry" vs "grid-template-rows: masonry"Having said that, Follow-up issuesHere are some issues that I know will come up. I don't think they need to be solved in this spec/implementation. But they are worth thinking about during this concepting phase. Loading imagesDay 2 issue for implementing a Masonry layout is dealing with shifting layout caused by loading images. With a masonry layout, the problem is exacerbated as taller cell element causes subsequent cells elements to move to a different column. The issue is best address by setting Expanding cells and maintaining position@chrisarmstrong mentions above:
The classic Masonry layout will shift a newly expanded cell element to the next possible position masonry.resize.movBut users just want the item to open up where they clicked it. I actually had to build a separate layout library, Packery, with a bin packing algorithm to solve for it packery.fit.movMaybe something like Keeping horizontal order with a masonry layoutA good amount of people requested that Masonry have more leeway in its layout algorithm so that horizontal order could be maintained. I eventually added a
Thrilled to see this work. I'll be following this thread merrily. |
|
Yes. Seems like the logical progression of CSS grid. Something that shouldn't be done with JavaScript anymore. |
|
Hi all, while reading the article, I thought about the possibility of having the masonry as a new This would perhaps ease the mental model for developers and designers, and perhaps simplify the browser implementations, since it will not automatically (and possibly incorrectly) force every grid feature to work with the proposed masonry mode. Instead, the masonry could grow its own vocabulary free of other grid features. But on the other side, the new display type would just work™ with the most relevant parts of the grid layout (e.g. fine control over columns, gap). I personally have no strong preference/opinions on either way. Masonry in any form would be a leap forward. Also, I think the spec should warn us of possible accessibility pitfalls, like:
Thanks! 💛 p.s. Just found a much better explanation to the idea of "segregation with some interoperability" here (from @rachelandrew): #9733 (comment) |
|
I recently came across a use-case at work where we want a 2-column layout on desktop, and a single column on mobile. But we want the top item of the right column to be "in the middle" of the single column, and the bottom item of the right column to be at the bottom of the single column like so:
Currently as far as I know there is no way to achieve this in CSS, but with masonry grid it is quite simple to achieve, as shown in this codepen: https://codepen.io/dougalg/pen/GRLPZea The benefits of grid here are ability to pull items naturally into different columns following the standard grid syntax, and doing so allows to maintain tab order easily to achieve the desired flow both on mobile and desktop. |
|
Lots of devs seem to find CSS Grid difficult to understand and use. They'd love a super easy way to do Masonry, like this: main {
display: masonry;
columns: 28ch;
}But this other way, with all the brackets and stuff, is almost as scary as CSS Grid syntax itself, so I wouldn't go for it: main {
display: masonry;
masonry-columns: repeat(5, minmax(28ch, 1fr));
/* where only one repeating width is allowed */
}However we will eventually need those extra syntax for more controls, so... For the reasons Jen mentioned, I'm all for adding masonry to CSS Grid layout. |
|
@desandro That's a great point RE horizontal order - eg item 11 in the mega-menu demo being positioned to the right of item 12 is correct, but looks totally wrong (see screenshot). 
|
|
I think masonry should have its own
|
|
Please, mayby create an questionnaire like with nesting, to gather more votes on the matter. |
I believe both could be made to work, eg: I think it should be |
|
I know there was no mention of column masonry layouts, I'm just wondering "why not". I'm all for This could be a messy layout as follows: 
Or should this be an error condition? If this shouldn't be allowed, it would be a slight problem for me, because it seems to break the line independence of css. Now by adding line 3, you've effectively broken the way line 2 should work. So this case would need to lead to a reasonable layout.
Also, how do I specify the layout direction, because this would also be a valid way to lay out the exact same boxes: 
Then we have problems of "how we should align them" or how they should be reflowed to fill the available space. But these are all initial issues that I'm running into when imagining this. |
|
I've spent some time thinking about this before commenting because I think there are good arguments to be had from both sides (adding it to Grid vs.
edit: sorry this ended up being a lot longer than intended! Where I'm coming fromI've seen some people pointing to potential performance issues based on repaints and layout shifts, and other things on the technical side of how it will be implemented. I'm simply coming in on this from a "in an ideal world, this is how I would like to use it, and how I think, from my experience helping people learn CSS, will be the easiest for them to pick up." We do need this
It should be a part of the CSS Grid specI feel like it should be a part of the Grid spec, rather than creating a new display type. "Most uses cases" shouldn't be good enoughSeveral people have pointed out that If we close off some doors because this other method covers most use cases it seems like a missed opportunity to me (subgrid being a big one for me, as I don't see how it could be compatible in any way if we break it into its own display type). CaveatOne thing I haven't understood is why a My main worry is, we don't know what people are going to do with this, but people will do things with it that we can't anticipate. The more feature rich it is, the more creative people will be with it. We haven't seen layouts that take advantage of these all of thse things because we don't really have a way to create them now, even with the existing JS solutions. Those often limit you to even columns, and there is no way to have things like subgrid or other grid features we have now. It fits well with common uses of gridThis new proposal is almost an in-between between flexbox and grid, so I do understand the argument for having a different display value, but from what I see, a large majority of grid layouts don't define rows to begin with. Instead they rely on the implicit creation of them while explicitly defining the columns. To be able to toggle between the implicit rows we have now to a masonry style layout with a It's (potentially) easier to learnAs someone who spends most of my time teaching CSS, I feel that it's a lot easier to introduce the layout as a small addition to Grid rather than to have to jump into a new display type, even if there are many similarities. I realize that there will potentially be more to it all than simply toggling our rows on and off, but like a In my experience of helping people learn CSS and seeing how they progress through it, this feels like the easiest way for a learner. You learn how to define columns and rows then simply how "let the rows do their own thing" becomes a natural progression, rather than an "alright, now take everything we've learned, and we're going to bring it to this other display type". This isn't a big deal by any means, but imo, the less friction when learning something, the better. From there, it definitely has the potential to get more complicated, but that doesn't matter which syntax or display type we go with, at one point, if you want to get past the basics of how something works, you need to learn more about it. While there might be some values that might only be available after changing the behavior of our rows ( To me, with There would be confusion on why certain things work in grid columns and not masonry columns as well, even if they have different display types. People see all of these as "layouts", and when it comes to setting up columns and placing things in those columns, the same questions and confusion will happen either way. Sidenote on
|
|
I'd like to extend my comment above with a couple of additional points.
|
|
Part of the Grid spec seems reasonable, can we have this now please, I've literally been waiting years. |
Yes.
I also wrote about this in my blog: https://medium.com/@ebisucom/css-grid-and-masonry-layout-24a5dff6ba8e |
|
I'd say Masonry should be its own display property. Step back from being a dev for a moment, in layman's terms. A grid would denote order, one knows where and how everything goes or should go beforehand. As an implementer, having masonry be its own display property will help deal with specific edge cases. |
|
I really like the approach you described and have wondered for a while why masonry/collapse was not a part of CSS Grid. The only question I had was the one mentioned by @saivan regarding the expected outcome of setting both columns and rows to masonry. I still think the approach you've described makes sense, I'm just curious what should happen in this instance. Sorry if someone already answered this. I've not yet had the chance to read this entire thread! |
|
I prefer the but regarding note: |
|
what about something like i know it can't be small opinion: i hate the problems with cascade in css when it fires in my face so please no |
|
I'm all for having this part of the grid spec. I would recommend simplicity over the friction of adding a new display type or even language that is not consistently used across regions (eg: masonry vs waterfall). I would go further to recommend simplifying the feature by using Again simplicity/less friction in usage for the user seems key and having a single option to implement this as a layout option, while retaining the full power of grid and subgrid as part of the capability without adding more or divergent syntax seems like a massive win for the web developer. |
|
Front end develop here. I'd love to have an option for masonry within grid as described in the examples - especially as it seems to naturally fall within the realm of grid (really only changing one property vs having to implement a full new functionality for Would there ever be a time where the mixed tab order of items would disrupt accessibility? |
|
Honestly?... I think these details are trivial. 1. Is there any use case in which the names of CSS properties impacts the end user experience?No. This isn't like HTML5 where proper elements / aria's are required for screen readers to function properly. These "semantics" are only relevant for the developer experience. Consequently in this article, the following argument holds zero weight in my mind.
Ok sure let's go with the "Akshually it's a different concept"... so what? If we're going to argue about things being be conceptually reasoned, we have bigger problems... Coercion is still a part of JS 😑 Try explaining how some of the following examples are consistent from the simplest lexical concepts to a new coder, or even a seasoned coder who has never seen JS: https://github.com/denysdovhan/wtfjs The point is conceptuality can serve as a good guidepost but as demonstrated it is not necessarily binding, and once whatever the thing in question is learned, it just becomes semantic anyway. 2. Is there any use case in which the semantics of this CSS impacts the dev experience?Given both options are being presented ( That being true, we already know that no matter how ratchet a bit of code looks, if it gets the job done with great performance and no side effects, of course we're gonna use it. In fact there's also an argument to be made, the more "hacky" a solution seems, provided it's not too verbose, the more enjoyable it is to learn/use as a dev. To the point where we fondly give them their own names: clearfix, OneDiv, IIFE's, Fast Inverse Squirt (Quake 3), etc. 3. Is there any use case in which the semantics of this CSS impacts the browser vendors?Possibly? The article has the following:
If i'm understanding correctly it means tying the details together in the spec necessarily ties the implementation together in browser engines, thus ensuring feature parity between both types of grid. Also i find it curious it's prefaced with this:
Extend... to what? Unless we're adding a Z dimension of depth for augmented reality or something? And in such a case those changes would necessitate the change of display type property for things other then masonry and grid anyway? Direct answers
Unanswerable by anyone not familiar CSS layout engines. My general view is, whatever's better for performance, if they're equivalent then whatever's easier to implement / maintain. Throwing the question out to the internet, i'm reminded of the following quote (that was perverted by managers): The customer is always right... in matters of taste. Every dev is going to have their own take on the matter. Sure you might get some consensus islands happening, but ultimately it's going to be impossible to please everyone.
If there's no other "penalties", more flexibility is much more betterer.
I think this question is a little obvious 😑 Just think of where you've seen masonry layouts. Image gallery's (pinterest), traditional newspaper column layouts, etc. Though there is one possibility i'd like to consider. Rendering a masonry grid takes quite a bit of calculation, it could be interesting if some of those internal functions were exposed via |
|
Hello, UI Designer / Front end dev here. I've already had this type of layout several time and it always was a nightmare / so ugly to solve using only current css properties, masonry would be such a useful property to have. Here's are recent examples of this layout for my company's website :
I vote to make it part of I agree |
|
First, thank you WebKit team for addressing this, and writing such a detailed blog post.
It should be part of CSS GridTo keep it short, I'll just say I agree with what those have already made a defense for masonry being part of CSS Grid. It makes the most sense to me and would offer the most functionality in a logical way. I would also like to second @desandro's thoughts on the naming. Although "masonry" makes sense to me, I know it's an odd word that many do not understand, so
I already use it in production…with I recently worked on a project for a church youth retreat. In this project, I included account pages so registrants could view and edit information after registering. Due to the nature of different inputs requiring more space than others, the masonry layout makes this section look a lot cleaner and easier to navigate. This first picture is what most people will see, since the masonry feature flag has to be enabled. This is what you would expect by not setting 
When I turn on the masonry feature flag, we get this consistent layout that collapses the checkmark/xmark fields to fit cleanly next to the address field. It's a small detail, but it goes a long way in making the data easy to navigate. 
I'm sure you all know, I could have used two separate grids and divided the fields between them to create the two columns, but it would have taken a lot of extra work making the order of the fields flow correctly and keep relevant information together. Unlike using the masonry layout for displaying a photo gallery, displaying form info requires the grouping of relevant information, or you'll end up with a terribly confusing user interface and a frustrating user experience.
|
|
I am creating a dashboard of widgets and cards and was looking for the perfect display option. After fiddling with grid for a couple hours, and being unsatisfied with the extra spacing between sections created when they weren't all the same aspect ratio in a row or column, I settled on flex-wrap. I am ecstatic to have found this article linked by fridayfrontend which perfectly described what I was looking for. I see masonry as a natural progression for CSS grid. |
|
This is 'grid paper' Q: Can somebody design a masonry layout using it? So, this should be a part of css-grid. |
|
It is similar to both flexbox and grid, and we could make several comparisons to both, but it appears to me to be a hybrid of both and lack features of both. It has columns but no rows. Or it has rows and no columns. |
|
Would it be fair to say that the arguments so far fall into roughly two camps?
If so, then perhaps the question is: which of these approaches is more consistent with the principles of how the rest of CSS has been architected? Should declarations be based more on what a thing does, or how it does it? |
|
@dougalg-js-tw #10233 (comment)
You can easily achieve it with CSS using |
|
Hi, I was directed here from this article. My opinion is that it makes sense from a functionality perspective to consider this to be |
|
NOTE: I have no hands-on experince with this yet, I didn't realise browsers had implemented anything relating to it yet. I will go play around with it soon, which may change some of my opinions.
After having read both the webkit post and the chromium post I believe that making it a seperate display method is the way to go. I still believe we will want to port, or have a method to share, many of the improvements made to grid however.
To me, calling one where all columns are the same size a "masonry layout" does not sit right, but is absolutely desired. At lesat the way I think about it: Masonry items are slotted where they best fit, row or column. No size or number of rows/columns is determined, and items can be scaled to fit best within the layout. Waterfall: a set number of rows OR columns is determined, and items are placed within them to the best fit possible. Items can be scaled to fit better. I would be fine with using one term to contain both, in which case it should be masonry (rationale: masonry can include both, waterfall is more specific so it cant). I would like to see support for both layout types. Examples of sites that use what I described as "masonry" are DeviantArt and Steam (community art submissions mostly). Examples of what I classified as a waterfall layout are numorus. I know that short and simple names are often prefered, and for good reason. I also understand that
I would absolutely use this. I deal a lot with images (concept art, showcases, etc) and illustrations (icons, etc, vector art basically) and its annoying to need to specify grid-row- and grid-column- spans to get things looking about right. This would save me a ton of trouble. Having this be a thing offically would encourage me to use it more aswell, such as to lay out text snippets next to each other more easily.
What I mentioned above as masonry layouts, for which you can't really determine a column/row size. EDIT: Changed the masonry image to one that better shows my idea. |
|
sWhat a ride this discussion is; so many interesting thoughts. A few points to note before I braindump: I'm the author of gridless.design and have spent a great deal of time thinking about grids in general. Ironically, there is a masonry-like layout on my personal site; it uses the CSS column layout as I don't care much about the order, only the presentation. I've also read the blog post by Rachel Andrew regarding the alternative direction. What I'll say is that I know from the decades of web design trends, I know the industry would benefit from the basics of a layout such as being described above. I say basics because there are certainly more complicated possibilities (some outlined in the blog post at the top of the issue) that many other folks may never need. As @desandro mentioned, the typical use is equal columns, but from the further examples there probably isn't much stopping us from defining varied column widths because the logic of how to define columns has already been in use through CSS grid. I think there is value in considering the possibility of complex layouts but it also could be scope creep. I don't think I can speak to the later questions because I probably don't have the need for these additional complexities. I just used subgrid for the first time in my latest site (the cards at the bottom) and I would have also been fine without it. So thinking about the first question, where does the concept belong in the family of CSS properties that we could place it, I'm considering what it would mean to rethink layout entirely. I'm not suggesting what I'm about to describe as an approach, but instead using it to inform my thinking in the categorization of where this might live. The way we describe flex vs grid is often 1D vs 2D layouts. However, grid does nearly behave like flex if it weren't for the column definitions. Children will wrap to the next line if allowed or be forced onto a single line. They both achieve this in different ways. Grid does this because of the number of columns and children, meanwhile flex will only allow wrapping when explicitly turned on. So I'm imagining a hybrid of both grid and flex, where children exist as taking up available space, packed densely until some definition comes in to influence how the packing occurs. If you only define columns, you'd get children to be sorted into the columns (in the layout we're describing here). If you only define rows, you get children sorted into the rows (a la flexbox) and if you define both, you get the grid. Children would be placed by writing mode such that all configurations will always set children left-to-right in LTR settings. All that said and looking at both approaches, personally I'd like to see something like the following: .my-items {
display: block | flex | grid | masonry;
columns: repeat(auto-fill, auto);
gap: 1rem;
}I see no reason why we namespace I'm also avoiding the matter of people learning a new syntax. If someone wants it, they'll figure it out. We've gotten used to flexbox and grid after that. Whatever comes out of this we'll learn too. It's more important that this can support a need; even if the syntax isn't precisely what we might have been expecting. |
|
Sorry I don't have much to offer here but I do want to add my thoughts; I would love to see a waterfall feature implemented into CSS Grid. I believe the benefits of utilising Grid features alongside a waterfall layout far outweigh any potential performance or future enhancement pitfalls that might come along when furthering the spec for Grid. To be honest, I would use the waterfall feature whether or not it is added to Grid, but in my mind they belong together. I would use it within Grid to create the kind of engaging designs that Apple has demoed, I've had to make layouts like these before and often wondered why it can be so tricky when it feels to me like an intrinsic design layout people want to use regularly. Ultimately, for me the power of Grid is its ability to let the browser do the hard work and allow for interesting layouts to emerge from experimentation, so adding waterfall to Grid would make it that much more powerful. |
|
Hi, I'm quite excited to see everyone discussing to finally make masonry happen !
That's it, that's my two cents, hope it can be useful to those who will get to work on the implementation ! |
|
After reading Rachel Andrew's points on why this should be a separate display property, I am convinced this should not be part of the grid spec. Same with flex it's a different way of defining a layout, although it does share many things with grid. |
|
I refuse to use JS to get this layout, so I am effectively masonry-disabled, even if it is self-inflicted. So adding this to the CSS spec is something I am strongly in favor of. But how it is added, too. While my initial thought was a separate This is something clients ask for all the time. It's astonishing to me that you could need any proof at all (with examples) of the need for it. It is, truly, long, long overdue. So +1 for leveraging the power of grids to provide masonry layouts and keeping the language consistent. |
|
Another (brief) +1 for extending CSS Grid to add Masonry support, I like the builtin graceful degradation! So that any page using it won't look that bad in older browsers. Also I might have a use for Masonry Layout personally... |
I will say, the Chrome Developers make a pretty compelling argument as to why masonry should be its own display: https://developer.chrome.com/blog/masonry The fact of dimensionality is the most convincing part for me, and the notion that some parts of grid won't be available to us when using masonry, and it will be up to us to remember those things. |
|
The masonry (or waterfall, whatever we wanna call it) layout is similar to a grid, so it shouldn't have its own display type. We can use display:grid, define the column layout (for vertical waterfall) or the row layout (for horizontal masonry), so we can have the benefits of grids, including the new features when released. Maybe a property "filling" or "grid-filling" could be masonry or waterfall (depending on the direction we wanna use). As for names, as @ddamato mentioned, I don't understand why grid properties have to be prefixed. Ex: grid-template-columns should be columns or template-columns. |
|
Should “masonry”/“waterfall” be part of CSS Grid or a separate display type?? Including "masonry" or "waterfall" layouts within CSS Grid makes sense. It's a natural fit for the Grid model and reduces unnecessary complexity. Do you want the capabilities to define a single-axis grid with CSS Grid — to use subgrid, spanning, explicit placement, and combining different track sizes? Or do you only want the ability to define a classic masonry layout with equal-sized columns? There's no need to sacrifice features when we can have both. Providing the flexibility of CSS Grid for various layouts, including classic masonry, ensures versatility without limitations. Will you use this at all? What might you do with it? Yes, for sure. I'm aways a fan of sprinkling some asymmetry here and there. The problem of invalid APIAs highlighted by by @saivan and elaborated on by Max Hoffmann in this comment, a significant concern arises from the potential for users to inadvertently create invalid layouts. .invalid-masonry {
display: grid;
grid-template-rows: off /* or masonry, or whatever*/;
grid-template-columns: off;
}
/* invalid but still possible */To mitigate this, introducing a new property such as .columnar-grid {
display: grid;
grid-template-columns: repeat(3, 1fr);
grid-axes: column; /* proposed new property */
}Handling cases where a user declares
Thus, if |
and others
We just published an article about Grid Level 3 / Masonry layout on webkit.org, https://webkit.org/blog/15269/help-us-invent-masonry-layouts-for-css-grid-level-3/, and at the end of the article, we asked web designers and developers to weigh in with their thoughts.
We opened this issue to provide a place for people to leave their input after reading the article, to especially answer these questions:
If you are finding this issue through the typical CSSWG channels, please read the article before commenting. It provides 4,000 words of context.
The text was updated successfully, but these errors were encountered: