Re: [selectors-api] Consider backporting find() behavior to querySelector()

I am very opposed to this, they do different things.  Having abilities
isn't a bad thing and numerous Web sites and libraries make use of qsa, not
just because find was not available but because different APIs shapes
interesting new possibilities, different ways of looking at problems,
etc... We solve problems with the tools at hand, so given that it has been
widely implemented a long time, you can safely assume we have found good
uses for it.

There are a vast number of libraries and websites that have use cases for
find, this is especially true because selector engines that solved those
cases evolved in the wild a long time ago.... it probably would have been
nice to have had that native first, as it would have been a more immediate
help for the vast number of users, but qsa is definitely useful.
On Jun 18, 2012 10:45 AM, "Simon Pieters" <simonp@opera.com> wrote:

> So http://dev.w3.org/2006/webapi/**selectors-api2/<http://dev.w3.org/2006/webapi/selectors-api2/>introduces the methods find() and findAll() in addition to querySelector()
> and querySelectorAll() and changes the scoping behavior for the former
> methods to match what people expect them to do.
>
> I'm not convinced that doubling the API surface is a good idea. If we were
> to do that every time we find that a shipped API has suboptimal behavior,
> the API surface on the Web would grow exponentially and we wouldn't make
> the overall situation any better. What if we find a new problem with find()
> after it has shipped? Do we introduce yet another method?
>
> I think we should instead either fix the old API (if it turns out to not
> Break the Web) or live with past mistake (if it turns out it does). To find
> out whether it Breaks the Web (and the breakage can't be evanged), I
> suggest we ship the backwards-incompatible change to querySelector() in
> nightly/aurora (or equivalent) in one or more browsers for some time.
>
> --
> Simon Pieters
> Opera Software
>
>