- From: Sebastian Zartner via GitHub <noreply@w3.org>
- Date: Sun, 01 Feb 2026 00:16:56 +0000
- To: public-css-archive@w3.org
While there was no one in the meeting to object the resolution, I do speak out a formal objection to the [last resolution](https://github.com/w3c/csswg-drafts/issues/10961#issuecomment-3820508516) now. @romainmenke @kizu @astearns @emilio @Loirooriol and others being against introducing `inline-grid-lanes` all brought up good arguments plus tried to provide some data, while the people _for_ introducing a single keyword only restated the arguments that were either already refuted or purely hypothetical. I strongly believe it is counter-productive to introduce the `inline-grid-lanes` and remove the indication that the single `inline-*` keywords are legacy. The main argument for introducing a single keyword was to avoid tripping up authors. Though that is only a hypothesis. And even if that were true, there will be plenty of sources teaching them that they need to use space separation in that case. > There is also no rush here. The first browsers to ship this could only ship `inline grid-lanes`. If this makes authors angry we can still add `inline-grid-lanes` in time before there is interop. Note that my objection only refers to _hastily_ adding the legacy variant and declaring the `inline-*` keywords as _not_ being legacy. As Romain wrote, when there's a strong complain from authors about a missing `inline-grid-lanes` and people are not happy when tought that they should use the two-value syntax instead, we can still introduce it at a later point. Though I'd claim that _not_ introducing the single-keyword variant pushes the awareness of inner and outer display types and the adoption of the two value syntax, which is more benefitial in the long term. > it doesn't cost anything for browsers to add this Requests for introducing aliases are normally declined by the WG arguing that those are very expensive to maintain, as they not only mean implementation adjustments but also spec, testing, and documentation changes. That's also why we don't have a `no-wrap` alias or `current-color`, `corner-radius`, or multi-keyword color names using dashes. But if the group changed their mind about that, I'd be in favor of introducing those aliases. Sebastian -- GitHub Notification of comment by SebastianZ Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10961#issuecomment-3829784658 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Sunday, 1 February 2026 00:16:57 UTC