Re: [csswg-drafts] [selectors] Parameterized selectors (#10567)

> This is very powerful, but I suspect that the sheer complexity of generic backreferences will make it very hard to get implemented.
> 
> Could there be a less powerful feature that still covers a good chunk of use cases? For idrefs, I proposed [#10970](https://github.com/w3c/csswg-drafts/issues/10970) a few months ago which would address [#12436](https://github.com/w3c/csswg-drafts/issues/12436) as well. What % of use cases are not idrefs? Perhaps we could extend to a syntax that takes the source attribute as a parameter as well. E.g. `/attref()/` or even just `/ref()/`. I’ll open a new issue.

New issue opened #12446 but in the course of writing it, I became convinced that for certain use cases, a backreference syntax like the one discussed here is going to have vastly better ergonomics. 

A combinator works well when the query is wide ("give me ALL elements whose `id` is the same as this element's `foo` attribute, wherever they are in the document") but not well when the query needs to be combined with another combinator ("give me all child elements whose `id` is the same as this element's `foo` attribute). It can be accomplished via filtering, but it's awkward.

The scope of the backreference would need to be the whole selector list for this syntax to work for the wide use cases as well though, otherwise it becomes very awkward to do the wide queries. But that breaks a fundamental assumption of selector lists, that all its constituent complex selectors are independent.

-- 
GitHub Notification of comment by LeaVerou
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10567#issuecomment-3033821576 using your GitHub account


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

Received on Thursday, 3 July 2025 22:12:18 UTC