Re: "match a selectors string" in the DOM spec doesn't do what it wants to be doing

On 8/4/14, 3:34 AM, Anne van Kesteren wrote:
> If it started to return a boolean, the algorithm defined for
> http://dom.spec.whatwg.org/#dom-element-matches would no longer make
> sense.

Sure.  The definition of matches() would change to just return the 
boolean returned from this new method.

As things stand right now, the definition of matches() (which is in fact 
what led me here) makes no sense.  It passes a one-element set to "match 
a selectors string", but "match a selectors string" passes that set as 
the ":scope elements" to "evaluate a selector".  It does not provide the 
"one or more element tree root elements" that "evaluate a selector" 
requires as input.  We can fix things up to make this work by passing 
"set" for both the set of tree root elements and the set of :scope 
elements, but the indirection and complexity (first construct some set 
of all elements that match the selector, then return whether our element 
is in that set) that led to this even being a problem doesn't seem very 
desirable to me.

Not to mention that if selector matching ever becomes observable 
(something people keep asking for with JS callbacks for pseudo-classes) 
the clever algorithm in the DOM spec becomes observably different from 
the sane way to implement matches().

 > Nor would numerous other algorithms in DOM.

Which ones?  The only consumers of "match a selectors string" I see in 
http://dom.spec.whatwg.org/ are matches() and closest(), both of which 
really want a simple boolean "does this element match this selector?" 
hook.  Am I missing other consumers?

I'm not proposing getting rid of "evaluate a selector"; I'm proposing 
explicitly exposing the lower-level "does this selector match this 
element" primitive and using it directly in matches() and closest().

-Boris

Received on Monday, 4 August 2014 07:52:54 UTC