Re: Behavior of matches() and closest() with :scope()

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