- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 04 Dec 2024 17:42:45 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Masonry Syntax Debate`. <details><summary>The full IRC log of that discussion</summary> <fantasai> Topic: Masonry Syntax Debate<br> <fantasai> github: https://github.com/w3c/csswg-drafts/issues/11243<br> <fantasai> alisonmaher presenting from Chromium team<br> <fantasai> alisonmaher: [intros the topic]<br> <fantasai> alisonmaher: Several properties behave differently in each, or don't apply, so we think a new display type would be better.<br> <fantasai> alisonmaher: Plus we can define a better default value for the template tracks, creating an automtical masonry instead of a single column<br> <fantasai> alisonmaher: Regarding grid fallback, needing one is a temporary problem, so should focus on the future<br> <fantasai> alisonmaher: authors should make explicit fallback, to avoid surprises<br> <fantasai> alisonmaher: Positioning in masonry is simpler than grid, it's only placed in 1 axis instead of 2<br> <fantasai> alisonmaher: Grid is confusing because authors might make a mistake about which axis they are placing in (rows vs columns)<br> <fantasai> alisonmaher: separate model only has one axis<br> <fantasai> alisonmaher: this allows switching the axis easily<br> <fantasai> alisonmaher: Shorthands also are better with separate shorthand. Grid shorthand is complicated, hard to use. Masonry shorthand is easier because don't need to remember the order<br> <fantasai> alisonmaher: placement works differently in grid vs masonry<br> <fantasai> alisonmaher: dense packing is also different : for grid can place in any empty slot, but due to perf considerations for masonry current proposal restricts to same-sized track<br> <fantasai> alisonmaher: masonry also has different intrinsic sizing rules, with auto-placed items affecting all auto-sized tracks not just the one they end up in<br> <fantasai> alisonmaher: alignment is also very different, open questions about how this works in the masonry axis<br> <fantasai> alisonmaher: this means grid and flexbox are quite different in how they behave<br> <fantasai> alisonmaher: in masonry layout auto-placed subgrids don't inherit line names<br> <fantasai> alisonmaher: we expect there to also be other changes for submasonry/subgrid that will lead to divergences<br> <fantasai> alisonmaher: Integrating masonry into grid will lead to spec bloat, will be harder to teach, and lead to developer confusion<br> <fantasai> alisonmaher: Conclusion: masonry should be a separate display type<br> <fantasai> jensimmons: [intro slide]<br> <fantasai> jensimmons: At this point decision is about syntax -- mental model. Behavior is same in both.<br> <fantasai> jensimmons: [reviews basic case]<br> <fantasai> jensimmons: Choice to Just Use Grid is extending Grid L1. [shows example of grid vs masonry photo grid, with one difference - the grid-template-rows: collapse line]<br> <fantasai> jensimmons: New layout type, creates a separate tool with separate syntax that's similar but not the same as what exists<br> <fantasai> jensimmons: [shows table of properties being added]<br> <fantasai> jensimmons: We don't believe there's a compelling argument to add so many new properties to CSS<br> <fantasai> jensimmons: Both have properties for defining tracks; defining masonry axis<br> <fantasai> jensimmons: both have ways to define placement, and both have a new slack property<br> <fantasai> jensimmons: both have shorthand, and a gap property<br> <fantasai> jensimmons: and both have ways to implicitly size tracks<br> <fantasai> jensimmons: more significant difference is grid-auto-flow vs masonry-direction/fill/flow<br> <fantasai> jensimmons: Chromium argues that their new syntax is more understandable. We disagree, just use grid-auto-flow<br> <fantasai> jensimmons: Other major difference is template syntax<br> <fantasai> jensimmons: Here's a column example using the templat syntax. identical in grid 1, and masonry in both<br> <fantasai> jensimmons: When you layout rows in grid, template syntax is a bit different -- you stack the template names to phyiscally diagram the names for the rows<br> <fantasai> jensimmons: Just Use Grid re-uses this syntax exactly; but new masonry layout uses the column syntax for rows.<br> <fantasai> jensimmons: Chrome believes it's less confusing to use the same syntax in rows vs columns; but we believe it's better to use the same syntax between grid rows and masonry rows<br> <fantasai> jensimmons: Other difference is the auto-flow -- grid's indicates the primary fill direction, Chrome believes this doesn't make sense and changed it to match the orientation of lines<br> <fantasai> jensimmons: Debatable which is better. Might make sense if we had time machine, but is it worth creating a new layout API for this ?<br> <fantasai> jensimmons: Lots of subtle differences are likely to trip people up. They're familiar but not quite the same.<br> <fantasai> jensimmons: We shouldn't fork grid, would be confusing to authors.<br> <lea> q?<br> <lea> q+<br> <fantasai> jensimmons: Chrome argues that new display type allows better defaults -- but the defaults propose aren't good<br> <fantasai> jensimmons: if you think through the default they propose, it doesn't quite work as easily as claimed [see article]<br> <fantasai> jensimmons: requires deep understanding of autosizing<br> <fantasai> jensimmons: We believe it's better to just use grid. Very simple, one new value, re-uses syntax and mental model makes easier to learn<br> <fantasai> jensimmons: also easier to switch, e.g. at breakpoints or progressive enhancement<br> <fantasai> jensimmons: follows CSS design principles to re-use what already exists<br> <fantasai> [end presentations]<br> <fantasai> astearns: If you have comments, please add yourself to the queue<br> <astearns> ack lea<br> <lea> https://github.com/w3ctag/design-reviews/issues/1003#issuecomment-2489688718<br> <fantasai> lea: We did a TAG review on this<br> <fantasai> lea: My opinion is fully reflected there. I think the arguments WebKit team makes are compelling.<br> <oriol> q+<br> <fantasai> lea: We thought not only should masonry be part of grid, but should go further.<br> <fantasai> lea: a lot of arguments for integrating is that "grid is too hard". In that case we should make grid things easier.<br> <astearns> q+<br> <fantasai> lea: complex things are possible, but simple things are not so easy<br> <fantasai> lea: Big part of Google's argument is defaults, but we could just have smarter defaults -- there is precedent for this in CSS<br> <fantasai> lea: if we decided that would help ergonomics<br> <TabAtkins> q+<br> <fantasai> lea: We agree that switching between grid vs masonry is common. Grid might be a slightly better fallback than nothing, but minor argument because ppl can use @supports<br> <fantasai> lea: Introducing all these new properties increasing the API surfaces that authors need to learn. Less they can port over.<br> <fantasai> lea: Even if we say we will be disciplined, experience shows that we won't. Even if not intentional, accidental.<br> <fantasai> lea: DRY - don't have multiple sources of truth<br> <miriam> q+<br> <fantasai> lea: One of arguments against masonry in grid is that grid's are 2D, but actually in graphic design grids were often 1D<br> <fantasai> lea: I agree that most masonry use cases need simpler grids than general grid use cases<br> <fantasai> lea: but that means we should make those grids easier to define for both grid and masonry<br> <fantasai> lea: the more we looked into this, we realize there are 3 different layout modes that give you 2D arrangement of children<br> <fantasai> lea: we recommended not just make masonry part of grid, but find ways of integrating what we already have better<br> <fantasai> lea: could we come up with a shorthand that sets grid-auto-flow and flex-direction, and promote that for layout direction in general?<br> <fantasai> lea: then authors only need to learn one control for it<br> <fantasai> lea: another concern was overfitting<br> <fantasai> lea: it doesn't cover a lot of cases that look like masonry, like Flickr-style grid<br> <fantasai> lea: it's like a horizontal masonry<br> <astearns> ack oriol<br> <fantasai> oriol: Problem with jensimmons's reasoning<br> <fantasai> oriol: She said the proposed masonr-direction property would be new syntax that doesn't match grid-auto-flow property<br> <fantasai> oriol: but this property matches flex-direction property<br> <fantasai> oriol: so instead of trying to be close to grid, tries to be close to flexbox<br> <fantasai> oriol: closer to grid is a choice, could be consistent with different things<br> <fantasai> astearns: One question I asked is, has anyone changed their mind on which proposal they support?<br> <fantasai> astearns: I personally have. I thought that separate display property made a lot more sense, in terms of designing the feature and I was very daunted by the idea that we'd have to consider both grid and masonry for any new development ineither<br> <fantasai> astearns: seemed sticky to me<br> <fantasai> astearns: but the TAG argument convinced me that we should do the work of integrating these things<br> <astearns> ack TabAtkins<br> <fantasai> TabAtkins: Thanks for setting that up for me, because I'm going to refute the TAg argument! I think they're wrong in this case<br> <astearns> ack astearns<br> <astearns> zakim, close queue<br> <Zakim> ok, astearns, the speaker queue is closed<br> <fantasai> TabAtkins: You can draw a lot of surface-level connections between Grid and Masonry, and Flexbox, and other hypothetical layouts<br> <jyasskin> q+<br> <fantasai> TabAtkins: but when you actually look at details of how they work, behaviors each one is capable of, they're pretty distinct<br> <fantasai> TabAtkins: if you try to combine together, it would be an unholy mess of conflicting constraints -- e.g. flexing in items of masonry or grid<br> <fantasai> TabAtkins: or you'd have a weird mish-mash of, "the 2D layout", but if you call it a flex you get access to these properties, call it grid, access to these other properties<br> <fantasai> TabAtkins: concrete example, "pillar" example mentioned in webKit blog post, that wasn't compatible with the base concepts in masonry and flex because it wants a shared block formattng context<br> <fantasai> TabAtkins: grid etc have different formatting contexts, can't use floats<br> <lea> actually, the TAG argument was that layout seems to actually be a continuum, and syntax should accommodate that rather than forcing one of two extremes (current flex vs current grid).<br> <fantasai> TabAtkins: they're specialized for what makes sense<br> <fantasai> TabAtkins: You can occasionally merge things together, but definitely not something you can do that by default<br> <fantasai> TabAtkins: too distinct to be merged in a reasonable way<br> <jensimmons> That's why the "pillar" example will use `display: block`. The argument being made when it was articulated is NOT that it should be part of Grid, but that it should be part of Block, and not it's own yet another new mode.<br> <lea> Our argument was not "make it a part of grid" per se, but more "don't introduce a completely parallel new thing". If you can extend flex so that masonry can become part of that, that's just as fine<br> <fantasai> TabAtkins: Then usability arguments.<br> <lea> q+<br> <fantasai> TabAtkins: The masonry shorthand can be very similar to a standard CSS shorthand -- fully reorderable, just put the bits you care about<br> <fantasai> TabAtkins: integrated one, the grid shorthand is very complex, mixing in masonry doesn't make it simpler<br> <fantasai> TabAtkins: would stay bad and get worse<br> <fantasai> TabAtkins: separating lets use design things catered to the use case<br> <lea> if the `grid` shorthand has poor usability we should improve the grid shorthand, not design a new thing :)<br> <astearns> ack miriam<br> <fantasai> miriam: Like Alan, tend to agree with TAG on this. I'm not real excited about a future where we keep inventing new layout modes with slight differences.<br> <TabAtkins> The `grid` shorthand is complex *intrinsically*, it's got a lot of concepts that have to all be put together. It can't really be made much better.<br> <astearns> ack dbaron<br> <fantasai> miriam: I get that there's complexity, but it's worth the attempt to figure out how to not invent new tracks every time we have a new layout that has tracks<br> <TabAtkins> And that intrinsic complexity is directly tied to it being an inherently 2d layout mode, whereas Masonry, like Flex, is "1d, plus a bit"<br> <fantasai> dbaron: I remember Ian arguing about the perf characteristics wrt intrinsic size calculations<br> <fantasai> dbaron: Was related to fundamental ordering between how parts of the process run in grid vs masonry<br> <fantasai> dbaron: Good perf important for end users. Is that topic still under debate? Or is masonry in grid syntax using the model that Ian wanted<br> <fantasai> TabAtkins: Whether in grid syntax or not, using the distinct layout rules we defined to work for it<br> <fantasai> jyasskin: Wanted to emphasize a couple aspects of TAG review<br> <fantasai> jyasskin: It seems really nice to keep the property from Chrome proposal that you don't have to learn both, can just learn to do masonry without learning all of Grid<br> <fantasai> jyasskin: even if that's in a unified system<br> <fantasai> jyasskin: perhaps still define masonry shorthand, and have it set grid properties<br> <jensimmons> To create a simple masonry-style layout in Grid, you just need 3 lines of code (4 with a gap). It's quite simple.<br> <fantasai> jyasskin: Most consensus part of TAG feedback was to share properties whenver possible<br> <lea> q+<br> <fantasai> jyasskin: Not necessary to share the same 'display' values; could define different 'display' values but share the properties.<br> <fantasai> jyasskin: One thing we didn't like about unified proposal was `grid-auto-flow` in the unified proposal, where some values were ignored.<br> <TabAtkins> Yeah, this is the usability point I'm pounding on<br> <fantasai> astearns: I'm not hearing a way forward yet. At some point, one of the camps is going to have to concede in order to move this forward.<br> <fantasai> lea: What if we do a straw poll. Not to decide, but to figure out how far are we from consensus?<br> <fantasai> +1 lea<br> <fantasai> lea: people may have been convinced<br> <fantasai> POLL: 1) Just Use Grid 2) New Masonry Layout<br> <TabAtkins> 2<br> <lea> 1<br> <fantasai> 1<br> <kizu> 1<br> <oriol> 2<br> <bts> 1<br> <alisonmaher> 2<br> <jensimmons> 1<br> <masonf> 2<br> <florian> 1<br> <miriam> 1<br> <ethanjv> 2<br> <JaseW> 1<br> <astearns> 1 (changed from 2)<br> <dbaron> abstain<br> <ydaniv> 2<br> <rachelandrew> 2<br> <dholbert> 2 (weak preference)<br> <gfaujdar> 1<br> <chrishtr> 2<br> <SebastianZ> 2<br> <jfkthame> 1<br> <bramus> abstain<br> <kbabbitt> 2<br> <joshtumath> 2 (but being persuaded)<br> <schenney> 1 but try to move toward common property names<br> <noamr> abstain (happy if we ship either!)<br> <jyasskin> I would love to see both camps' attempts to move a step closer to a shared understanding. e.g. Do the WebKit folks think it makes sense to define a masonry: shorthand in the grid-unified proposal? Can they fix grid-auto-flow? Do the Chromium folks see some properties that could be more shared?<br> <romain> 1 (changed from 2)<br> <emilio> 1.5<br> <fantasai> jensimmons: Personally disappointed that we're not making more progress. We've been having this argument for 5 years.<br> <fantasai> jensimmons: We have two implementations. We'd like to ship. Lots of discussion over the last year.<br> <fantasai> jensimmons: Many folks have strong opinions, but the target keeps moving. A lot of the concerns have been addressed, but new reasons to keep separate.<br> <TabAtkins> I mean, same.<br> <fantasai> jensimmons: Argument is no longer about technical details, but overall concept and authoring experience.<br> <JaseW> Are Jen's slides available anywhere?<br> <fantasai> astearns: I believe both camps want to ship and are frustrated with current impasse.<br> <rachelandrew> not new reasons here, same reasons I started with (before I was at Google)<br> <astearns> zakim, open queue<br> <Zakim> ok, astearns, the speaker queue is open<br> <fantasai> jyasskin, yes I think we could do that. Not sure it would convince the Chrome folks though :)<br> <JaseW> @jensimmons<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11243#issuecomment-2518124401 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 4 December 2024 17:42:46 UTC