- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 03 Dec 2025 17:04:09 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-grid-3][masonry] item-flow row vs. column in masonry layouts`, and agreed to the following: * `RESOLVED: Whatever property controls the orientation of grid-lanes, its initial value is 'normal' and it resolves to waterfall or brick layout depending on whether grid-template-columns or grid-template-rows was set (respectively), defaulting to waterfall if both or neither are set.` <details><summary>The full IRC log of that discussion</summary> <Kurt> fantasai: There are a bunch of things interacting in this issue, but one thing we all seem to agree on is the initial value of the control should be a keyword called normal that switches between waterfall and brick based on wither you set grid-template-rows or columns<br> <Kurt> fantasai: I think we're all on board with that idea<br> <alisonmaher> q+<br> <astearns> ack alisonmaher<br> <Kurt> almaher: I had a separate proposal with a directionality wouldn't have a normal value, but auto-flow would have a default of normal. Not sure if that falls under the same resolution.<br> <TabAtkins> Ooh, I also didn't see all the discussion that happened yesterday afternoon<br> <Kurt> astearns: If we need an initial value that's neither row nor col it would be named normal<br> <Kurt> alisonmaher: my proposal is for a single source of truth - grid-lanes-orientation that would take either row or column. Could set either row or column and take whichever property is specified. Implied ordering of items in each lane as defined in masonry.<br> <Kurt> fantasai: I don't think that's incompatible with what I'm proposing, We're both saying there is a property that is a source of truth. That source of truth would have an initial value, that we'll call normal to not conflict with auto that computes to either row or column depending on what you set.<br> <Kurt> astearns: the difference is that there is no source of truth<br> <Kurt> fantasai: the difference is you don't need to set a separate property - we can infer if you set the template<br> <astearns> s/no source of truth/the source of truth doesn’t have a normal value/<br> <Kurt> alisonmaher: in your proposal, there isn't a single source of truth, there are many that can override each other<br> <TabAtkins> Yeah, there's no overriding.<br> <TabAtkins> This is a pretty normal way we handle defaulting.<br> <ntim> (see my last comment on the issue)<br> <Kurt> fantasai: If you set that property to something other to normal, then it automatically checks. That is intuitive for authors - they don't need to think of another property. If they don't set it, they get the thing they ask for, regardless of templates properties.<br> <Kurt> alisonmaher: are you saying that grid-auto-flow is the source of truth?<br> <Kurt> fantasai: Separate proposal, doesn't matter, there is a property, initial value is normal and will compute to rows or columns<br> <Kurt> alisonmaher: with that proposal, you can't have a masonry to have a row definition of non, allowed in masonry and not grid. If grid auto flow is normal, we need to look at grid. If both are set to none, we use columns, we can't get a definition set to non.<br> <Kurt> fantasai: If you set it we can determine. Issue is only if you don't set it.<br> <Kurt> alisonmaher: In that definition you can't have that definition for rows<br> <Kurt> TabAtkins: you have to set yourself to rows, because we can't infer it. You can achieve it with no template if you set row in direction determining property.<br> <Kurt> alisonmaher: I though if you set on later it would override the others, but sounds like that's not an issue<br> <ydaniv> +1<br> <fantasai> PROPOSED: Whatever property controls the orientation of grid-lanes, its initial value is 'normal' and it resolves to waterfall or brick layout depending on whether grid-template-columns or grid-template-rows was set (respectively), defaulting to waterfall if both or neither are set.<br> <Kurt> RESOLVED: Whatever property controls the orientation of grid-lanes, its initial value is 'normal' and it resolves to waterfall or brick layout depending on whether grid-template-columns or grid-template-rows was set (respectively), defaulting to waterfall if both or neither are set.<br> <TabAtkins> q+<br> <astearns> ack TabAtkins<br> <Kurt> fantasai: We're advocating for reusing grid-auto-flow. We don't see a need for a new control.<br> <miriam> q+<br> <astearns> ack miriam<br> <Kurt> TabAtkins: Storng for not using grid-auto-flow. We are using grid-template, but not other properties because they are not necessarily the same. In this case, they are very different. Specifically directionality. If we use grid-auto-flow, we are using wrong keywords for direction. We have extensions to grid-auto-flow to match flex (col-reverse,<br> <Kurt> etc), and those keywords don't work in masonry, not the right concepts. Trying to overly reuse grid is a disservice to authors. Better to get a similar that works for grid-lanes but not trying to serve multiple concepts.<br> <alisonmaher> q+<br> <TabAtkins> (I'm totally fine with -direction or -orientation<br> <TabAtkins> )<br> <Kurt> miriam: I prefer grid-auto-flow for consistency. I don't like it for grid either, but I learned it, and the same model works in both. I don't think grid-lanes is special. If we do come up with something for grid-lanes, it shouldn't be grid-flow, that would be confusing.<br> <astearns> ack alisonmaher<br> <ntim> I don't think we need a grid-lanes shorthand<br> <Kurt> alisonmaher: +1 to miriam, if we do have grid-lanes, orientation or direction makes this clearer. I also agree with tab to not use grid-auto-flow. Current proposal can set grid-lanes-rows which is the same as grid-auto-flow columns. Having same properties to set different things would be inconsistent. Shorthand would use opposite keyword, which is<br> <Kurt> a problem.<br> <ntim> q+<br> <Kurt> astearns: two routes, two options for each<br> <fantasai> Alison is referencing https://github.com/w3c/csswg-drafts/issues/12803#issuecomment-3597842524<br> <oriol> +1 to having a grid-lanes specific thing, +1 to call it -direction or -orientation, not -flow<br> <djmarland> +1 to grid-lanes specific, and avoiding the problematic word "flow"<br> <hoch> +1 to having grid-lanes specific<br> <Kurt> astearns: is it possible to discuss shorthand without making a decision without deciding on source of truth, or do we need source of truth first?<br> <Kurt> TabAtkins: they are tied, shorthand needs to express direction, which layout do you mean? It's the same question.<br> <Kurt> astrearns: other question, is there any difference between competing sources of truth on how syntax extensions for reversing stuff?<br> <Kurt> TabAtkins: yes, on the keyword side as well<br> <Kurt> fantasai: 3 syntaxes proposed, need to discuss and make a chart<br> <Kurt> TabAtkins: agreed<br> <ntim> I left my opinions on the issue, I prefer re-using grid-auto-flow<br> <Kurt> astearns: More opinions in irc for a separate property, not going to resolve today. Re-use auto-flow or new orientation property, not flow. Take it back to the issue and write out proposals in both syntaxes. Maybe have a github poll once there's a clear breakout of options, another grid-lanes breakout in 2 weeks. Opinions?<br> <Kurt> astearns: let's do that<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12803#issuecomment-3607869618 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 3 December 2025 17:04:10 UTC