- From: Tab Atkins Jr. via GitHub <noreply@w3.org>
- Date: Fri, 12 Dec 2025 22:49:35 +0000
- To: public-css-archive@w3.org
"Reopening" this issue to discuss it at a high level!
Basically, now that we've spent a lot of time working through the syntax discussions and trying to come up with a good design that does work for all three layout modes (and more in the future), I and @bfgeek are of the opinion that we can't, in fact, do it.
1. Flexbox and Grid and Grid Lanes are indeed all very similar in a number of aspects, but they're not *identical*, and trying to come up with a syntax design that covers all three of them (and more in the future) ends up either leaving us with a suboptimal set of terms (concepts which only *properly* apply to *some* of the layouts and not others) or an overly-generic set of terms that doesn't actually help authors understand the concepts either. (Several of us - me, fantasai, alison, kevin, florian, ydaniv, and others - worked *really hard* during TPAC to come up with a good set of shared concepts for "flow", and we *failed utterly* to come up with *anything* that didn't end up with a 50/50 split on people's intuition of what the names did.)
2. Beyond the difficulties we've had with coming up with an omnibus set of `flow` properties, every layout mode has its own little quirks that only apply to it and no other, but which are clearly in this common wheelhouse *generally*, which also results in some awkward design choices. For example:
* Flexbox has a `nowrap` concept, but Grid doesn't (and Grid Lanes either doesn't, or doesn't have "wrapping" at all, depending on how you choose to look at it).
* Grid Lanes has a "tolerance" concept, but Grid doesn't (and Flexbox might gain one, but it'll be a different concept, tho adjacent thematically).
* Grid and Grid Lanes both distinguish between "sparse" and "dense" placement, but Flexbox doesn't.
* Flexbox is gaining the ability to "balance" how it wraps, but that doesn't meaningfully apply to Grid or Grid Lanes.
* etc.
3. Doing this also ties our hands somewhat in the future. Any time we add a new concept to the shared property pool, we have to define how it works for *all* of the layout modes that use the pool. It's not possible for us to define it for only one, and then later spread it others when someone has a good idea for how it could work. For example, the "balanced wrapping" concept we're adding for Flexbox *must* be defined as doing *nothing* in Grid and Grid Lanes; if anyone ever comes up with a useful "balancing" behavior for them, we'll have to invoke it differently somehow, which defeats the purpose of "shared" properties.
If every layout mode uses its own set of properties, we *can* do things one at a time, and if they end up identical, we can use identical naming and syntax (save for the property name prefix), so authors still get to transfer their knowledge over easily. But we can make that choice on a case-by-case basis and without a ticking deadline!
-------
So, Agenda+ to propose that we reverse our previous resolution, and reject the TAG's feedback in this regard. It was a good idea, but it just doesn't work well in practice. Instead, Flexbox, Grid, Grid Lanes, and future layout modes will, generally speaking, use their own sets of properties for things. They might share names and even syntaxes if identical, and in some cases it's okay to directly share properties (like Grid Lanes reusing `grid-template-columns` and `grid-column` from Grid), but these will all be individual decisions made by the editors and the WG, not an enforced sharing in a single namespace.
--
GitHub Notification of comment by tabatkins
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11480#issuecomment-3648421097 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 12 December 2025 22:49:35 UTC