Re: [csswg-drafts] [selectors-5][css-syntax] Resolve to use `'/' [<ident> | <function>] '/'` syntax for all future combinators (except for good reason) (#12451)

The CSS Working Group just discussed ``[selectors-5][css-syntax] Resolve to use `'/' [<ident> | <function>] '/'` syntax for all future combinators (except for good reason)``, and agreed to the following:

* `RESOLVED: Remove idref feature from the spec`
* `RESOLVED: add a note that we expect to use /-delimited idents or functions for future syntax expansion`
* `RESOLVED: Add a note about unused ascii punctuation`

<details><summary>The full IRC log of that discussion</summary>
&lt;emilio> lea: this has come up in several discussions<br>
&lt;emilio> ... down the line unless strong reasons appear to use ascii art<br>
&lt;emilio> ... it's often been mention that future combinators should use slashes<br>
&lt;emilio> ... I wonder if we could resolve around this<br>
&lt;emilio> ... there's generally confusion about how combinators work<br>
&lt;emilio> ... and you can't have combinators with readable name<br>
&lt;Rossen9> q?<br>
&lt;emilio> ... so might be useful to have that resolution<br>
&lt;TabAtkins> q+q+<br>
&lt;TabAtkins> q+<br>
&lt;emilio> ... that's basically it, just propose as a design principle<br>
&lt;emilio> ... without reasons to have different syntax we should go for that<br>
&lt;emilio> q+<br>
&lt;RRSAgent> logging to https://www.w3.org/2025/11/05-css-irc<br>
&lt;Zakim> RRSAgent, make logs Public<br>
&lt;Zakim> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference<br>
&lt;RRSAgent> I have made the request, Zakim<br>
&lt;Rossen9> Zakim, start meeting<br>
&lt;Zakim> RRSAgent, make logs Public<br>
&lt;emilio> q+ TabAtkins<br>
&lt;RRSAgent> I have made the request, Zakim<br>
&lt;Zakim> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference<br>
&lt;Zakim> RRSAgent, make logs Public<br>
&lt;Zakim> Meeting: Cascading Style Sheets (CSS) Working Group Teleconference<br>
&lt;emilio> q+ later<br>
&lt;RRSAgent> I have made the request, Zakim<br>
&lt;Rossen9> ack emilio<br>
&lt;emilio> TabAtkins: I agree with fantasai and dbaron's comment on the thread<br>
&lt;dholbert> scribe+<br>
&lt;emilio> ... don't want to resolve us into any particular syntax<br>
&lt;emilio> ... but the right idea is to go ahead is to remove the syntax from the proposal<br>
&lt;emilio> ... instead of having a specific /for/ we have a note that this is indeed how we're likely to do future combinators<br>
&lt;dholbert> emilio: I was going to say something similar<br>
&lt;emilio> ack emilio<br>
&lt;dholbert> emilio: resolving on the specific syntax seems premature, but generally this seems fine<br>
&lt;emilio> florian: I'm a bit confused, because tab seemed to agree and disagree with lea at the same time<br>
&lt;emilio> TabAtkins: I was a bit distracted, might be agreeing with her if lea's position has changed<br>
&lt;emilio> dbaron: some of the nuance is about some things in the draft<br>
&lt;emilio> ... that probably shouldn't be in there in its current form<br>
&lt;emilio> florian: but as a design principle it seems ok with everybody?<br>
&lt;emilio> dbaron: what I was going to try and add is that we've talked about this idea enough that we should probably document it<br>
&lt;castastrophe> q+<br>
&lt;emilio> ... specially since we are out of characters<br>
&lt;emilio> ... with the exception of one that would be pretty bad<br>
&lt;emeyer> +1 to bramus!<br>
&lt;TabAtkins> I mean, we've got $, %, ^...<br>
&lt;lea> q?<br>
&lt;emilio> castastrophe: do we have an adjacent document to document these kinds of things?<br>
&lt;Rossen9> ack castastrophe<br>
&lt;emilio> lea: we could do a lot better in that respect<br>
&lt;emilio> ... we have some design principles in the wiki<br>
&lt;castastrophe> *documentation adjacent to specifications<br>
&lt;emilio> ... tag has a css design principles section<br>
&lt;emilio> ... but no canonical source<br>
&lt;emilio> ... which isn't great<br>
&lt;emilio> dbaron: yeah on the wiki except nobody reads it... If we want to make a note of it I think it's fine to be a doc in the spec<br>
&lt;emilio> lea: I think it's useful for anyone proposing future syntax<br>
&lt;Kurt> https://wiki.csswg.org/ideas<br>
&lt;emilio> ... but tangentially we should have a canonical source for design principles<br>
&lt;castastrophe> q+<br>
&lt;emilio> Rossen9: worthy effort<br>
&lt;emilio> ... hopefully someone could pick it up<br>
&lt;emilio> q+<br>
&lt;Rossen9> ack castastrophe<br>
&lt;emilio> castastrophe: I was thinking generally +1 to adding some documentation to the spec<br>
&lt;fantasai> https://wiki.csswg.org/ideas/principles :)<br>
&lt;emilio> ... would be useful to document the unused ascii chars that are still available for doc purposes?<br>
&lt;emilio> lea: no objection to that<br>
&lt;emilio> dbaron: it might be tricky to say what counts as available, but sounds fine<br>
&lt;dholbert> emilio: more to the point than the design principals thing... have we considered other syntaxes that aren't slashes?<br>
&lt;dholbert> emilio: to me, angle-brackets feel more combinator-y<br>
&lt;Rossen9> ack emilio<br>
&lt;dholbert> emilio: like &lt;for>; that would parse potentially differently<br>
&lt;dholbert> dbaron: given the existing child selector, that might not go over very well<br>
&lt;dholbert> emilio: seems parseable... but anyways<br>
&lt;dholbert> lea: there have been proposals for a &lt; combinator that goes the other way, which would make this ambiguous<br>
&lt;emilio> ack fantasai<br>
&lt;Rossen9> ack fantasai<br>
&lt;emilio> fantasai: I think we can resolve on removing the existing idref feature<br>
&lt;emilio> ... and potentially to put a not along the lines that dbaron mentioned<br>
&lt;emilio> ... for future named combinators<br>
&lt;emilio> Rossen9: there's also castastrophe's proposal to document the available ones<br>
&lt;emilio> fantasai: Isn't that just ascii punctuation minus the set of used chars?<br>
&lt;emilio> castastrophe: might be overkill but maybe useful for others not so familiar with the spec?<br>
&lt;emilio> Rossen9: might be useful<br>
&lt;emilio> PROPOSED: Remove idref feature<br>
&lt;emilio> RESOLVED: Remove idref feature from the spec<br>
&lt;emilio> PROPOSED: Add a note about future named combinators<br>
&lt;kbabbitt> +1<br>
&lt;dbaron> "add a note that we expect to use /-delimited idents or functions for future syntax expansion"<br>
&lt;Rossen9> https://github.com/w3c/csswg-drafts/issues/12451#issuecomment-3377805584<br>
&lt;emilio> RESOLVED: add a note that we expect to use /-delimited idents or functions for future syntax expansion<br>
&lt;emilio> PROPOSED: Add a note about unused ascii punctuation<br>
&lt;emilio> RESOLVED: Add a note about unused ascii punctuation<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12451#issuecomment-3492432778 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 5 November 2025 17:17:44 UTC