Re: [csswg-drafts] [css-grid-3][masonry] item-flow row vs. column in masonry layouts (#12803)

> This then raises the question: is it really worth pursuing this?

Firstly I appreciate all the work that has gone into `item-*`/`flow-*` proposal so far. I didn't raise these concerns initially as I was curious to see where it would go, and didn't want to throw up unnecessary roadblocks at that time.

However on my (very old) web developer hat[1], the `item-*` proposal creates significantly more confusion than the value it provides IMO.

If browsers ship this I expect there will be a lot of CSS content created about how this is the "new" way of doing things, however this content will only reach a minority of web-developers.
 
1. Additional cognitive overhead. The `grid-*`/`flex-*` properties aren't going anywhere. They appear on the majority of websites at the moment. Additionally they are used outside of the web (for instance in [react native](https://reactnative.dev/docs/flexbox) as one example). All/most web developers will have to learn the existing properties simply as a result of their existing usage on the web platform (and beyond). If the `item-*`/`flow-*` properties appear, and start being used, its pure additional overhead for in the general case (as most things simply map back onto an existing property).
  In an ideal world maybe it would have been better to have a unified set of properties from the beginning, but this isn't the world we live in. 

2. Creating a parallel structure of properties creates confusion when used together. This will be problematic in existing codebases. Say a codebase uses the `flex-*` properties, and a well meaning web developer comes along and uses `item-flow` or similar. This creates surprise for a web-developer who isn't familiar with these new properties ("I'm sure it should be vertical - I have `flex-direction: column` set"). Yes devtools will help - but it will be surprising to a lot of web developers.

3. Unnecessary debates about which way is better. Like most things there are tradeoffs about which approach you might take within a particular codebase. However by providing a "new" way, lots of developers will insist their "old" / "new" way is better ad-nauseam. I've already seen this with other features within CSS where we've provided syntactic sugar over something, and generally its not productive (see also general discussions about code formatting).

TL;DR the potential benefit to the `item-*`/`flow-*` properties doesn't outweigh the negative aspects.

<hr>

Lastly with my implementor hat on - a minor point - but an important one. The `item-*` proposal starts to tie CSS features together, multiplying work to support some new addition to a layout (e.g. instead of just supporting a feature in one layout mode, need to support in all).

Historically all browser engines have been terrible at implementing features across layout modes in a timely manner. As a recent example supporting `align-self` etc in abspos, and block layout. Blink was the first to ship this and so received most of the compat pain, but `align-self` in abspos for example was very close to not shipping due to the number of regressions we received initially. While we should try and do better - but history is a sobering counterpoint.

(Not to mention `align-content:baseline` is completely broken in every browser as another recent example - e.g. we might have to spec that it does nothing).

[1] Yes I was a web developer once upon a time!

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


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

Received on Wednesday, 12 November 2025 22:31:28 UTC