- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 07 Jan 2026 17:45:42 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``[css-grid-3] if using `display` we should provide examples for `inline grid-lanes`, and include the `inline-grid-lanes` legacy fallback``, and agreed to the following: * `RESOLVED: remove inline-grid-lanes for now, but we are open to adding it again if there is evidence it solves a problem` <details><summary>The full IRC log of that discussion</summary> <JoshT> fantasai: there was a question to add inline-grid-lanes or not<br> <JoshT> ... we have had inline-table, inline-block, etc, because display used to be single keyword in CSS2<br> <JoshT> ... but we also split it into two: inner and outer<br> <JoshT> ... intent was to be the new way forward<br> <JoshT> ... but because we already shipped inline-flex, etc, we were stuck with the legacy keywords<br> <JoshT> ... but we've inline- every other display type. why not grid-lanes?<br> <JoshT> ... would it confuse authors?<br> <JoshT> ... argument for not doing it is this is the new way forward. is this a good point to stop adding them and prompt authors to learn about display: outer inner<br> <oriol> q+<br> <astearns> ack oriol<br> <alisonmaher> q+<br> <JoshT> oriol: as I said in issue, I don't think this is the point where we choose. I think we already have precedent where we didn't add a legacy keyword like inline-list-item keyword<br> <fantasai> chrissov summarizes the inline value space in https://github.com/w3c/csswg-drafts/issues/10961#issuecomment-3717941923<br> <JoshT> ... also for custom layout function for Hudini<br> <JoshT> ... same with ruby types<br> <JoshT> ... and for math, we don't have block-math, block-ruby<br> <JoshT> ... and now I'm surprised people are saying this is a problem<br> <JoshT> q+<br> <emilio> +1<br> <astearns> ack alisonmaher<br> <JoshT> alisonmaher: I'm supportive of adding, we have it for grid<br> <dbaron> The multi-value syntax is what the MDN compat table calls "multi-keyword values", right? https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Properties/display<br> <kizu> q+<br> <JoshT> ... if switching between the two, it might be confusing why it doesn't work<br> <kbabbitt> scribe+<br> <kbabbitt> JoshT: counter argument for oriol is the ones you mentioned are ones authors are unlikely to use<br> <kbabbitt> ... whereas like alisonmaher said, people are more familiar with inline-grid and will assume inline-grid-lanes exists<br> <astearns> q+<br> <astearns> ack JoshT<br> <astearns> ack kizu<br> <JoshT> kizu: I think similar to how ruby and flow-root, etc, there is no need to do the other one, I think for grid-lanes,<br> <JoshT> ... while with inline-grid there are more use cases for it, grid-lanes wouldn't normally be inline<br> <JoshT> ... if you actually need inline grid-lanes, you probably know a lot about how display works<br> <djmarland> q+<br> <JoshT> ... I don't think 99% of authors will ever reach out about this<br> <JoshT> astearns: should we not add this until there is evidence it solves a problem<br> <astearns> ack astearns<br> <astearns> ack djmarland<br> <JoshT> djmarland: legacy syntax was declared as legacy, so if we keep adding to it, it's not really legacy<br> <JoshT> astearns: easy to add this, but is it justified? anyone feel strongly that we need it now?<br> <romain> +1<br> <oriol> +1<br> <JoshT> ... I'm lacking a strong advocate<br> <miriam> +1<br> <emilio> +1<br> <JoshT> PROPOSED: remove inline-grid-lanes for now, but we are open to adding it again if there is evidence it solves a problem<br> <JoshT> RESOLVED: remove inline-grid-lanes for now, but we are open to adding it again if there is evidence it solves a problem<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10961#issuecomment-3720021476 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 7 January 2026 17:45:43 UTC