Re: [csswg-drafts] [css-grid-3] if using `display` we should provide examples for `inline grid-lanes`, and include the `inline-grid-lanes` legacy fallback (#10961)

I was very surprised by this resolution and the arguments that led to it.

- historical data will always favor legacy syntax, using that as an argument to keep doing the legacy thing will block any progress
- llm's just regurgitate whatever they have seen the most
- any actual feedback from authors was ignored in, while hypotheticals where given weight

--------

Obviously historical data will indicate that `inline-flex` is much more widely used than `inline flex`. There never was in incentive to use `inline flex` but there was always a reason to use `inline-flex`, for better browser version support. This sort of stuff trickles down into articles, guides, stackoverflow posts, llm training data, ... and takes a very long time to change.

This doesn't imply that authors are opposed to `inline flex` or that they would have issues with only `inline grid-lanes`.

Authors might collectively be choosing to use a worse syntax (`inline-flex`) for the good of end users who are still on older browser versions.

Instead of speculating about this, isn't it better to gather actual data?

--------

If you ask ChatGPT (hadn't touched that monstrosity in years...) to create a masonry layout it will also spew out that which it has been trained on, which are some of the articles around earlier designs:

```
.masonry {
  display: grid;
  grid-template-columns: repeat(auto-fill, minmax(250px, 1fr));
  grid-template-rows: masonry;
  gap: 1rem;
}
```

If you then point it to the latest draft spec it will use `display: grid-lanes;`.
If you ask it to make it `inline` it will use `inline-grid-lanes` because that is explicitly mentioned in the spec.
If you ask it to use the multi keyword syntax to make it `inline` it will use `inline grid-lanes`.

So it seems that llm's will just produce for authors whatever we spec, write about, document,...

If we remove `inline-grid-lanes` from the spec I have no doubt that an llm will suggest `inline grid-lanes` as it seems capable of this.

--------

What I understand least of all is that some of us are concerned that authors will be upset about this but there doesn't seem any source for this concern?

Has there been a poll or article about this or some way to gather this feedback?
From the minutes this seems to have been an impression, but not something that was actually tested.

### poll by kizu

While @kizu [did a poll](https://front-end.social/@kizu/115947014705147754) that seemed to favor not adding `inline-grid-lanes`. It might not have had massive reach and I can imagine that people who follow @kizo are already more knowledgeable about CSS than others it is still a real data point.

### MDN docs

MDN warns against using multi keyword syntax:

https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Properties/display

> Note: To be sure layouts work on older browsers, you may use single-value syntax, for example display: inline flex could have the following fallback

https://developer.mozilla.org/en-US/docs/Web/CSS/Guides/Display/Multi-keyword_syntax#what_about_the_old_values_of_display

> The single values of display are described in the specification as legacy values, and currently you gain no benefit from using the multi-keyword versions, as there is a direct mapping for each multi-keyword version to a legacy version, as demonstrated in the table above.

So that isn't great if we want authors to adopt the multi-keyword syntax...
This goes back to the incentives for authors.

### Stylelint rule

Over at Stylelint we have been rushing to get a rule out given this thread.

Our intention was to create awareness of the multi-keyword syntax and promote its usage.
Thereby making it easier to introduce only `inline grid-lanes`.

This seemed a good moment for this because:
- the syntax has been supported in all browsers since mid 2023
- popular minifiers and transpilers will convert `inline flow-root` into `inline-block` anyway

What I didn't expect was the early feedback we already got there.

It seems that at least one author really wants their colleagues to only use the full multi-keyword syntax. See: https://github.com/stylelint/stylelint/issues/8958#issuecomment-3759008709

They reason that it is much easier to understand how the `display` property works if you use the full syntax.

I am less in favor of using the full notation over shorter values but I do agree with the overal point they're making.

It is something I have also observed, that colleagues will use `inline-flex` when any `inline` would have worked, just because that is what worked last time. By making it one keyword authors seem to associate specific traits with the composite instead of with either a specific inner or outer display mode.

We hoped to ship this rule out and make it a default in a commonly used preset so that authors would be confronted with this and tell us how angry they are about `inline flow-root`.

--------

The few actual author signals seem to favor the previous resolution.
I don't understand why we reversed it without real data.

I am in favor of going back to the previous resolution and gathering author feedback first.

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


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

Received on Friday, 30 January 2026 06:58:25 UTC