- From: Sean Hogan <shogun70@westnet.com.au>
- Date: Wed, 24 Sep 2014 16:28:45 +1000
- To: "Tab Atkins Jr." <jackalmage@gmail.com>
- CC: Anne van Kesteren <annevk@annevk.nl>, Boris Zbarsky <bzbarsky@mit.edu>, "www-style@w3.org" <www-style@w3.org>, "www-dom@w3.org" <www-dom@w3.org>, David Håsäther <hasather@gmail.com>
On 24/09/14 6:32 AM, Tab Atkins Jr. wrote: > On Tue, Sep 23, 2014 at 1:05 PM, Sean Hogan <shogun70@westnet.com.au> wrote: >> On 23/09/14 5:32 PM, Anne van Kesteren wrote: >>> On Mon, Sep 22, 2014 at 11:54 AM, Sean Hogan <shogun70@westnet.com.au> >>> wrote: >>>> No. I am also saying that if there is no explicit scope reference node >>>> passed in then the implied scope reference node is document (or some >>>> equivalent for elements not in document). I believe that currently the >>>> implied scope reference node is the element itself. >>>> >>>> Currently: >>>> E.matches(':scope') -> true >>>> E.matches(':scope ul li') -> false >>>> >>>> Should be: >>>> E.matches(':scope') -> false >>>> E.matches(':scope ul li') -> true if E.matches('ul li') is true >>> Why would that be better? As far as the :scope pseudo-element is >>> concerned, the current semantics seem much more intuitive. I could see >>> how you maybe want to rebind :scope, or restrict the tree traversed, >>> but not why you want to change the way :scope works. >>> >>> >> E.matches(':scope') >> E.closest(':has(:scope)') >> are not selectors anyone would write. >> They do not have to be useful. >> >> They should be consistent. e.g. >> A.query(':scope > li > a[href]').matches(':scope > li > a[href]', A); // >> potentially true >> document.query(':scope body').matches(':scope body'); // probably true >> >> Scoping is defining a boundary (not a reference node). > Correct, but irrelevant. :scope is not directly related to selector > scoping, despite the name. (The scoping elements are *one* source of > default :scope elements, though.) If :scope doesn't mean scope then it's a bit of a stretch to claim any usage is intuitive. Has any browser implemented :scope in CSS? Does it still mean scope there? I don't think dom traversal should be blurring the term to mean "reference-node which is sometimes the scope". If someone starts with the dom definition that :scope mean reference-node will they be confused in CSS where :scope means scope? Is it too late for dom traversal to use a different pseudo-class? >> In the DOM, a single node can define a boundary for all the nodes *below* >> it. >> That's why in >> A.queryAll(':scope > li > a[href]') >> A.queryAll('> li > a[href]') >> the scope is naturally A, because queryAll() can find all nodes *below* A. > No, it can find nodes outside of A. `A.queryAll("+ li > a[href]")` > can return an answer. The arguments to query/queryAll are *not* > scoped selectors, they are relative selectors with a :scope element. I was surprised by that. The :scope is A but the scope is document (or equivalent). I would not be surprised by say A.ownerDocument.querySelectorAll(':ref-node + li > a[href]', A) if qSA could be passed reference nodes. The :ref-node is A and the scope is document. >> SImilarly in >> E.closest(':scope > li > a[href]', A); >> the scope is naturally A, because the search can find an element *below* A. > This is assuming a future extension where you explicitly provide a > reference element, right? Yes, if you explicitly specify what :scope > should match, :scope should match it. A bit more than that. If A is the scope then a) it must be an ancestor of E and b) it will provide an exclusive limit to upwards dom traversal in the search. If A is just a reference node then neither of those apply. A reference node is more flexible but I can't think of any real-world use-cases. I suspect ":scope always means scope" is sufficient. But isn't blurring scope and reference node just going to make specs and implementations more complex?
Received on Wednesday, 24 September 2014 06:29:20 UTC