- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Thu, 29 Jan 2026 21:37:56 +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: Add inline-grid-lanes, and remove indication that inline- syntaxes are legacy or otherwise inferior.` <details><summary>The full IRC log of that discussion</summary> <dholbert> scribenick: sgill<br> <sgill> iank_: this was resolved in a previous call<br> <sgill> bunch of people who were in favor of inline- keyword were not on call<br> <sgill> i want to present the case more clearly<br> <sgill> if you are a web developer you could have gone without encountering inline flex syntax<br> <sgill> you might try to write inline-grid-lanes based off this and not know why it doesn't work<br> <dholbert> (with space between "inline" and "flex")<br> <sgill> this syntax has been around for a while and amount that it is used compared to dash variant is couple of magnitudes different<br> <sgill> it doesn't cost anything for browsers to add this<br> <oriol> q+<br> <sgill> so we should do it to not cause devs to be angry<br> <TabAtkins> q+<br> <astearns> ack oriol<br> <sgill> oriol: while i agree that it does not cost a lot to add, we decided on having space separated<br> <sgill> if we keep adding old syntax it is not really legacy<br> <fantasai> +1 it would need renaming in the spec<br> <sgill> becomes confusing because we keep adding both<br> <sgill> i'm not convinced that requiring the space will be more confusing since authors will need to already need to learn the grid lanes keywords<br> <sgill> they could also learn about the space syntax at the same time<br> <astearns> q+<br> <sgill> i prefer not to add legacy but if we do should not call it legacy<br> <kizu> q+<br> <sgill> iank_: so your summmary is basically coming from the spec wise?<br> <sgill> oriol: yeah will not object but the spec should use different terminology<br> <TabAtkins> run-in<br> <sgill> iank_: reason we adedd display inside display outside it to support other types like run in<br> <sgill> nobody has shipped it<br> <dholbert> s/it/display:run-in/<br> <sgill> iank_: you will make web developers angry for no good reason<br> <astearns> ack TabAtkins<br> <sgill> TabAtkins: i also support adding the dash version. already common pattern that is expected even if the space version exists<br> <sgill> going to be expected by authors and does not cost anything. really only just adding a parsing test<br> <sgill> removing just for spec purity sense loses against author expectations<br> <sgill> astearns: i don't really care though inline-grid and inline-flex are used a bunch<br> <sgill> is inline-grid-lanes going to be as prevalent?<br> <sgill> iank_: maybe<br> <sgill> TabAtkins: maybe<br> <oriol> q+<br> <sgill> astearns: we assume authors are going to be angry but we don't really have evidence<br> <sgill> astearns: this might be a good inflection point to stop adding this legacy thing since we don't have evidence authors are confused<br> <astearns> ack astearns<br> <sgill> iank_: but it is effectiveley free<br> <fantasai> It's free for implementations, the question is what's the impact on authors.<br> <sgill> astearns: yes and no because of the one small test but we are setting precedent<br> <astearns> ack kizu<br> <emilio> q+<br> <sgill> kizu: i am against adding this and will not object but most of what i have to say is in the last comment on the issue<br> <sgill> don't think usage of inline flex or inline grid is indicative of need<br> <sgill> imo nobody will use them when there is already the dashed version<br> <emilio> +1, was going to argue the same<br> <sgill> why would you use a less supported version?<br> <sgill> we did introduce a new color syntax that uses spaces<br> <sgill> do we have data that authors were angry about this?<br> <sgill> if not i don't think they would be angry about this<br> <sgill> similar search on github shows same differences in magnitude of usage<br> <sgill> also question of what are we consistent with? what do we keep using? is the old one legacy and is worse? if so why do we keep adding it?<br> <Kurt> q+<br> <sgill> i don't think authors care if there is a dash or not, they will learn it<br> <sgill> specifically for grid lanes, while there may be cases you would need inline i would like to see examples<br> <sgill> we could always introduce later<br> <dholbert> q+<br> <sgill> did a small poll on mastadon, twice as many people prefer having space separated but may not be representative<br> <sgill> iank_: to respond to last point: your audience may be heavily css skewed as opposed to full stack dev which may touch css once in a blue moon<br> <sgill> this was me previously!<br> <sgill> i would have gotten very angry this was not consistent<br> <astearns> zakim, close queue<br> <Zakim> ok, astearns, the speaker queue is closed<br> <sgill> kizu: i mean it will probably be inline-grid-lines since it will come from tailwind<br> <sgill> iank_: education wise more and more people are going to llms and none of them teach the space separated<br> <TabAtkins> and note that jensimmons makes the exact same "confusing for authors to leave out" argument https://github.com/w3c/csswg-drafts/issues/10961#issuecomment-3712529717<br> <astearns> ack oriol<br> <sgill> oriol: +1 to what Roman said<br> <dholbert> s/be inline-grid-lines/be an .inline-grid-lanes class name/<br> <sgill> forgot to mention there are arguments in other cases we agreed not to add a single keyword to represent them<br> <jensimmons> q+<br> <sgill> should we add them to the old ones now?<br> <astearns> zakim, open queue<br> <Zakim> ok, astearns, the speaker queue is open<br> <astearns> q+ jensimmons<br> <sgill> iank_: my position has evolved<br> <TabAtkins> we shouldn't add the block-*, that doesn't have a precedent. inline-list-item is fine if we want it<br> <astearns> Zakim, close queue<br> <Zakim> ok, astearns, the speaker queue is closed<br> <sgill> my argument would be to add the dash variants since they are commonly used<br> <astearns> ack emilio<br> <sgill> emilio: was going to make a similar argument to Roman<br> <sgill> don't understand this is the hill we are dying on<br> <sgill> we determined legacy syntaxes are legacy and we evolved from that<br> <sgill> allows you to decouple inline and outside display<br> <sgill> not sure i buy the argument of the llm thing<br> <sgill> can apply that to other things<br> <sgill> iank_: they are orders of magnitudes used more than the other ones<br> <sgill> we named the dash variants "legacy" but web ecosystem does not see a benefit to the space<br> <sgill> emilio: don't agree.<br> <sgill> fantasai: creates a mental model with the outer and the inner<br> <sgill> right now it's a list of different modes that are mashed together vs having the separation<br> <sgill> helps the developer understand what is happening with the different display types<br> <oriol> inline-grid-lanes can cause confusion if it's (inline-grid)-lanes or inline-(grid-lines). `inline grid-lanes` is clearer<br> <TabAtkins> inline-block is actually "inline flow-root"<br> <sgill> emilio: doesn't help that inline-block is "inline flow-root"<br> <sgill> still don't think it's a good idea to add the new keyword otherwise we will not move on<br> <sgill> i don't agree that even though the cost is tiny they are worth adding<br> <sgill> TabAtkins: had this discussion when we added grid<br> <astearns> ack Kurt<br> <sgill> Kurt: want to add one piece that is different<br> <fantasai> emilio: We hadn't shipped 2-value syntax yet when we added grid<br> <fantasai> TabAtkins: we were just about to though ...<br> <sgill> my understanding that with grid lanes a lot of the messaging is around grid<br> <sgill> there would be a discrepancy between the two<br> <lea> q?<br> <astearns> ack dholbert<br> <sgill> dholbert: might be worth having separate discussion on what means for dash to be legacy<br> <sgill> fantasai: if we add this then we basically say that it isn't<br> <TabAtkins> (as noted, historically we add a new display type roughly every 5-ish years. that's fine)<br> <sgill> dholbert: authors are probably using dash syntax because of muscle memory<br> <sgill> might be opportunity to educate but authors still might think it's pedantic and is a barrier<br> <astearns> ack jensimmons<br> <sgill> jensimmons: i think this is tricky because all arguments are true<br> <florian> q+<br> <sgill> i agree what is best for authors<br> <sgill> if we don't provide legacy then there will be this extra teaching of the new and why it is better. but majority of devs will not get that memo<br> <sgill> inline-grid-lanes is probably rare but people will probably use syntax that they use to, or from llm, or whatever they have been taught<br> <miriam> q+<br> <emilio> Why does this argument not apply to e.g. `oklab()`?<br> <sgill> too easy to use the old syntax and not worry about it<br> <emilio> (Or any other modern color for that matter)<br> <sgill> don't think it's right to put this blocker in front of devs<br> <sgill> astearns: personally not convinced we should add it. would like evidence of dev angry<br> <sgill> emilio: don't understand why this does not apply to color syntax or other things<br> <sgill> astearns: if we wait for evidence, then we run risk of this coming back up<br> <sgill> willing to resolve to adding it to get passed this<br> <sgill> florian: i think it's ok and we should not give up on space syntax<br> <sgill> there are more interesting combinations<br> <sgill> as long as we are not giving up on that i don't care that strongly if we don't introduce it this time<br> <sgill> if we do add it, it is ok<br> <sgill> miriam: i think Jen's probably right that most authors probably won't know about it<br> <sgill> can say that when i teach the space separated syntax authors appreciate it. what the outside and inside represent<br> <sgill> authors did not understand and find it helpful when they learn it<br> <sgill> sort of opposed to adding more dash but idk... there is a practicality and i wouldn't be a blocker<br> <sgill> astearns: somewhat resistant to a poll since what happened in last resolution<br> <sgill> sounds like there are people for and against, but against will not object<br> <sgill> fantasai: this is an inflection point<br> <dbaron> I probably lean somewhat towards having the dash keyword. I think deprecations / removals are expensive and we don't have that strong a reason to want to push people towards the space-separated syntax (and make them struggle with it being missing).<br> <sgill> if we decide this is the pattern we want then we should remove any indication of legacy<br> <sgill> astearns: can we resolve on adding this one dash and never again?<br> <sgill> florian: we are not resolving on that we are resolving on just adding<br> <astearns> s/and never again//<br> <sgill> fantasai: find it nonsensical to say we are going to add this and call it a legacy<br> <sgill> have to revert our previous claims and move forward with it being the proper or we resolve to not adding to it now<br> <sgill> florian: seems stronger than necessary<br> <sgill> in this case grid has it<br> <sgill> not interested in making a binding precedent<br> <TabAtkins> no reason to try and say "inline-foo is always right, inline foo is wrong"<br> <sgill> fantasai: not binding but if we add it now it is not legacy<br> <fantasai> PROPOSED: Add inline-grid-lanes, and remove indication that inline- syntaxes are legacy or otherwise inferior.<br> <florian> -0<br> <dbaron> +1<br> <emilio> NaN<br> <oriol> -1, not objecting<br> <sgill> RESOLVED: Add inline-grid-lanes, and remove indication that inline- syntaxes are legacy or otherwise inferior.<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-3820508516 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 29 January 2026 21:37:57 UTC