[css-cascade-6] Can we replace the selector scoping notation with a new parameter in querySelector()?
#7709
Projects
Comments
|
In particular, the current second argument to qS() is, effectively, the upper bound of scoping; we could expand the argument to be an options bag with |
|
Meanwhile, the other half of the |
|
The CSS Working Group just discussed
The full IRC log of that discussion<emilio> Topic: querySelector and scoping<emilio> github: https://github.com//issues/7709 <emilio> miriam: in the scope spec we tried to provide the at rule and also tried to provide that in selectors <emilio> ... the reason was to use querySelector to return scoped results <emilio> ... that ended up being difficult and raised many different issues <emilio> ... syntax is easy to solve in @scope and harder in selector notations <zcorpan> (I found https://html.spec.whatwg.org/multipage/webappapis.html#creating-a-css-module-script ) <emilio> ... is it worth to pursue that or can we add a second argument to qSA <TabAtkins> q+ <emilio> ... and get rid of the selector notation <Rossen_> ack TabAtkins <emilio> TabAtkins: I think we should switch the second arg to an options bag <TabAtkins> querySelector(".foo", {upper: Element, lower: Element} ) <emilio> q+ <heycam> emilio: I assume the way this would be implemented would be basically a post-processing of sorts <miriam> q+ <heycam> ... you'd first match the selector, then if it matches, you check the scope. do we really need a querySelector API for that? <heycam> ... it's like a filter on the querySelectorAll results <heycam> miriam: I'm not sure I understand your proposal Tab <heycam> emilio: I understand the proposal, but do we need to build this into qSA? can't you process the qSA results? <heycam> miriam: if I'm reading Tab's proposal right, you're looking for a selector within a scope <heycam> ... I'm trying to return a scoped fragment of tree <heycam> ... which is a bit different from scoped selector <heycam> ... so when you grab an element you get its descendants <heycam> ... potentially with cutting off some lower boundaries <emilio> TabAtkins: that's what you'd get if your selector was a star <Rossen_> ack emilio <Rossen_> ack miriam <emilio> miriam: no, we're trying to return not a selector within a scope, but the scope <emilio> TabAtkins: that sounds like a completely different thing <emilio> miriam: doesn't qSA return the tree of elements? <emilio> fantasai: no, only the list of matched elements <emilio> fremy: are you trying to get something like get all the images inside a div but not inside a p <emilio> TabAtkins: you can't do it with selectors reliably , you need upper and lower boundaries <emilio> fremy: yeah but your proposal takes an element, it should ideally take selectors right? <emilio> TabAtkins: it should take a list of elements <fantasai> fantasai: Should accept a selector representing such elements <heycam> emilio: I'm moderately sure qSA doesn't take a second argument <heycam> TabAtkins: yes it does <heycam> ... but it's the this value <Rossen_> q <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? <emilio> q+ <heycam> emilio: I think we should drop the selector syntax <heycam> ... I'm pretty convinced you can achieve the scoping stuff with script right now <heycam> ... even if it needs multiple qS calls <Rossen_> ack emilio <heycam> ... but if we need to add a more convenient way to do that, we can do that <TabAtkins> Doing it in small amounts of code, correctly, is non-trivial. <heycam> ... but I don't think we should force scoping into selectors just for this use case <emilio> fremy: the only thing would be performance <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. <emilio> ... you can filter in JS but you can create wrappers for lots of nodes <heycam> emilio: if you use closest, you don't create [...] <emilio> TabAtkins: you can't use closest, it's non-trivial to do in script <heycam> emilio: but I'm sure we can figure out a convenient way to do this if we need it <zcorpan> https://dom.spec.whatwg.org/#dom-parentnode-queryselector <emilio> TabAtkins: proposal is removing scoping from selectors, opening an issue in DOM for adding scoping API to qSA <emilio> RESOLVED: Remove scoping from selectors |
|
Closing this here, since our spec has been updated - and a new issue is opened on the WHATWG/dom spec. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
CSS Cascade L6 defines a selector scoping notation which is functionally the same as the
@scoperules, but is designed as a selector syntax rather than an at-rule. There is also an inline issue, noting the purpose of that:In practice, the selector notation is much more difficult to design in a readable way. The basic syntax is less clear than the at-rule, we haven't yet determined how it interacts with nesting, and it's become a blocker for otherwise-straight-forward issues like #6577. If we don't absolutely need this syntax, and can find another solution for scoping
querySelector(), I would like to remove it from the spec.My proposal would be:
lowerBoundaryparameter to bothquerySelector()andquerySelectorAll().The text was updated successfully, but these errors were encountered: