- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Tue, 19 Aug 2025 14:31:46 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-grid-3] Masonry Switch Syntax`, and agreed to the following: * `RESOLVED: Design Principle - Keep masonry consistent with grid wherever practical: deviations need to be strongly justified by the inherent differences between grid vs masonry layout` * `RESOLVED: Design Principle - Keep masonry consistent with grid wherever practical: deviations need to be strongly justified by the inherent differences between grid vs masonry layout` <details><summary>The full IRC log of that discussion</summary> <emilio> astearns: fantasai wanted to resolve that we'd like to keep both the grid and new masonry display modes as consistent as practical<br> <emilio> PROPOSED: keep both the grid and new masonry display modes as consistent as practical<br> <lea> +1<br> <emilio> oriol: not an objection but saying this is still subjective, so not sure this resolution is bringing much value<br> <emilio> astearns: I think there's some value, but yes should be discussed case by case<br> <emilio> ... but without it the tendency would be to diverge<br> <emilio> ... and not considering grid when talking about masonry or vice versa<br> <emilio> fantasai: yeah lots of situations where many options can be practical<br> <emilio> ... this say that in those cases we prefer consistency<br> <emilio> oriol: but there's not only practicality<br> <emilio> ... we already prefer diverging in some cases<br> <emilio> ... e.g. we might prefer to be consistent with the existing diversions<br> <emilio> ... like with the intrinsic keywords<br> <emilio> ... we had the choice to make masonry better than grid vs. consistent with it<br> <emilio> ... and not sure I'd agree with that<br> <ntim> +1000 to what Elika is saying<br> <emilio> fantasai: self-consistency is useful and good but I don't think having one mode self-consistent in this mode, and the other one be different in the same way I think that's wrong<br> <ntim> q+<br> <astearns> ack fantasai<br> <emilio> oriol: my worry is that is masonry and grid are different, that's why we have it<br> <emilio> ... when discussing new features I think it makes sense to consider whether they would have special behaviors on masonry<br> <emilio> ... rather than blindly following grid<br> <emilio> ... and I don't want to have a resolution that blanket disallows considering it<br> <emilio> astearns: I think we should allow inconsistencies between grid and masonry but only when they're well supported<br> <emilio> oriol: wdym with that?<br> <SebastianZ> +1 to astearns<br> <kbabbitt> q+<br> <ydaniv> q+<br> <emilio> fantasai: there should be a very good reason to diverge from grid<br> <emilio> ... this is one of the key reasons about being a different display type<br> <emilio> ... so people don't tailor things to be different between masonry / grid<br> <emilio> astearns: but as much as you can is key<br> <emilio> oriol: I agree with consistency by default<br> <emilio> ... but I don't want to close the door to diverging<br> <emilio> fantasai: ever diversion should be strongly motivated by an intrinsic difference of masonry vs. grid that requires us to consider that<br> <emilio> ... the context of that decision is substantially difference such that overriding consistency makes sense<br> <florian> q?<br> <emilio> ... they should still feel like flavors of the same mode<br> <florian> q?<br> <florian> q+<br> <emilio> ... shouldn't feel like flex vs. grid<br> <emilio> ... we shouldn't make them behave differently just because<br> <emilio> lea: what about impl differences?<br> <astearns> ack ntim<br> <emilio> fantasai: we should work towards addressing that as possible<br> <emilio> ntim: from an authoring perspective consistency makes a lot of sense<br> <emilio> ... the small differences are the ones you forget<br> <emilio> ... and those are rather annoying<br> <emilio> ... aiming for consistency as much as possible is a big win for authors in general<br> <emilio> q+Q<br> <emilio> q-Q<br> <emilio> q+<br> <emilio> ntim: yeah being told that masonry and grid are the same but slightly difference<br> <emilio> ... different is very annoying<br> <emilio> lea: the more context you can carry across the better<br> <emilio> alisonmaher: this resolution feels a bit too general<br> <emilio> lea: I think fantasai is proposing more of a design principle, not a law<br> <astearns> ack kbabbitt<br> <emilio> alisonmaher: by that principle that'd force us into a resolution in that case<br> <emilio> lea: it nudges into that direction<br> <emilio> kbabbitt: I was going to suggest a different wording<br> <emilio> ... we prefer consistency between grid and masonry when it wouldn't do a disservice for an author use case<br> <diekus> +1<br> <emilio> ... I agree consistency makes it easy for authors to learn<br> <emilio> ... from a priority of constituencies standpoint I don't think we should be locked into consistency for consistency's sake<br> <emilio> fantasai: that's a bit too shallow<br> <emilio> ... because you can always come up with a use case for a divergence<br> <emilio> ... but that doesn't mean to make the use case impossible<br> <emilio> ... e.g. setting consistent default initial track sizing<br> <emilio> ... but consistency also has to be balance with that<br> <emilio> lea: what you're consistent with is often the challenge<br> <emilio> ack ydaniv<br> <astearns> ack ydaniv<br> <emilio> ydaniv: maybe stupid question, but lea just said it, we want consistency at the API level, which we have with item-flow etc props<br> <emilio> ... if we have the same props and values work for the same intent that's consistency<br> <emilio> ... it's desirable to have different behaviors for different display types<br> <emilio> ... because this is the whole intent of the feature<br> <emilio> fantasai: this is why we didn't want a different display type<br> <ntim> q+<br> <emilio> ... you can justify this with it being a different display type<br> <emilio> alisonmaher: if the inconsistencies are consistent with the existing inconsistencies that might override the consistency<br> <lea> what I was alluding to was that "be consistent" by itself is a platitude. Everyone agrees that all else being equal, consistency is a good thing. The challenge is a) *what* to be consistent with when there are multiple diverging precedents and how to weigh consistency against other design principles, when they are conflicting<br> <emilio> fantasai: I'd agree with that but if they're not necessary then we shouldn't make them<br> <lea> q?<br> <emilio> q-<br> <lea> q+<br> <emilio> ack florian<br> <emilio> florian: I don't think we can resolve on this, the goal of consistency if usability<br> <emilio> ... priority of constituencies doesn't really help us here<br> <emilio> ... I think we are trying to go for is "just because it's a different display type we should not diverge from grid"<br> <emilio> ... consistency we should be our default position<br> <emilio> q+<br> <emilio> florian: e.g. we shouldn't take this with an opportunity necessarily just to correct a grid mistake<br> <fantasai> +10000 florian<br> <emilio> ... I don't think that locks us into many of the things alisonmaher talked about<br> <emilio> ... consensus is the only thing that matters, let's agree on something<br> <astearns> ack ntim<br> <emilio> TabAtkins: I'm fine to resolve that to the extent it's reasonable we should keep masonry and grid as consistent as possible<br> <emilio> ntim: I think an example of inconsistency we want to avoid is getting the same keyword getting different meaning on masonry v.s. grid<br> <emilio> ... making sure we keep coherency between both<br> <astearns> q+<br> <fantasai> (if it's not required by the characteristics of masonry vs grid)<br> <astearns> zakim, close queue<br> <Zakim> ok, astearns, the speaker queue is closed<br> <emilio> ... so it's not just consistency per consistency's sake<br> <ydaniv> +1 to ntim - coherency is nice<br> <astearns> ack lea<br> <emilio> lea: as an observation from this discussion it seems like fantasai is suggesting a design principle<br> <emilio> ... we're supposed to follow other design principles, but they are not hard resolution<br> <ChrisL> “A foolish consistency is the hobgoblin of little minds, adored by little statesmen and philosophers and divines”<br> <ChrisL> ― Ralph Waldo Emerson, Self-Reliance: An Excerpt from Collected Essays<br> <emilio> ... they're meant to nudge / apply pressure<br> <emilio> TabAtkins: in the context of the issue we discussion it was much more reasonable to conclude this was not a general principle but more of a strong nudge<br> <emilio> florian: I think it should be considered a strong nudge but not a shortcut<br> <emilio> ... it applies pressure but not resolves the other issue<br> <emilio> TabAtkins: but yeah it's a principle I want to adhere to<br> <florian> proposed: we will attempt to keep masonry consistent with grid when possible, and deviations need to be strong justified by the inherent between grid vs masonry<br> <ntim> how about: we should aim to not break coherency between grid and masonry ?<br> <TabAtkins> emilio: after scribing, it feels like everyone is in agreement<br> <astearns> ack emilio<br> <TabAtkins> emilio: was gonna suggest "cconsistency with Grid should be considered and preferred when possible", but maybe florian's suggestion is better<br> <emilio> astearns: I had closed the queue because I didn't know how far we're going to get with this<br> <fantasai> PROPOSED: Keep masonry consistent with grid wherever practical: deviations need to be strongly justified by the inherent differences between grid vs masonry layout<br> <emilio> ... we already have the tag feedback saying that it's not just grid/masonry but also flex that should be consistency as much as we keep it<br> <emilio> ... because of that input we have the item-flow proposal which is an incredible improvement<br> <emilio> ... to how we have been considering flex/grid/masonry<br> <emilio> ... I think in some way the design principle shouldn't be just about grid/masonry but also about all the display modes<br> <emilio> ... but happy to keep the resolution about these<br> <lea> q?<br> <lea> q+<br> <emilio> fantasai: I think that's harder because other modes are more different<br> <astearns> ack astearns<br> <emilio> ... so it'd be a louser nudge<br> <emilio> lea: we could do both<br> <TabAtkins> (I think fantasai's wording is great)<br> <emilio> ... we could word the design principle we should three in sync, otherwise two<br> <emilio> florian: we have a proposal and I don't see any pushback<br> <emilio> astearns: any objection with the proposed wording?<br> <emilio> oriol: seems fine<br> <emilio> ntim: does that mean inherent differences between grid / masonry are allowed to break coherency?<br> <emilio> fantasai: yeah e.g. auto placement must happen in a different order between grid / masonry<br> <emilio> ... but we don't need to create different interpretations of whether auto accounts for min-width or how it does it<br> <emilio> astearns: alisonmaher do you have any reservations I'm fine not resolving on this<br> <emilio> alisonmaher: I'm ok with the principle it's just the specific issues<br> <fantasai> PROPOSED: Design Principle - Keep masonry consistent with grid wherever practical: deviations need to be strongly justified by the inherent differences between grid vs masonry layout<br> <kbabbitt> +1 to including the words "design principle"<br> <florian> +1<br> <emilio> RESOLVED: Design Principle - Keep masonry consistent with grid wherever practical: deviations need to be strongly justified by the inherent differences between grid vs masonry layout<br> <fantasai> RESOLVED: Design Principle - Keep masonry consistent with grid wherever practical: deviations need to be strongly justified by the inherent differences between grid vs masonry layout<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12022#issuecomment-3201014167 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 19 August 2025 14:31:47 UTC