- From: Roman Komarov via GitHub <noreply@w3.org>
- Date: Fri, 23 Jan 2026 23:16:57 +0000
- To: public-css-archive@w3.org
One note about the current usage: I am not sure if it shows anything, as even people who know about the multiple keywords syntax won't necessarily use it in practice. Why use something that works the same but has [much worse](https://caniuse.com/mdn-css_properties_display_multi-keyword_values) browser support? If anything, in my practice, I remember wanting to use the longhands for inner and outer displays separately and not being able to, but I don't remember needing to use the shorthand with two values. - - - Another similar comparison of a newer syntax vs. a legacy syntax and not maintaining the legacy syntax for the new thing: colors. Usage-wise, it is a similar case to `rgba()` with spaces & slash syntax compared to the commas: - `language:CSS "rgba(0, 0"`: https://github.com/search?q=language%3ACSS+%22rgba%280%2C+0%22&type=code — 15M files - `language:CSS "rgba(0 0"`: https://github.com/search?q=language%3ACSS+%22rgba%280+0%22&type=code — 11K files. And it is also a case, where I don't see any reason to use the new syntax in practice, as it has clearly worse browser support. But for the new color functions like `oklch()` we introduced _only_ the new syntax, without the support of the legacy one. And people did learn it and started using it. It will be consistent to not introduce `inline-grid-lanes` if we consider these “short” values legacy. The Web Platform Design Principles say, [“Leave the web better than you found it”](https://www.w3.org/TR/design-principles/#leave-the-web-better). > Consistency with existing problematic design patterns is not a good reason to propagate those patterns in newly specified Web APIs or platform features. Where possible, build new web capabilities that improve the overall platform quality by mitigating existing defects. Do we consider having a “short” value (that is not shorter) alongside two keywords a problematic design pattern? If we were to add another 10 different display types, would we continue adding duplicate values for consistency? Another principle says, [“Prefer simple solutions”](https://www.w3.org/TR/design-principles/#simplicity). > Simple solutions are generally better than complex solutions, although they may be harder to find. Simpler features are easier for user agents to implement and test, more likely to be interoperable, and easier for authors to understand. It is especially important to design your feature so that the most common use cases are easy to accomplish. What is simpler: having two alternatives for the same thing, or just one? Is this added complexity granted by its use case, or do we have the most common use cases covered by regular `grid-lanes`? -- GitHub Notification of comment by kizu Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10961#issuecomment-3792979287 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 23 January 2026 23:16:58 UTC