[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. |
|
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 |
|
+1 to team Safarifox on this one. The masonry layout solution should be part of Grid, not its own display. As someone pointed out in another comment, it is sometimes hard distinguishing Flex from Grid, and being able to use features of Grid with a masonry layout feels very nice. Honestly, the masonry layout kinda feels like being able to marry Flex and Grid in a very natural way. |
How much complicated would this make the grid specification? You will have to learn all the ways where masonry and grid are different in addition to what they have in common. I don 't believe this will be trivial. Having a separate |
|
Wouldn't this new spec be very similar to grid-auto-flow: dense? Can we amend it to handle content of varying size, to the developer/user that appears to be the only difference? I am aware that grid is 2D and "masonry" 1D but to a dev it very similar. I'm sure there are many low level engineering reasons (or ego driven opinions) why grid-auto-flow: dense is different or can't be amended and I would like know what they are. Rachel Andrews briefly mentions this but shares no detail on why a separate spec is required. If "masonry" is added I think it should be a new display type not part of grid. Adding it to grid will be redundant and it will be confused with grid-auto-flow: dense. Either way there will be many posts in the future asking: "What's the difference between grid-auto-flow: dense and 'masonry'?" and "Why does grid-auto-flow: dense exist and why use it?" I really like the ideas of "sub-masonry", spanning rows/columns and being able to explicitly place items with-in a "masonry" grid. Some name ideas: stagger, condense, offset, compact, matrix, stack. Or simply call it what it actually is: "flexgrid" I would like to see vertical/column, horizontal/row and auto (auto arrange even if out of order) options. e.g. stagger: auto, stagger: row or stagger: column Has the csswg even agreed on what a "masonry" layout is? There are many variations. |
|
For me auto-flow-dense should work in grit-template-row: off as well.
Normally they should be added as they flow in html, but with dense they
should try to fill holes that were created by normal flow.
W dniu wt., 7.05.2024 o 10:51 justinasmussen ***@***.***>
napisał(a):
… Wouldn't this new spec be very similar to grid-auto-flow: dense
<https://developer.mozilla.org/en-US/docs/Web/CSS/grid-auto-flow#:~:text=columns%20as%20necessary.-,dense,this%20leaves%20holes%20that%20could%20have%20been%20filled%20by%20later%20items.,-Formal%20definition>?
Can we amend it to handle content of varying size, to me that appears to be
the only difference? I'm sure there are many low level engineering reasons
why grid-auto-flow: dense is different or can't be amended and I would like
know what they are. Rachel Andrews briefly mentions
<https://developer.chrome.com/blog/masonry#:~:text=grid%2Dauto%2Dflow%20doesn%27t%20apply%20to%20masonry%20and%20masonry%2Dauto%2Dflow%20doesn%27t%20apply%20to%20grid.%20Merging%20them%20would%20create%20problems%20of%20things%20that%20are%20invalid%20due%20to%20the%20layout%20method%20you%20are%20in.>
this but does not go into detail.
If "masonry" is added I think it should be a new layout type not part of
grid. Adding it to grid will be redundant and it will be confused with
grid-auto-flow: dense. Either way there will be many posts in the future
asking: "What's the difference between grid-auto-flow: dense and
'masonry'?" and "Why does grid-auto-flow: dense exist and why use it?"
Some name ideas: stagger, condense, offset, compact, matrix, stack.
I would like to see vertical/column, horizontal/row and auto (auto arrange
even if out of order) options. e.g. stagger: auto, stagger: row or stagger:
column
Has the csswg even agreed on what a "masonry" layout is? There are many
variations.
—
Reply to this email directly, view it on GitHub
<#10233 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AFKBQQPTJDSQHJVQEJLSKDLZBCIYPAVCNFSM6AAAAABGPZCFRGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOJXG44DCNRRGA>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
I want to give a +1 to It reads better, has a single purpose and doesn't make |
|
I'm late to the party but wanted to cast a vote for I just implemented CSS Grid to my framework Bulma, and the amount of properties is already high, even if some of them are shared with Flexbox. And for me:
A grid is two-dimensional because it has rows and columns. These rows and columns can be explicitly or implicitly defined. Cells can span multiple columns and/or rows. When I'm using In a Masonry layout however, I only care about the columns. I've used and created Masonry layouts with JavaScript, and I never cared about the rows. Take a look at this Masonry layout, taken from Webkit's blog post. This simple Masonry layout already has a whopping 60 rows:
I don't see any scenario in which I would actually use these implicit rows, like telling an item to "span 2 rows", because that's not how a Masonry layout works. The usual mechanics of a Masonry layout are to:
At no point did the concept of rows come into action. And if you look at the documentation of Masonry by @desandro (probably the best library out there), you can see how you can specify the That for me is why I don't consider Masonry layouts as a type of grid, but rather as another type of 1-dimensional layout. In any case, I appreciate all the effort put into this by browser developers and the feedback provided by the community, and hope to see it implemented soon. |
|
@jgthms but how treating Masonry as 1-dimensional layout could account for items spanning multiple columns, as most examples in the documentation of Masonry by @desandro show? It clearly seems to introduce the horizontal dependencies between columns (you have to check the height of neighbouring columns as well while choosing where to put the next element), and these dependencies can be considered "virtual row lines". And limiting the possible layout to single-column version would exclude "magazine layouts" like in this example. To me, Masonry is still 2-dimensional, and @desandro himself describes his library as a "Cascading grid layout library". I see the key difference from the regular Grid, which works "from layout in" in both direction, that Masonry works from layout in in one direction and from content out (like Flexbox) in another. However, differentiating 2-dimensional "masonry grids" and 1-dimensional "masonry columns" (like "masonry" vs. "waterfall" in the comment above) might make sense. |
|
Hi, a UX designer turned design technologist(which I am still confused what that title means) here. I would agree with what @itsmanojb demonstrated in his comment. As a designer, grid is just lines that helps me align my content. When designing a screen with masonry(waterfall) content, I would rely on the grid to design them. Because of this reason, when I'm researching ahead before communicating with the FE who is going to make my design come to life, my google search terms would be things like |
|
Should masonry be part of grid? Absolutely not. It should definitely be a display type in its own right. However I really don't think this is a valuable use of anyone's time. There are so many defined things in CSS yet to be implemented across browsers not to mention significant inconsistency between browsers and browser bugs. Time and effort would be far better spent getting up to speed and collaborating more rather than trying to define and make something with relatively few applications all the while arguing over the best way to do it. This entire debate strikes me as a case of browser creators making what they want to make rather than what the web, users and developers actually need. |
|
I agree that masonry should be it’s own thing apart from grid, using There are plenty of other arguments beyond this. For instance, masonry truly is a hybrid layout, more like grid in one direction and flexbox in the other. But the biggest thing for me is the learning path. It's a lot easier to learn masonry, then discover a lot of that knowledge can be applied to grid than it is to learn all of grid and selectively piece together which parts of it can and cannot apply to masonry. I think a huge number of developers only interact with grid using I think it’s okay to have a number of parallel properties between masonry and grid. That's kind of how placement already works between flex and grid (e.g. |
|
Yeah, I think upon reflection, I'm adding a +1 to the To me, it would feel almost like a kitchen sink layout methodology if this went through, cramming what is essentially two different layout methods into one. And I worry about the performance implications, and future maintainability of this too (a grid level 4 would have to not only consider normal grid layout + subgrid, but masonry too - in which there may be some things added to that spec that don't make sense for masonry). If this is kept separate, we can optimize the performance for that specific layout type, and future specs can be more focused on features for either normal grid or masonry. For my own personal use case, creating a grid with a fluid track definition, alignment options, direction options, and the ability to span an item over columns or rows would cover pretty much all my use cases. |
|
@tabatkins can you speak to how you would achieve this use-case? I think you can remove the header and footer from the equation since they can be handled separately. But I'm wondering if your proposal accounts for the optional banner ? Could you still ensure that the right content, secondary nav and ads, end up in the sidebar? 
|
|
@stubbornella I don't think this particular layout makes sense as a masonry layout, it's so constrained it doesn't use any mechanism of masonry anymore. I feel like the easiest and most semantic solution is to wrap the asides (secondary content, ads) in an |
Of course, it would be something like: @media (wide) {
body {
display: masonry;
/* two tracks, named main/sidebar */
masonry: "main sidebar" 1fr 200px;
}
#main-nav, #footer {
masonry-track: 1 / -1;
}
#banner, #content {
masonry-area: main;
}
#sub-nav, #ads {
masonry-area: sidebar;
}
}
@media (narrow) {
body {
display: masonry;
/* just one track, no need for a name */
masonry: auto;
/* Or, I guess, just switch to Flexbox or something. Whatever. */
}
}
/* and since there's only one track, no need to position
the children manually */Header and footer work just fine, you can still span multiple tracks. And of course |
Nah, as I've played in the space I've found that "columns you can assign things to" is a very reasonable use-case, and fits within the confines of a Masonry spec very naturally. Literally the only thing you need to support this entire layout is the ability to have items span multiple tracks (already a well-established core use-case) and the ability to assign items to a specific track (less common, but trivial to adopt, and very natural when reusing concepts from Grid for the placement properties; it would be weirder to not allow that, actually). The only downside of shoving this use-case into Masonry is that you still get the limitations of "size as you place", which restricts how you can size tracks, even tho all the items have a known placement location up-front. But still, that's a relatively small price to pay, I think (and is theoretically fixable in the future, if we decide to...) |
|
Alternately, cases like this can be solved within Grid using |
|
@tabatkins Strong +1 for I didn't intend to say that this layout should not be achievable in |
|
in follow-up to Tab's excellent presentation at #cssday 2024, regarding wether it should be part of the grid, or a separate display: I would prefer to see it as a separate |
I totally agree @FremyCompany. In fact, before I stumbled upon this thread, I posted my thoughts on that layout here after seeing @stubbornella's talk at CSS Day 2024, in which she presented it. :) While it is possible to achieve that layout with Grid + Flex + |
Hi I have more or less the same use case, and I think it's a common pattern for a e-commerce product-detail page. Most of them have a Product image/gallery on the left and next to it a buy-block and on a smaller screen they should stay together, but you don't want any whitespace below the image or below the buy-block I made a screenshot so I hope you will understand it a bit better. 
first (brown block) is Image/Gallery, the (blue block) is buy-block and the rest are al kinds of blocks that can come in all kinds of types. The current situation is that they use 2 templates a single column for small devices with a device check, and 2 columns for desktop like devices. But Ideal you just want 1 template for it. |
|
There's no harm in trying. I think display masonry and waterfall will best fit in the grid because they come much in common. But separating them too is not bad as it will reduce the code lines making things simpler. In any way they appear creative people will use it to achieve great and eye-catching designs. Or better still they can be versatile that is, they can be used independently or as in display grid. |
|
Thanks Jen Simmons and Rachel Andrews for writing such in-depth articles about the future of CSS! After reading both the Jen's Webkit and Rachel's Chrome articles, I would say I'm leaning towards masonry being its own display type. The masonry layout is more concerned about one axis like flexbox, rather than grid's concern over both axes. If masonry was added to the grid spec, I think the amount of properties that do not cross-over from one layout to the other would make troubleshooting issues a big pain. Some values seem logical with masonry while should throw errors in grid : I use grid constantly and am well versed in the syntax and I think masonry should share a lot of the terminology and functionality but they should still be separate display types. One is issue I have with the Webkit article is their case for subgrid. I've tried shoe-horning subgrid into projects several times and it never really makes sense to me. In their example (I understand it's an example and maybe not the best real-world scenario), I think it would make more sense to define the layout of the card so that the cards are all uniform. Their use of subgrid seems arbitrary since every card is taking up two columns, one of those columns on the parent is just to align child's content. That seems like classic case of over-parenting. |
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: