- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Fri, 14 Nov 2025 05:49:09 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `https://github.com/w3c/csswg-drafts/issues/12803`.
<details><summary>The full IRC log of that discussion</summary>
<ntim> topic: https://github.com/w3c/csswg-drafts/issues/12803<br>
<ntim> github: https://github.com/w3c/csswg-drafts/issues/12803<br>
<ydaniv> fantasai: going back to item flow discussions we had previously<br>
<ydaniv> ... there's been discussion on what the syntax should be<br>
<ydaniv> ... TabAtkins and iank_ said we should not go with what grid does<br>
<ydaniv> ... this is blocking impl. work<br>
<ydaniv> ... we still need to decide what longhand do<br>
<ydaniv> ... we need to underline longhands<br>
<astearns> s/underline/underlying/<br>
<ydaniv> ... we need to resolve on what they are? what the values are? and shorthands later<br>
<ydaniv> ... we have a proposal with counter arguments<br>
<ydaniv> ... we have to decide are using grid properties, or minting new ones<br>
<ydaniv> ... what are those properties? what are the values? and what they're mapped to?<br>
<ydaniv> ... also discussed about "auto"<br>
<ydaniv> TabAtkins: I'll present while reusing grid-auto-flow is not correct<br>
<ydaniv> ... if you want waterfall layout [missed]<br>
<astearns> s/waterfall/grid-lane/<br>
<miriam> I think 'waterfall' in this case refers specifically to vertical grid-lanes<br>
<astearns> yes<br>
<emilio> TabAtkins: to avoid confusion we've referred to waterfall and brick<br>
<emilio> ... if you have a waterfall layout you have columns, that's also the initial value because it's the most common initial value for grid-lanes<br>
<florian> q+<br>
<emilio> ... grid-auto-flow initial value is row<br>
<emilio> ... so we'd need to magic up a new initial value<br>
<emilio> fantasai: which we planned to do anyways<br>
<emilio> TabAtkins: not for grid<br>
<emilio> ... secondly grid-auto-flow, row vs row-reverse, they change whether items autoflow ltr or rtl<br>
<emilio> ... in grid-lanes a lot of people have the intuition that the primary direction should be the direction where they break ties<br>
<emilio> ... you'd start rtl again even with a column layout<br>
<fantasai> s/discussed about "auto"/discussed about "auto" initial value for the flow direction, to automatically decide based on the -template properties; but this needs to be renamed (maybe to normal) to avoid conflicts in grid shorthand with 'auto' track sizing/<br>
<emilio> ... so if we reuse grid-auto-flow, row-reverse would mean a different thing than in grid-lanes<br>
<emilio> ... would mean perpendicular axis<br>
<emilio> ... because you want columns to be ltr columns and column-reverse to be rtl<br>
<emilio> ... in grid your default is row / row-reverse<br>
<emilio> ... if you say column that means top to bottom or bottom to top<br>
<miriam> almost makes you think we should call it the same thing as in grid…<br>
<emilio> ... this is due to the distinction between flow direction and track direction. In flexbox and grid they are aligned in masonry they are opposite<br>
<ntim> q+<br>
<emilio> ... so reusing the same terms that mean track / direction in grid but giving the keywords a perpendicular meaning doesn't seem good to learning how these work<br>
<miriam> q+<br>
<emilio> ... it might be if waterfall layout was rows<br>
<emilio> ... but it's not<br>
<emilio> ... so we should mint a new property<br>
<emilio> ... grid-lanes specifically<br>
<florian> q?<br>
<emilio> ... so I think we should do that instead of changing the meaning of specific values in grid-lanes masonry<br>
<emilio> astearns: this felt two introductions about two different topics<br>
<emilio> ... let's go through the queue and see if we can get some clarity<br>
<astearns> ack florian<br>
<emilio> florian: my initial impression was a bit similar to tab in the sense of of course waterfall should be column<br>
<emilio> ... but looking at it I don't think we're calling it anything<br>
<emilio> ... we're controlling aspects of the design<br>
<emilio> ... so sure if you look at it I see columns<br>
<emilio> ... but even then depending on the property I'm comfortable saying that the flow of the items in a waterfally grid-lane goes by row<br>
<emilio> ... and that seems fine to me<br>
<emilio> TabAtkins: if the thing that determines the direction uses rows for masonry which uses grid-template-columns etc for everything<br>
<emilio> ... I'd formally object to that<br>
<emilio> florian: just saying that I don't have the same opinion<br>
<oriol> I agree with Tab it would be super confusing<br>
<emilio> TabAtkins: I'd formally object to that<br>
<astearns> ack ntim<br>
<emilio> ntim: re. flow vs track<br>
<florian> s/just saying that I don't have the same opinion/just saying that I used to have the same opinion, but no longer to<br>
<emilio> ... I think that track direction doesn't really matter, ATs what you experience is the flow direction not track direction<br>
<florian> s/longer to/longer do<br>
<emilio> ... if you really care about track and ?? then you use multicol<br>
<emilio> ... I'd probably object if we were to consider the track direction was the primary one<br>
<astearns> ack miriam<br>
<emilio> miriam: Thanks for not taking into account our opinions<br>
<emilio> ... you wanted us to follow up, we did, we disagree with you and now it's a formal objection situation<br>
<emilio> ... have no power in that situation, that's cool, have fun with it<br>
<emilio> astearns: I'm with you in the frustration but you can formally object as a member of this group<br>
<emilio> fantasai: you don't even need to be a member, anyone can literally formally object<br>
<astearns> ack fantasai<br>
<emilio> ... I want to present my position and counter proposal<br>
<emilio> ... we think that keeping the properties consistent with grid is better<br>
<emilio> ... therefore we should use grid-auto-flow, and interpret the values in the same way<br>
<emilio> ... if you switch display the overall layout would flow in the same direction<br>
<emilio> ... TabAtkins mentioned that he wants a shorthand<br>
<emilio> ... and if you write row 200px<br>
<fantasai> grid-lanes: row 100px 200px;<br>
<fantasai> grid-template-columns: 100px 200px;<br>
<emilio> ... which would be confusing<br>
<fantasai> grid-auto-flow: row;<br>
<emilio> ... I have several suggestions<br>
<emilio> ... first one is we've discussed grid-auto-flow initial value would be normal<br>
<emilio> ... and depending on grid-template-rows/columns we'd pick the correct flow direction<br>
<emilio> ... whichever one is none picks the flow direction<br>
<emilio> ... now grid-lanes sets grid-template-{rwos,columns,areas} and grid-auto-flow, ... either to the initial value or something else<br>
<emilio> ... I suggest changing grid-lanes to instead of `row` being a grid-auto-flow<br>
<emilio> ... value, we'd change it to `rows`<br>
<emilio> ... and then set grid-template-rows<br>
<TabAtkins> my point is and has been that *this* would be a terrible mistake that I can't allow as editor of the spec:<br>
<TabAtkins> <br>
<TabAtkins> .waterfall {<br>
<TabAtkins> display: grid-lanes;<br>
<TabAtkins> grid-template-columns: 100px auto;<br>
<TabAtkins> column-gap: 1em;<br>
<TabAtkins> column-rule: thin solid silver;<br>
<TabAtkins> grid-auto-flow: ROW????!?!?<br>
<TabAtkins> }<br>
<fantasai> grid-lanes: rows 100px 200px;<br>
<fantasai> grid-template-rows: 100px 200px;<br>
<fantasai> grid-template-columns: none;<br>
<fantasai> grid-auto-flow: normal;<br>
<emilio> fantasai: I think that resolves the biggest syntactical problem<br>
<emilio> ... instead of saying what the auto-flow value is, it decides which template prop we set<br>
<alisonmaher> q+<br>
<emilio> ... the shorthand also becomes useful for grid layout<br>
<emilio> astearns: Is that proposal in the issue?<br>
<emilio> fantasai: thought of it a bit too late<br>
<emilio> astearns: we should've deferred this then<br>
<emilio> ... to give people some time to look at it<br>
<emilio> fantasai: last part is what about grid-auto-flow<br>
<emilio> ... currently it takes {row, column, dense}<br>
<emilio> ... recently we introduced reverse-*<br>
<TabAtkins> [ row | column ] || dense<br>
<emilio> ... we think we should have a consistent interpretation<br>
<emilio> ... I think most people don't need this property on masonry except if you're doing reversing<br>
<astearns> s/masonry/grid-lanes/<br>
<emilio> ... we have row-reverse | column-reverse || wrap-reverse<br>
<emilio> ... so that's confusing, but also the interpretation of row and columns is confusing<br>
<emilio> ... so I think it'd be clearer if we named the keywords as primary-direction followed by secondary<br>
<emilio> ... so grid-auto-flow: row-column | column-row<br>
<emilio> ... so you can do [row | row-reverse] || [column | column-reverse]<br>
<florian> q?<br>
<florian> q+<br>
<emilio> ... so I think that might be a bit more straight-forward<br>
<astearns> zakim, close queue<br>
<Zakim> ok, astearns, the speaker queue is closed<br>
<lea> +1 for reusing `grid-auto-flow`<br>
<emilio> ... altogether, main point I want to put forward is that grid-lanes should have a keyword representing the suffix of the template property<br>
<emilio> ... and we should reuse grid-auto-flow matching grid<br>
<emilio> ... I think that addresses most of the key points on both sides of the argument<br>
<emilio> q?<br>
<ntim> what is primary vs secondary?<br>
<dholbert> For the part with primary direction followed by secondary direction, I'm a bit uneasy that folks will forget what primary/secondary are here (similar to how waterfall is sort-of rows but nobody thinks of it like that)<br>
<astearns> ack alisonmaher<br>
<emilio> alisonmaher: +1 to alan, would be useful to see this in the issue<br>
<emilio> ... I think it's a promising direction<br>
<emilio> ... but there are a few side effects<br>
<TabAtkins> yeah, this entire idea is new to me, and I don't think it solves several of the issues. take to the issue.<br>
<ntim> Is primary the flow direction? and secondary the track direction?<br>
<fantasai> primary is the first direction you go, secondary is the second direction you go<br>
<emilio> ... afaiu right now `grid-lanes: rows none` you'd get a columns lanes with the template of none<br>
<emilio> ... which means you can't have a row-based masonry without a track definition<br>
<emilio> ... we could potentially handle this with some grid-lanes-orientation thing or something<br>
<fantasai> You can, you would use grid-auto-flow, just wouldn't use the shorthand<br>
<emilio> ... and that'd always tell you which one to use<br>
<fantasai> grid-auto-flow *is* the orientation controlhere.<br>
<emilio> ... the other one is reusing grid-auto-flow would be a bit weird<br>
<emilio> ... so grid-lanes: columns and grid-auto-flow: column, it won't do anything because in masonry you can't have your flow items in the column direction when ??<br>
<emilio> fantasai: it can, the default auto-flow chooses based on templates, but non-initial values you get what you asked<br>
<emilio> alisonmaher: I think it'd be clear if we had a grid-lanes-flow<br>
<astearns> ack florian<br>
<emilio> florian: I understand the proposal is very fresh but I think it's useful to discuss it<br>
<emilio> ... it came out from the fact that we're at TPAC, this is an issue that needs solving and the ability to talk about this is great<br>
<emilio> ... even if we don't resolve I think it's important to discuss this to get it unstuck<br>
<emilio> ... I'd need more time to think about part 3 because that's very fresh<br>
<emilio> ... 1 and 2 make a lot of sense to me<br>
<emilio> ... we get around TabAtkins and ntim's formal objection<br>
<emilio> ... because you use columns to define grid-lane<br>
<emilio> ... and the low-level controls is mostly automatic but when it's not it does the thing ntim wants<br>
<emilio> ... but I'm optimistic<br>
<emilio> astearns: let's discuss this during the break<br>
<emilio> ... I think throwing around formal objections was inappropriate and unproductive<br>
<emilio> TabAtkins: was just repeating my words from a few weeks ago<br>
<emilio> astearns: I hadn't put it on the agenda because I knew we weren't going to get anywhere, but I readded I got told we'd talk about smaller topics<br>
<emilio> fantasai: we did<br>
<astearns> zakim, open queue<br>
<Zakim> ok, astearns, the speaker queue is open<br>
<emilio> astearns: anyways for now hallway conversation, let's go back to mixins for a bit<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-3530939442 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 14 November 2025 05:49:09 UTC