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/
