- From: Kevin Babbitt via GitHub <noreply@w3.org>
- Date: Tue, 10 Feb 2026 21:15:54 +0000
- To: public-css-archive@w3.org
> Can we do a compromise? > > * add `inline-grid-lanes` > * keep all the `inline-*` (including `inline-grid-lanes`) marked as legacy syntax > * decide not to add `inline-*` variants in the future, with the option to revisit later I was thinking along the same lines myself and would support such a compromise. Leaning on the TAG design principle of [consistency](https://www.w3.org/TR/design-principles/#consistency): > Since the web platform has gradually evolved over time, there are often multiple conflicting precedents which are mutually exclusive. You can weigh which precedent to follow by taking into account prevalence (all else being equal, follow the more popular precedent), API ergonomics (all else being equal, follow the more usable precedent), and API age (all else being equal, follow the newer precedent). As a general principle, I think it makes sense to lean into the multi-keyword syntax, because it's more flexible. Variable substitution can be used for one term or the other, for example. That makes it more ergonomic. Going way back in the conversation, I agree we don't need combined values for any of the following: > We didn't add a legacy inline-list-item (dropped in https://github.com/w3c/csswg-drafts/issues/1495), block-ruby nor block-math (https://github.com/w3c/csswg-drafts/issues/5385), you need to provide 2 keywords for these combinations. However, it is also the case that `inline-grid` is way more prevalent then `inline grid` in current usage. I think it's reasonable for authors to expect that if they go in and append `-lanes`, it will work. So I would be in favor of introducing `inline-grid-lanes` for the specific reason that grid-lanes shares a name with a layout that already has a combined value. -- GitHub Notification of comment by kbabbitt Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10961#issuecomment-3880757116 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 10 February 2026 21:15:55 UTC