Re: [csswg-drafts] [css-cascade-6] Can we replace the selector scoping notation with a new parameter in `querySelector()`? (#7709)

The CSS Working Group just discussed `querySelector and scoping`, and agreed to the following:

* `RESOLVED: Remove scoping from selectors`

<details><summary>The full IRC log of that discussion</summary>
&lt;emilio> Topic: querySelector and scoping<br>
&lt;emilio> github: https://github.com/w3c/csswg-drafts/issues/7709<br>
&lt;emilio> miriam: in the scope spec we tried to provide the at rule and also tried to provide that in selectors<br>
&lt;emilio> ... the reason was to use querySelector to return scoped results<br>
&lt;emilio> ... that ended up being difficult and raised many different issues<br>
&lt;emilio> ... syntax is easy to solve in @scope and harder in selector notations<br>
&lt;zcorpan> (I found https://html.spec.whatwg.org/multipage/webappapis.html#creating-a-css-module-script )<br>
&lt;emilio> ... is it worth to pursue that or can we add a second argument to qSA<br>
&lt;TabAtkins> q+<br>
&lt;emilio> ... and get rid of the selector notation<br>
&lt;Rossen_> ack TabAtkins<br>
&lt;emilio> TabAtkins: I think we should switch the second arg to an options bag<br>
&lt;TabAtkins> querySelector(".foo", {upper: Element, lower: Element} )<br>
&lt;emilio> q+<br>
&lt;heycam> emilio: I assume the way this would be implemented would be basically a post-processing of sorts<br>
&lt;miriam> q+<br>
&lt;heycam> ... you'd first match the selector, then if it matches, you check the scope. do we really need a querySelector API for that?<br>
&lt;heycam> ... it's like a filter on the querySelectorAll results<br>
&lt;heycam> miriam: I'm not sure I understand your proposal Tab<br>
&lt;heycam> emilio: I understand the proposal, but do we need to build this into qSA? can't you process the qSA results?<br>
&lt;heycam> miriam: if I'm reading Tab's proposal right, you're looking for a selector within a scope<br>
&lt;heycam> ... I'm trying to return a scoped fragment of tree<br>
&lt;heycam> ... which is a bit different from scoped selector<br>
&lt;heycam> ... so when you grab an element you get its descendants<br>
&lt;heycam> ... potentially with cutting off some lower boundaries<br>
&lt;emilio> TabAtkins: that's what you'd get if your selector was a star<br>
&lt;Rossen_> ack emilio<br>
&lt;Rossen_> ack miriam<br>
&lt;emilio> miriam: no, we're trying to return not a selector within a scope, but the scope<br>
&lt;emilio> TabAtkins: that sounds like a completely different thing<br>
&lt;emilio> miriam: doesn't qSA return the tree of elements?<br>
&lt;emilio> fantasai: no, only the list of matched elements<br>
&lt;emilio> fremy: are you trying to get something like get all the images inside a div but not inside a p<br>
&lt;emilio> TabAtkins: you can't do it with selectors reliably , you need upper and lower boundaries<br>
&lt;emilio> fremy: yeah but your proposal takes an element, it should ideally take selectors right?<br>
&lt;emilio> TabAtkins: it should take a list of elements<br>
&lt;fantasai> fantasai: Should accept a selector representing such elements<br>
&lt;heycam> emilio: I'm moderately sure qSA doesn't take a second argument<br>
&lt;heycam> TabAtkins: yes it does<br>
&lt;heycam> ... but it's the this value<br>
&lt;Rossen_> q<br>
&lt;emilio> TabAtkins: regardless of design discussions, question is is it ok to drop the scoping from selectors because we'll address the use case in some way by modifying qS?<br>
&lt;emilio> q+<br>
&lt;heycam> emilio: I think we should drop the selector syntax<br>
&lt;heycam> ... I'm pretty convinced you can achieve the scoping stuff with script right now<br>
&lt;heycam> ... even if it needs multiple qS calls<br>
&lt;Rossen_> ack emilio<br>
&lt;heycam> ... but if we need to add a more convenient way to do that, we can do that<br>
&lt;TabAtkins> Doing it in small amounts of code, correctly, is non-trivial.<br>
&lt;heycam> ... but I don't think we should force scoping into selectors just for this use case<br>
&lt;emilio> fremy: the only thing would be performance<br>
&lt;TabAtkins> Need to make sure the forbidden ancestor is between the element and the root (upper boundary); if it's *above* the root it doesn't matter.<br>
&lt;emilio> ... you can filter in JS but you can create wrappers for lots of nodes<br>
&lt;heycam> emilio: if you use closest, you don't create [...]<br>
&lt;emilio> TabAtkins: you can't use closest, it's non-trivial to do in script<br>
&lt;heycam> emilio: but I'm sure we can figure out a convenient way to do this if we need it<br>
&lt;zcorpan> https://dom.spec.whatwg.org/#dom-parentnode-queryselector<br>
&lt;emilio> TabAtkins: proposal is removing scoping from selectors, opening an issue in DOM for adding scoping API to qSA<br>
&lt;emilio> RESOLVED: Remove scoping from selectors<br>
</details>


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


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

Received on Thursday, 15 September 2022 21:13:02 UTC