Re: [selectors-api] LCWD comments

Krzysztof Maczyński wrote:
>> I'm not familiar with XPath's usage of the term. Please explain why this 
>> is a problem for two completely orthogonal specs to define the same term 
>> with different meaning?
> 
> Well, it's potentially confusing, I can easily imagine e.g. myself 
> having to say "context node (in CSS sense)", and I see no reason not to 
> call it a scoping node or something instead. If you do see one however 
> about which you feel strongly, I don't intend to oppose fervently.

I see no compelling reason to change it and I would like to avoid making 
unnecessary changes.

>> I cannot find an alternative term that would be appropriate.  However, I 
>> have adjusted its definition to refer to the nodes as a collection 
>> rather than a tree.
>  
> But you still call it a subtree, thus a tree, which it definitely
> needn't be.

Well, it is a subtree rooted at the context node, which is why I chose 
that term.  But if I understand you correctly, your issue is that the 
term is used even though the context node itself is excluded from the 
set.  This leaves any number of subtrees, each rooted by one of the 
context node's child elements.  Therefore, I have changed it to the 
plural "node’s subtrees".  Is that acceptable?

> (Only now have I clearly understood that you don't want an
> element E to equal E.querySelector("*"). May be just as reasonable or 
> more so than the opposite, but what's the rationale, by the way?)

Because the use cases have no need for the method to be able to return 
the element itself, and as your example shows, doing so would be 
pointless and confusing.

> I've just spotted one more issue:
>  
>> definitions of the querySelector methods
>  
> Is the plural intended?

Yes, there are two definitions. One for querySelector() and another for 
querySelectorAll().

-- 
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/

Received on Friday, 30 January 2009 12:17:57 UTC