- From: Miriam Suzanne via GitHub <noreply@w3.org>
- Date: Thu, 13 Nov 2025 19:46:32 +0000
- To: public-css-archive@w3.org
Yeah, I have no strong attachment to the `item-*` proposal, but also don't consider it to be the core thrust of the TAG review – which said that layout properties "could be more unified to some degree". I agree with that! And don't think it requires us to force things. But it's why I like re-using grid track definitions as much as possible. I think it's a good counter to the desire for everything to be it's own bespoke syntax with special unique powers. With my current web developer hat on, I already know that `grid-auto-flow: row` requires me to define a set of `grid-template-columns` for items to flow into. Otherwise `grid-auto-flow: row` gives me a single column. The terms aren't connected, but I understand the logic of it anyway. We fill the row axis before wrapping to a new row. Picking up a new track-based layout mode that uses those same columns with the same auto-flow makes sense to me! Even if the rows aren't aligned, I use `row-gap` for spacing. That's fine. I think of row/column like inline/block – a logical axis, not a specific alignment. I don't need a whole new mental model based on how things will look. My existing understanding maps directly to the new thing. > …and when you need to create more implicit tracks to fit stuff, `grid-auto-flow: rows` is paired with `grid-auto-rows`, meaning that rows is referring to row tracks as the layout unit it cares about. This just isn't the way grids are _actually used_. I almost never set (or see others set) `grid-auto-rows`. The most common grid definition is just defining columns, without changing the flow or the row-sizing. Rows generally don't get sized until there's a full template with both columns and rows. > Grids are hard to apply any of this logic to, since they have "shape of layout" pointing in both directions That's only true from a theoretical perspective. There's a long history of providing extrinsic layout on the inline axis (sizing columns), while allowing the block axis to resize based on contents (auto rows). Authors mostly think of grids in terms of the column sizing. We almost never use `auto` for columns, because auto max-content sizes are wildly unreliable and mostly known for blowing-out grids with accidental horizontal overflow. We almost always use `auto` for rows, because we need somewhere for content to flow given the column constraints. _That's the same way I expect to use `grid-lanes`_. (Which is why I can hardly imagine a case where I would trust `repeat(auto-fit, auto)` to give me reliable results.) -- GitHub Notification of comment by mirisuzanne Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12803#issuecomment-3529447459 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 13 November 2025 19:46:33 UTC