Re: [csswg-drafts] [css-flexbox][css-grid] Unifying grid-auto-flow and flex-flow (#11480)

I like the idea of having a more unified approach to working when using different layout modes, and this proposal feels like it's going in the right direction for that. I see *a lot* of developers who pick either flexbox or grid and stick with it, to their detriment, because it's what they are familiar with. If there's more common ground with how they work (and future layouts, like masonry and whatever might come after that), I think it'll help bridge the gaps people currently experience.

But because developers already tend to stick with what they know, I have concerns about the proposed naming by @tabatkins and @fantasai.

I understand wanting to take a more semantically correct approach with a focus on tracks, but I fear it will negatively impact adoption. This might seem absurd, but I've had multiple people tell me they have had a PR rejected because they used a logical property because "no one knows what those are." 

I also frequently get people complaining about the readability of modern CSS in the comments on my videos. Much of it has *nothing* to do readability, but is simply because I'm using features they're unfamiliar with.

Other than `item-slack`, which is a completely new feature, all the others have a basis in features that already exist in one of the layout modes, and I think the naming leaning into those familiar properties is a better approach.

For example, with `item-wrap` vs `item-cross`, I realize something other than `wrap` fits better. As @tabatkins described, it's not only for controlling wrapping. However, developers are already familiar with `flex-wrap` and the behavior of the two will be identical from what I understand (in the flex context at least, and very similar in others). Because of that familiarity, I feel that if someone came across `item-wrap: nowrap` they'd immediately understand what that declaration is doing, even if they've never seen it before. If they came across `item-cross: nowrap`, most people would have no idea what it was doing at first glance, and while it would be nice to think they'd take the 20 seconds it would require to find out, many won't bother.

The primary reason people would understand `item-wrap` at first glance would be because those people would already be familiar with `flex-wrap`, and maybe the naming there has some inherit issues, and I realize that coming in with a new spec means that there is the opportunity to improve on how we might have named things in the past, but I also think it adds avoidable inconsistencies to CSS. Most developers already see CSS as a chore, and in my opinion, adding inconsistent naming for properties with similar behaviors isn't going to help.

Maybe the idea is, down the road, new developers will never have to learn `flex-wrap` or `flex-direction` because they can learn `item-wrap` and `item-track` from the get go. And yeah, we'll hopefully get there one day, but if people still have PRs rejected because they use `margin-block`, I have a feeling in the real world, this might not happen as quickly as we'd like.

-- 
GitHub Notification of comment by kevin-powell
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11480#issuecomment-2763670194 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Saturday, 29 March 2025 16:38:33 UTC