Re: QSA, the problem with ":scope", and naming

On 23/10/11 5:44 AM, Timmy wrote:
> On Oct 21, 2011, at 7:57 PM, Sean Hogan wrote:
>> It was definitely not a design flaw in QSA. As Alex's sample code shows it is possible to get findAll() behavior using QSA.
> I think that further supports my argument.  JS libraries have commonly considered this to be an oversight in the design of QSA, hence the need for ID hack.  That is still true whether it was actually a design flaw or not.
>
>> To do the reverse would involve calling document.findAll() then filtering for nodes that are descendants of the invoking node.
> I don't think anyone is interested in implementing the reverse in selector engines.  The most useful thing would be elem.findAll().  No manual filtering required.

<rant>
This sounds like:

Although X is more composable than Y, this is irrelevant because no-one 
would use X if Y is available.

This was the rationale used for removing matchesSelector() from the 
original Selectors API spec.

In my experience, when someone (me, for instance) or a committee or 
work-group can't think of a benefit of a more composable function it 
merely indicates a limited experience or imagination.

Once it has been decided that an API will be provided for a particular 
feature, the more primitive methods should be available by default. To 
*not* include them should require good reasons.

More specific methods should require use-cases and a rationale for why 
they shouldn't be composed from other methods.

Anyway, the use-case for element.querySelectorAll() - apart from being 
called from selector engines in js libs - is quite straight-forward.

Say I want to augment all elements in a page that match a given 
selector. After the page has loaded I can find all the elements by 
calling document.querySelectorAll(). When new content is added into the 
page I don't want to call document.querySelectorAll() and filter out 
already augmented elements. But if I only had element.findAll() then I 
might miss elements that match the selector because for findAll() the 
*whole* selector must match within the scope of element.

This is similar to the way jQuery.fn.delegate() works. One of the 
strengths of .delegate() is that it can handle events for elements that 
match the given selector even if the element wasn't in the document when 
delegate() was called. But .delegate() scopes selectors to the whole 
document, not the invoking nodes.
</rant>

>> But if findAll() is implemented they can advertise that avoiding non-standard pseudo selectors gives virtually native performance (on supporting platforms). I imagine this would be almost equivalent to deprecating them, which would be a win.
> This is extraneous.  The implementation of custom pseudo selectors would be identical.

Well, no-one can prevent JS libs implementing custom pseudo selectors, 
just as they can't be prevented from implementing custom DOM methods, 
e.g. HTMLElement.prototype.awesome().
But they both have the same negatives, most especially that if the 
method name / pseudo-selector name is one day implemented in browsers 
but with a different definition then code that was relying on the 
library will start receiving the different native behavior.

Of course, there are counter-arguments to the negatives. Never-the-less 
it is considered good practice (good web-citizenship if you like) to use 
vendor prefixes for custom methods and custom selectors.

Sean

Received on Sunday, 23 October 2011 11:27:57 UTC