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

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.

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.

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

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.

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

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

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

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

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

[css-grid-3] Update CSS-Grid-3 spec to use new grid-lanes syntax

Making these work:

display: inline-flex;
display: inline-grid;
display: inline flex;
display: inline grid;
display: inline grid-lanes;

and making this broken:

display: inline-grid-lanes

is not a good way to help developers understand what's happening.

I understand the desire to push developers into two-value syntax. The two-value syntax is better. But convincing developers to use it needs to come from teaching resources and news that it exists.

Just making display: inline-grid-lanes invalid is only going to confuse people. It's going to make them think Grid Lanes doesn't work as an inline container. That it has to be block.

Authors over implementors over specifiers over theoretical purity.

@jensimmons

@jensimmons I fail to see how this argument applies to inline-grid-lanes but not to inline-layout(), inline-list-item, inline-block-list-item, flow-root-list-item, block-math and block-ruby, which we avoided in the past.

I'm pretty strongly against us being knowingly dishonest in our specifications. And I believe we need to sort out the serialization question here, as it's a pretty integral part of this debate and not really a follow-up issue.

I think “knowingly dishonest” is vastly overstating the case.

@romainmenke

Then we also have to revisit inline-list-item, block-math, block-ruby as the same arguments would also apply to those keywords?

@romainmenke No, I think we can reasonably say that the inline-* pattern is for inner display types only, and there's no block-* pattern.

Even with just inline-*, it's not clear if the arguments supporting inline-grid-lanes also apply to inline-list-item, inline-block-list-item and inline-layout().

@Loirooriol

@Loirooriol So far it's been "all default-block-level inner display type values get inline-* keywords". If we add inline-grid-lanes that keeps the pattern. Not adding inline-grid-lanes creates a fixed, historically-determined set ("legacy"). Neither of these options requires adding all the extra values you're mentioning, that we don't have.

layout() is an inner display type that defaults to block-level, so the pattern isn't working.

[grid-lanes] Make tests not depend on inline-grid-lanes alias

Bug 2018808 [wpt PR 57972] - [grid-lanes] Make tests not depend on in…

@kizu

With one engine already shipping this feature and at least one actively being worked on, I'd like to revive this discussion in the hope that we can find a viable solution before it's too late.

Repeating my previous statement:

RESOLVED: remove inline-grid-lanes for now, but we are open to adding it again if there is evidence it solves a problem

This was already a good compromise, in my opinion, which would keep the consistency @fantasai is asking for. And I still didn't read a strong argument against that.

Reading through the comments again, it seems nobody actually gave an proper argument against this first resolution. (Please let me know if I missed it! This thread got quite long...)
As @kizu stated earlier, any negative reaction of authors for not introducing a single-keyword value is speculative. And that resolution let the door open for introducing it if there's request for it.

@fantasai wrote:

@Loirooriol So far it's been "all default-block-level inner display type values get inline-* keywords". If we add inline-grid-lanes that keeps the pattern.

This hasn't been written down anywhere before, has it? At least I couldn't find any resource using this definition as a reason for having the inline-* keywords.

Not adding inline-grid-lanes creates a fixed, historically-determined set ("legacy").

The spec and different resources explaining the two-value syntax like MDN already outline the inline-* keywords as "legacy". The resolution I objected to asking to "remove [the] indication that inline- syntaxes are legacy or otherwise inferior" not only targets the spec but also those resources.

I'm pretty strongly against us being knowingly dishonest in our specifications.

What are you actually referring to here?

And I believe we need to sort out the serialization question here, as it's a pretty integral part of this debate and not really a follow-up issue.

@mirisuzanne wrote:

Any chance we can avoid using the 'legacy' option for serialization?

I don't think serialization is such a big deal. Though if we want to keep advocating for the two-value syntax, I think it should serialize as two values even if we introduce the single-keyword variant.
In any case, it should be consistent for inline grid-lanes and inline-grid-lanes.

So, let's bring this to the agenda again with the main questions being:

Are there objections against the first resolution?
Do we want to keep advocating for the concept behind inner and outer values?
Depending on the above, how to serialize the value?

Sebastian

@benface

I've been teaching the multi-value syntax for years, and authors find it useful for understanding the various things display is doing. But it won't see broad teaching & adoption until there is functionality that relies on it. Authors don't get a lot of training in CSS, they mostly read how-to articles about things they are trying to achieve. If we're not willing to put any features entirely in the new syntax, it will remain a useful curiosity that only some developers encounter.

I think the most attractive way to put functionality behind the multi-value syntax is with longhands — especially the much-needed display-visibility (name TBD) #12046 mentioned by @benface earlier.

I also think authors are entirely capable of learning that inline grid-lanes is the proper syntax, if we stick to the original resolution. And when they ask why, they will discover the multi-value syntax – and that it is broadly available. That's good for everyone.

To me, continuing with two syntaxes only increases an inconsistency of the language. We're dragging out the point of confusion, rather than making a clean break. Deprecating the old syntax makes things more consistent and learnable than trying to keep both syntaxes alive just in case someone tries the old one for a new feature.

(but I did and do not feel strongly enough to object)

@fantasai

@fantasai @jensimmons @bfgeek I think you were the ones with the strongest opinion for introducing the single-keyword value.
Could you please provide some feedback to my previous comment, especially regarding the three questions at the end, so we can make progress on this issue and hopefully find a solution acceptable for everyone?

Sebastian

Bug 2018808 [wpt PR 57972] - [grid-lanes] Make tests not depend on in…

Navigation Menu

Repository navigation

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

64 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

Activity

Loirooriol commented on Sep 27, 2024

bfgeek commented on Sep 27, 2024

keithamus commented on Sep 27, 2024

Loirooriol commented on Sep 27, 2024

Loirooriol commented on Nov 11, 2024

Loirooriol commented on Jan 2, 2026

SebastianZ commented on Jan 2, 2026

jensimmons commented on Jan 6, 2026

Loirooriol commented on Jan 6, 2026

64 remaining items

fantasai commented on Feb 23, 2026

astearns commented on Feb 23, 2026

fantasai commented on Feb 23, 2026

Loirooriol commented on Feb 23, 2026

fantasai commented on Feb 23, 2026

Loirooriol commented on Feb 23, 2026

SebastianZ commented on Sep 7, 2026

mirisuzanne commented on Sep 8, 2026

SebastianZ commented on Oct 13, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

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