Alternate masonry path forward #9041
Comments
|
Separating masonry from grid layout was already discussed in #4650 and had a bunch of proponents, including me. As indicated by the different properties @bfgeek introduces, masonry layout works differently than grid in several points. And separating its syntax from grid also allows adding features that only apply to it and not to grid and vice versa. Sebastian |
|
I've never been a fan of including masonry in grid layout. Mostly because we'd forever more be having to figure out how new grid stuff works with Masonry layout, which will always be a bit weird because a masonry layout is different to a grid layout. The current spec makes masonry layouts do a whole bunch of extra things that I've not seen authors ask for, mostly because "why not?" once it's all bundled into grid. Without compelling use cases for these features, it feels as if we'd be adding future problems of needing to work round masonry for grid additions, plus making to harder to add masonry specific things. I think this proposal achieves the things people want out of masonry, and avoids these pitfalls. |
|
(Fwiw I could have sworn we had a resolution to adopt |
I was actually searching for this quite a lot lately and didn't find a resolution on this and to be honest not even a draft. Would that be smth. for the Cupertino F2F Agenda as well @fantasai? |
|
So I don't forget - default alignment needs to be different for masonry as well. E.g. its desirable for replaced elements to stretch (vs. the grid default of start) similar to flexbox. |
|
Another thing so I don't forget - variable track sizes is problematic with items that span multiple tracks with "dense" packing. To correctly place the item in the correct tracks, you need O(N) layout passes on the item. |
For what it's worth, I do have a use case for that at https://www.gamestar.de. That page has two columns. And those columns contain different sections, which are placed explicitly in those columns. In horizontal direction the sections are meant to align on tracks while vertically they should be independent from each other. At the same time, they are explicitly placed in one of the tracks.
The two-column split is just one example. There are other pages which use three or even four columns. So, this seems to be a perfect match for masonry layout. And I believe, basically every website that is split into several columns could benefit from masonry layout. display: masonry;
masonry-template: minmax(0,1fr) minmax(0,2.5fr) minmax(0,15rem);The point of using Masonry here is that the height of the items should not depend on each other nor on a grid. So, I'd vote for a Sebastian |
|
That's not really masonry tho, right? They're not selecting the column based on available space; the stuff in the first column is meant for the first column, the stuff in the second is meant for the second. Today this would just be a grid with two columns and one row, with all the stuff in each column wrapped in a container. To fix the general problem of wanting to flow a mixed set of contents into a single grid cell without having to pre-wrap them in a container div we have #9098 |
Right. That use case avoids the auto-placement algorithm altogether, like it can be done in Grid and Flexbox, already. The benefit over Grid is that they are only aligned on one axis and the benefit over Flexbox is that they don't rely on wrapping logic.
Correct. That's how it's solved right now in the first example.
Yes, that issues would also solve that use case. Though that use case seems to be a natural fit for masonry and less so for grid. Sebastian |
|
What I mean is, since there is no column auto-selection at all, this isn't Masonry. Masonry's entire reason for existing is to allow you to place items according to the tracks' current fill height; if you're skipping that entirely, then Masonry might not be the right abstraction for this. This is especially true if reusing Masonry as the layout abstraction for this (and making changes to accommodate it) would harm more core use-cases. On the other hand, nothing about this case is particularly unusual for Grid. New functionality is needed (flowing multiple items into one cell as if they were grouped into a container element), but it's immediately compatible with the rest of Grid, too; it doesn't force us to reshape anything else about grid to accommodate it. As far as Grid is concerned it's exactly like just having a container element filled with stuff, and that's exactly what the use-case needs and wants out of it. So yes, in theory we could address some variations of this "flow multiple items into one grid cell" use-case with Masonry, but we can't hit all of them, and even for the ones we can do, it requires adding additional features to Masonry that harm the core use-cases. |
I'd argue that this is not true. The spec's introduction says this:
This is the main use case for Masonry. The auto-placement algorithm is one aspect of it, like it is for Grid layout. Sebastian |
|
Yes, that's an introduction for Grid Level 3. It was written starting from the assumption that this new functionality would be based on Grid, so it being somewhat Grid-biased is not a surprise. But the use-case in the wild, that we are attempting to capture in a layout mode, is pretty clear: it's items of arbitrary size being placed relatively tightly into tracks according to whichever track is currently least-filled. Placing items into specific tracks without automatic placement has not been traditionally called "masonry" or addressed by those tools; it's instead been handled by "group them in a container element". Anything going beyond that remit might be appropriate to solve with Masonry, or might be best solved with another layout mode (one that already exists or one not yet written!). We should not assume that every nearby use-case is necessarily appropriate to fold in, particularly when, as I said, doing so would harm the core use-cases. (Which allowing different-sized columns might do, as has been argued, by making some features (spanners, in particular) either not work correctly or be surprisingly expensive to layout.) |
|
The CSS Working Group just discussed The full IRC log of that discussion<TabAtkins> iank_: When Masonry was introduced there was discussion about whether this should be a new display type, or built into grid<TabAtkins> iank_: After reviewing this in more detail, I'm more convinced we want a new display type <TabAtkins> iank_: We didn't have a great proposal for what this would look like, so I typed up some details in a quick issue <TabAtkins> iank_: There's some fudnamental tensions between Masonry layout and Grid. This leads to some undesireable complexities, possibly perf problems <TabAtkins> iank_: So for a new masonry display type, we can do masonry-first, rather than bolting it onto Grid <TabAtkins> iank_: This is so far a very simple proposal, it can be extended in the future, but it concentrates on the core use-cases <TabAtkins> iank_: Handful of props. masonry-template tells how your non-masonry'd tracks look <TabAtkins> iank_: One detail is that, at least for now, ahving all your tracks the same size is important for perf. <TabAtkins> iank_: We also ahven't seen different-size tracks in the wild. <TabAtkins> iank_: Another is masonry-direction, same concept as flex. <TabAtkins> iank_: There are example where you want your masonry items to flow upwards <TabAtkins> iank_: Another detail - you can tell a masonry item to span, but not specify in a specific track. Again, based on use-cases we haven't found any use for that. <TabAtkins> iank_: A few other bits about alignment, squaring off. <fantasai> scribe+ <TabAtkins> Rossen_: Next steps? <TabAtkins> iank_: We might be interestsed in prototyping this in Chromium. I think if there are any fundamental issues, or use-cases that aren't covered by this proposal, that would be good to hear about <TabAtkins> Rossen_: I see the issue thread is already fairly active, some +1s, some open issues. <TabAtkins> Rossen_: I propose we take the convo back to the issue. When we have enough of an understanding on next steps we can bring them here. <fantasai> -> https://github.com//issues/9041#issuecomment-1710838816 <TabAtkins> fantasai: I took Ian's issues and split them out into sub-issues <Rossen_> ack fantasai <TabAtkins> fantasai: I think we should go thru and address these individually <TabAtkins> fantasai: The q of whether to make this a new display type or part of grid is kinda like the top of this issue, but some of the questions are "well is it even possible to build this into grid?" and I think we should answer that first <TabAtkins> fantasai: Then the question about a new display type isn't about whether or not it's possible, but whether it's *better* to be part of Grid or a separate display type. <TabAtkins> fantasai: I think all the issues Ian raises are addressable within the Grid framework, so it would be good to go thru the individual issues to see if they're actually blockers. <TabAtkins> fantasai: Then we can come back and see whether there's acutally a blocker that forces a new display type, or if it *is* possible in Grid so it'll be more a decision of which is better <plinss> q+ <TabAtkins> iank_: One thing I want to ensure is that, while lots of things are possible, perf is important. I'm concerned about quadratic behavior to add this into Grid. <Rossen_> ack plinss <TabAtkins> plinss: Orthogonal q - what's the status of layout worklets? <TabAtkins> iank_: We have a prototype; we want to clean it up after our layout rearchitecture. <TabAtkins> iank_: It's not a huge list of issues, we're just evaluating where it is on priority. <TabAtkins> plinss: k, just curious. if we're experimenting with new display types, seems like a great opportunity to explore in userland <TabAtkins> (fwiw I'm fairly certain Masonry *can* be done in the existing layout worklet API) |
|
Regarding |
|
grid-gap having been generalized as gap for usage in flexbox actually made it impossible to detect support for gap in flexbox with |
|
I think it's worth strengthening @tabatkins' point about ability to accept/reject at parse time. This means that dev tools will be able to suggest/highlight values immediately, and greatly improves discoverability. It would be nice if new syntax we add is statically checkable, and it may reduce friction. Regarding my comment on animation at the meeting, I guess we could always have View Transitions as last resort. |
|
(chair hat off still, this is just me trying to make sense of the options) Assumptions and caveats:
Masonry + Grid together Pros:
Cons:
Masonry as a separate display type Pros:
Cons:
By “new properties” I mean things that aren’t yet in Grid or proposed for Masonry. If the new thing works identically in both modes then the property duplication for the separate display types is annoying. But it’s also not great if a new single property has to have a mode switch designed into it. From a “designing future extensions to grid/masonry” standpoint I think I am favoring a separate display type. |
And this must be done when new properties or values are first introduced. |
Would also make it hard for feature detection, remember When using dedicated properties for masonry, you can feature detect support for a certain value separately from grid supporting it. |
And just to stress on this point - every single Grid property that can apply to masonry, save for |
|
+1 to Tab's and Rachel's comments |
|
@mirisuzanne brought up a good argument in favor of masonry in grid: you might want to have a masonry in a certain |
|
@nt1m That's possible, but I'm less certain how plausible it really is. Presumably you'd be shifting from an auto-flow grid into a masonry; I'm not sure I really see how common it would be to change from "all rows same height" to "no rows" based on a breakpoint. If you are changing based on a size breakpoint, it seems more likely to me that you're also going to be changing the tracks, in which case it's the same effort either way. |
|
Hi, |
|
I hadn't noticed the limitations that grid would have in conjunction with masonry, but that alone is a very compelling argument to have masonry as its own display. I think having masonry as a separate display would keep clarity between all of the display types as well, given that they do all seemingly handle different dimensionality. Given this method vs the Webkit method I'd prefer this. Thanks for the thoughtful breakdown! |
|
(chair hat on) In the interests of arriving at a decision, is there anything in the conversation so far that convinces the “separate display type” folks that integrating with Grid is the better path forward, or that convinces the “integrate with Grid” folks that a separate display type is the better path forward? (bonus points if equal numbers of people switch camps) |
|
For what it's worth, I was initially neutral but the reasonings provided by the "separate display type" folks have convinced me that option seems better. |
|
Quoting @astearns:
Stepping away from the discussion a bit, I feel like this:
is the most important argument of all. Masonry has no value at all if developers don't adopt it, and I feel like the chances are much higher with a strictly defined syntax. As a speaker and someone who gives workshops on a regular basis, I still run into people who don't understand grid and are still only using flexbox. Blowing up the grid spec even more would exacerbate this problem. New features (afaik) are introduced for the users - the web developers - and therefore should have the main focus on them to help solve their problems and therefore come with a good UX (Web Developer Experience). Going with Masonry + Grid together feels like we are shifting towards a better DX (Spec Writers - Browser Vendors) at the expense of worse UX by increasing complexity by introducing new edge cases into the spec and thus decreasing the adoption rate. I feel like I was kind of repeating myself, but I hope you get my point - Take a step back and don't forget who we're introducing this feature for. |
You could also argue that this is due to Grid being an entirely new thing for them to learn, in which case keeping Masonry separate only adds to that problem? |
|
For me, this all boils down to the question of whether CSS syntax should be based on "What" it's doing, or "How" it's doing it. When I say Creating However I can appreciate the arguments on both sides, and ultimately I care more about getting SOME form of this I can use than I do about getting perfect syntax. Heck, the flexbox syntax* still confuses me (I never know whether I want justify or align) but I’m still really glad we have it. *Possibly more a reflection of my lack of intelligence than anything else. To those of you who made it happen: thank you. |
With that example, you're actually advocating for When I say |
|
I just came here to +1 the |
|
I wouldn't mind splitting masonry and grid as long as they can inherit template rows/columns from each other like in the subgrid. It should work even when the display types are different: subgrid in masonry and submasonry in grid. In the future, this inheriting capability could also be expanded to multiline flexbox. |
|
I do wonder if there's any best-of-both approach here? But I don't know what that would look like. Just thinking: I get the complexity of properties working slightly different in different contexts, but it also feels real awkward having nearly-identical properties with nearly-identical syntax, but no interop. I'm not convinced that's actually "more clear" for authors in any meaningful way. |
@mirisuzanne Rachel Andrew has done an excellent job (as they always do) writing down the reasoning and shareable properties: https://developer.chrome.com/blog/masonry Plus, this write-up by Tab Atkins (one of the original spec writers for css grid) explains why "nearly-identical" is the best possible situation right now, whether masonry becomes an extension to css grid or its own layout: #9041 (comment) Some more thoughts:
|
|
I'm not entirely sure if this needs to be heard or not, but my take: Masonry isn't a It's a list of boxes, and they are flexible in both size and positioning: I would label it a "flex box" :) What makes far more sense, to me, is a more grammatically sensible naming if we want to keep it in line with what CSS already has: Example: .masonry {
display: flex;
flex-direction: row;
flex-wrap: wrap;
align-items: compact;
gap: 1px;
}You might even consider more specific options: align-items: compact-start;Which would push blocks upward into their available white space (excluding the align-items: compact-end;Which would push blocks downward into their available white space (excluding the It would also work if your flexbox is in the Potential issues:
Please don't make it into a grid addition. I feel that a masonry layout is absolutely not a grid. |
|
Here's another way to look at the question: how often will it be true that a gird, set up with the same values for the applicable properties, will be a desirable fallback for a masonry design in browsers where masonry is not supported? If people will need to change all sorts of things anyway, and need to rely on I think the theoretical answer is yes, grid can work as a fall back for masonry in many cases. But I'm more interested in author feedback based on real experience: you could fall back to an identically set up grid, but would you? I suspect the answer might be: not if you want a good design, but if fallback is more of an afterthought, falling back to an identically set up grid is often good enough. I don't know how much this expectation matches author experience at large. |
|
This is definitely a preferable implementation to the one advocated by WebKit. 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. |
@tabatkins can you give an example of a common degenerate case? |
|
Any case where you have a large number of tracks and/or items. Authors do all sorts of weird stuff for all sorts of reasons; they write Grids that are far larger than we had any reason to believe they'd need, for example. |
|
Hmmm, did I never post my alt document here? I shared it with Elika, but I can't immediately find any place I might have shared it with the rest of the group. I had a sketch of a proposal at the end of my earlier comment, and I've gone ahead and written a first draft of an alternate spec for a full Masonry display type here: https://tabatkins.github.io/specs/css-masonry/ |
|
Reponding to @frivoal:
From my experience, in most cases, falling back from an intentional design of a masonry to a grid is not going to be acceptable. For example, in the cases I can account for, if a user asked for a masonry then they want that to be the layout, regardless of whether it will be done via CSS or not. |
and others
TL;DR
The primary issue with building masonry layout on top of grid is related to intrinsic-sizing (of the container itself, and intrinsic tracks).
Grid layout works by placing everything in the 2D grid, that is assigning each child a column(s), and row(s), then sizing the grid with all the children fixed within the grid (they can't jump to another grid position).
Masonry layout however works in reverse - by sizing the rows/columns first, then placing children in the "shortest" row/column. This means that we can't correctly size the rows/columns (as we don't know the content), and also can't size the container itself correctly (if sizing using min/max content sizes).
This is detailed in issue: #8206
There are potential workarounds to deal with this issue, e.g. assume that all children are in every row/column for the purposes of sizing, but this prevents some potentially desirable use cases.
One thing that seems desirable is to allow a wider/different syntax for rows/columns than is currently allowed for grid, e.g.
masonry-template: repeat(auto-fill, auto).(Above would measure all the masonry items, and select the best number of tracks to fit the content).
(Arguably above might be a better default than masonry-template: auto for example).
This isn't possible for grid-template for good reasons - but we could accept it for masonry.
One open question is if we need different track sizes or just one would suffice. All the designs I have personally seen have just one track repeated N times. Accepting just one track template would allow easier intrinsic sizing of spanners for example.
One addition which is currently missing with grid repeaters is the ability to clamp to a minimum / maximum number. This is more relevant with masonry. E.g.
masonry-template: repeat(auto-fill, /* min */ 1, /* max */ 5, auto)would allow clamping to a maximum of 5 tracks which seems desirable from designs I've seen.(this is probably a bad syntax but you get the idea).
Another missing in the current proposal is controlling the direction of the masonry flow. E.g. there are cases where you'd want the masonry axis to start from the block-end / inline-end.
This could be covered by a property similar to flex-direction , a simple (and likely understandable property) might be:
masonry-direction: row | row-reverse | column | column-reverse(this would be similar to the originTop/originLeft controls in masonry.js https://masonry.desandro.com/options.html#originleft )
One issue with masonry style layouts is that things can easily be visually out of order, e.g. if the current tracks are [100px, 99px] the next masonry item would be placed in the 2nd track, when the first would be more natural. A potentially solution to this is some user defined "threshold" to "place within the first track within Xpx of the smallest track"
masonry-threshold: <length>Things that aren't in this proposal vs. the current draft are:
Ian
The text was updated successfully, but these errors were encountered: