[css-grid-3] Should there be an `inline-grid-lanes` legacy keyword for `display`?

[keithamus]

As per title; I haven't seen examples of display: inline masonry. I also think should ensure to include the legacy inline-masonry keyword if we're using display.

[Loirooriol]

We didn't add a legacy inline-list-item (dropped in #1495), block-ruby nor block-math (#5385), you need to provide 2 keywords for these combinations.

So I'm not convinced that we need inline-masonry, authors can just use inline masonry instead.

[bfgeek]

So I'm not convinced that we need inline-masonry, authors can just use inline masonry instead.

We should add it as a convenience (there isn't any reason not to). E.g. most developers will use just inline-grid and not inline grid, and would be unnecessarily surprised if inline-masonry isn't supported. We shouldn't make this more difficult unnecessarily.

Ian

[keithamus]

list-item is special and block is assumed; the only legacy variants are inline- prefixed. While
I’m indifferent about adding inline-masonry I was largely pointing it out for completeness otherwise IIRC it would be the only inside display value without an inline legacy variant.

[Loirooriol]

We shouldn't call these "legacy" if we are going to keep adding them whenever we add new inside display types.

[Loirooriol]

it would be the only inside display value without an inline legacy variant

Actually not, Houdini Layout adds layout() but not inline-layout().
It was removed by Ian in w3c/css-houdini-drafts@60ff1c2

[Loirooriol]

Renamed since now it's grid-lanes instead of masonry.

Agenda+ to decide whether to add a "legacy" inline-grid-lanes keyword.

[SebastianZ]

I've strongly in favor of not introducing a new legacy keyword. That allows to push the awareness of the double-keyword syntax of display.

Sebastian