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

[Kang-Hao (Kenny) Lu]

(12/06/21 23:28), Charles McCathieNevile wrote:
> On Thu, 21 Jun 2012 15:56:45 +0200, Kang-Hao (Kenny) Lu
>  wrote:
>> (12/06/20 22:26), Lachlan Hunt wrote:
>>> The least-objectionable alternative is rarely the best alternative, and
>>> trying to please everyone is a fool's errand.
>>
>> While I agree that trying to please everyone is foolish, I am curious
>> about data that can be used to prove the "the least-objectionable
>> alternative is rarely the best alternative" statement.
> 
> I don't think there is any readily available. There are no clear
> criteria for judging "best", although there are some clear criteria for
> judging bad - for example things that often get confused are definitely
> bad.

Well, yes, though I wonder why we can't define "best" to be what gets
the most public votes (just in this case, please don't generalize this
to cases when X and Y are having different implementation difficulty).

>>> Hopefully, this time, the group will let me, as editor, evaluate the
>>> options and supporting rationale and make a decision based on that.
>>
>> I don't know what happened when the WG decided on the poor name
>> "querySeletor"
> 
> Pretty much what Lachy said. As chair, I was the one who decided there
> ws too much objection and called for some other process. I don't claim
> it was especially good or came up with a great name, but I don't think
> it was awful and I don't see a better alternative if the situation
> arises again.

Thanks for the information (and to Lachy too). I also found the vote[1]
itself quite interesting.

[1] http://www.w3.org/2002/09/wbs/38482/selectorsNames/results

>> "Despite the fact the editor thinks function name X is better than
>> 'querySelector', there were a few people () who were
>> strongly opposed to X and a group vote happened and a decision was made
>> by (). Nobody ran a compatibility research."
>>
>> And this time, I would like to ask whoever is going to make the decision
>> to take the opinion of the *public* into account. I am not saying it
>> should be the sole factor, but what I am looking for is an explanation
>> like
>>
>> "Compatibility research shows that both name X and Y are fine. 70% of
>> the Web developers are in favor of name X and therefore X is chosen."
> 
> We don't have that data. We don't agree which web developers are the
> ones whose opinions matter - those who type a name once a month and want
> something self-explanatory, or those who type it once every 3 minutes,
> or those who write tools to avoid typing it at all, or ...
> 
> And then we don't have representative samples. We know, for example,
> that focus/blur made sense to english-speaking developers but confused
> millions of developers whose first language was something else.
> 
> So claiming we are basing a decision on "the data" will probably give
> results as arbitrary as the process we used, but with a veneer of
> intellectual dishonesty.

I claim that numeric data is as honest as we ever can be. Taking a look
at Lachy's summary, I have to say while I appreciate the effort spent on
this, there are really just contradictory sentences that made me frown,
and Lachy later admitted[2]:

[[
In hindsight, looking at the arguments above, I probably did let my own
personal dislike of the name get in the way of my objectivity in this
case, as much as I tried to avoid doing so.  As such, I am now willing
to consider these alternatives.
]]

. Debating these "rationale" seems to be a waste of time too.

I don't see why doing a public poll can be considered dishonest. The
honest description would just be

"We ran a public poll on () with X people, Y % of
them are Web developers (). The
result ... "

[2] http://lists.w3.org/Archives/Public/public-webapi/2007Jun/0120

> (It is instructive to think for five minutes about the things that can
> go wrong, and how much effort we should spend on trying to get it "right")
> 
> Essentially, a bunch of people tossed up all the reasons to object to a
> name that they could think of based on their experience of things that
> go wrong. Based on that, some proposals were rapidly rejected, and then
> we looked at the rest, kicking the tyres of each in turn until we
> figured out which one the most people didn't think was truly
> problematic. It can be dismissed as "design by committee", but it can
> also be characterised as applying the wisdom of several smart people to
> avoid as many pitfalls as possible.
> 
> Frankly I think that suggesting one is smarter than any committee of
> smart people could be is a bold claim - if nobody is especially happy
> with the outcome, it can often be said that a number of very clever
> hardworking people recognise that it doesn't have any of several obvious
> problems they can name, and they think it is an acceptable outcome.

I never like the "design by committee" term because it seems to suggest
a solution (the benevolent dictator) without explaining what's going on.

In the "querySelector" case, although I admit 

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

[Charles McCathieNevile]

On Thu, 21 Jun 2012 15:56:45 +0200, Kang-Hao (Kenny) Lu  
 wrote:



(12/06/20 22:26), Lachlan Hunt wrote:

On 2012-06-20 10:42, Charles McCathieNevile wrote:

In other words we have the same arguments that we had five years ago,
when we settled on querySelector as the one that provoked least
objection.
...



The least-objectionable alternative is rarely the best alternative, and
trying to please everyone is a fool's errand.


While I agree that trying to please everyone is foolish, I am curious
about data that can be used to prove the "the least-objectionable
alternative is rarely the best alternative" statement.


I don't think there is any readily available. There are no clear criteria  
for judging "best", although there are some clear criteria for judging bad  
- for example things that often get confused are definitely bad.



Hopefully, this time, the group will let me, as editor, evaluate the
options and supporting rationale and make a decision based on that.


I don't know what happened when the WG decided on the poor name
"querySeletor"


Pretty much what Lachy said. As chair, I was the one who decided there ws  
too much objection and called for some other process. I don't claim it was  
especially good or came up with a great name, but I don't think it was  
awful and I don't see a better alternative if the situation arises again.



"Despite the fact the editor thinks function name X is better than
'querySelector', there were a few people () who were
strongly opposed to X and a group vote happened and a decision was made
by (). Nobody ran a compatibility research."

And this time, I would like to ask whoever is going to make the decision
to take the opinion of the *public* into account. I am not saying it
should be the sole factor, but what I am looking for is an explanation  
like


"Compatibility research shows that both name X and Y are fine. 70% of
the Web developers are in favor of name X and therefore X is chosen."


We don't have that data. We don't agree which web developers are the ones  
whose opinions matter - those who type a name once a month and want  
something self-explanatory, or those who type it once every 3 minutes, or  
those who write tools to avoid typing it at all, or ...


And then we don't have representative samples. We know, for example, that  
focus/blur made sense to english-speaking developers but confused millions  
of developers whose first language was something else.


So claiming we are basing a decision on "the data" will probably give  
results as arbitrary as the process we used, but with a veneer of  
intellectual dishonesty.



Seriously, I don't see why a rationale like this is better than the one
for "querySelector" as this is pretty much just s/WG/editor/ of that
since the WG vote didn't represent the public


Sure.


In other words, while I can agree that a single +1/-1 statement isn't
strong as a rationale (or even not a rationale) I beg you to take the
sum as a valid and strong rationale, at least in this case where X and Y
don't have much difference.

And I am still interested in what really happened last time.


(It is instructive to think for five minutes about the things that can go  
wrong, and how much effort we should spend on trying to get it "right")


Essentially, a bunch of people tossed up all the reasons to object to a  
name that they could think of based on their experience of things that go  
wrong. Based on that, some proposals were rapidly rejected, and then we  
looked at the rest, kicking the tyres of each in turn until we figured out  
which one the most people didn't think was truly problematic. It can be  
dismissed as "design by committee", but it can also be characterised as  
applying the wisdom of several smart people to avoid as many pitfalls as  
possible.


Frankly I think that suggesting one is smarter than any committee of smart  
people could be is a bold claim - if nobody is especially happy with the  
outcome, it can often be said that a number of very clever hardworking  
people recognise that it doesn't have any of several obvious problems they  
can name, and they think it is an acceptable outcome.


cheers

Chaals

--
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg kan noen norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com

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

[Lachlan Hunt]

On 2012-06-21 15:56, Kang-Hao (Kenny) Lu wrote:

(12/06/20 22:26), Lachlan Hunt wrote:

On 2012-06-20 10:42, Charles McCathieNevile wrote:

In other words we have the same arguments that we had five years ago,
when we settled on querySelector as the one that provoked least
objection.
...
But spending another few months arguing about it hasn't proven that we
are any wiser, nor (importantly) any closer to agreement.


This is why it should be an editorial decision, not a group vote.


While I don't think a WG vote is the right way to do, I strongly
disagree that naming of a function belongs to an editorial decision.
Changing the name of a function requires all the tests be rewritten, and
therefore it is by definition not editorial.


By editorial decision, I meant that the decision of what to name it 
should be up to the editor, not that it is a minor editorial issue. 
Sorry for the confusion.  Fixing tests is trivial, but the name should 
be decided before implementation begins and a testsuite is written anyway.


At this stage, I haven't seen any overly strong objections to the names 
find/findAll anyway, so hopefully this is a non-issue.



Hopefully, this time, the group will let me, as editor, evaluate the
options and supporting rationale and make a decision based on that.


I don't know what happened when the WG decided on the poor name
"querySeletor", but from a outsider's point of view, along with the
final decision, I also care about a detailed description about why a
function name is chosen.

For example, attributing the poor "querySelector" decision to an
abstract concept of "design by committee" doesn't seem to be reasonable
and genuine. I'd rather want to see a long explanation like:


What happened last time was that I carefully reviewed the entire debate, 
taking into account all arguments for and against every suggested 
alternative I found at the time and posted a thorough review and 
rationale for the decision I made at the end.


http://lists.w3.org/Archives/Public/public-webapi/2007Jun/0077.html

This then resulted in some people in the group complaining loudly enough 
because they weren't happy, mostly because it's impossible to please 
everyone, leading to a vote between 6 choices, ultimately overruling me.


Anecdotally, I heard from a few web developers at the time saying they 
even liked the names I'd chosen, despite them being a little long, but 
were later disappointed with the result of the vote.


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

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

[Kang-Hao (Kenny) Lu]

(12/06/20 22:26), Lachlan Hunt wrote:
> On 2012-06-20 10:42, Charles McCathieNevile wrote:
>> In other words we have the same arguments that we had five years ago,
>> when we settled on querySelector as the one that provoked least
>> objection.
>> ...
>> But spending another few months arguing about it hasn't proven that we
>> are any wiser, nor (importantly) any closer to agreement.
> 
> This is why it should be an editorial decision, not a group vote.

While I don't think a WG vote is the right way to do, I strongly
disagree that naming of a function belongs to an editorial decision.
Changing the name of a function requires all the tests be rewritten, and
therefore it is by definition not editorial.

> The least-objectionable alternative is rarely the best alternative, and
> trying to please everyone is a fool's errand. 

While I agree that trying to please everyone is foolish, I am curious
about data that can be used to prove the "the least-objectionable
alternative is rarely the best alternative" statement.

> Hopefully, this time, the group will let me, as editor, evaluate the
> options and supporting rationale and make a decision based on that.

I don't know what happened when the WG decided on the poor name
"querySeletor", but from a outsider's point of view, along with the
final decision, I also care about a detailed description about why a
function name is chosen.

For example, attributing the poor "querySelector" decision to an
abstract concept of "design by committee" doesn't seem to be reasonable
and genuine. I'd rather want to see a long explanation like:

"Despite the fact the editor thinks function name X is better than
'querySelector', there were a few people () who were
strongly opposed to X and a group vote happened and a decision was made
by (). Nobody ran a compatibility research."

And this time, I would like to ask whoever is going to make the decision
to take the opinion of the *public* into account. I am not saying it
should be the sole factor, but what I am looking for is an explanation like

"Compatibility research shows that both name X and Y are fine. 70% of
the Web developers are in favor of name X and therefore X is chosen."

or

"Despite 70% of the Web developers are in favor of name X, compatibility
research shows that "

or even

"Despite 70% of the Web developers are in favor of name X, 100% of
browser developers are not and therefore ..."

or even

"Nobody ran either a public vote and compatibility research and the
editor made the decision on X because he likes it."

(Seriously, I don't see why a rationale like this is better than the one
for "querySelector" as this is pretty much just s/WG/editor/ of that
since the WG vote didn't represent the public, but at least this is
easier to understand than "design by committee" or "design by editor",
which is just well, difficult to understand to a causal person who cares
about the standard but doesn't have the bandwidth to go in.)

In other words, while I can agree that a single +1/-1 statement isn't
strong as a rationale (or even not a rationale) I beg you to take the
sum as a valid and strong rationale, at least in this case where X and Y
don't have much difference.

And I am still interested in what really happened last time.


(will try to bring real feedback next time.)


Cheers,
Kenny

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

[Lachlan Hunt]

On 2012-06-20 17:46, Marat Tanalin | tanalin.com wrote:

20.06.2012, 18:14, "Lachlan Hunt" :

4. Support for returning elements that are not descendants of the
 context object.

This feature allows a selector to be constructed such that it matches an
element anywhere in the tree relative to the context element. This
feature is not relevant to document.find(), since it can already return
anything from the whole tree.

elm.find("+span")// span is a sibling
elm.find("/for/ input")  // input could be anywhere
elm.find(":not(:scope)") // Everything except the context object

This feature cannot be supported on Element.qSA, even when using eplicit
:scope, because matching elements need to be descendants of the context
object.


It's unclear why an _updated_ qSA version should have same limitation
that "matching elements need to be descendants of the context
object". There is nothing obvious that makes h1.querySelector('+ H2')
impossible to work in newer implementations (in older ones it would
not work anyway -- to the same extent as `elm.querySelector(">span")`
that you've declared as "could work").


Supporting this without the risk of breaking compatibility would require 
switching selection behaviour based on the presence of the :scope pseudo 
class (either explicit or implied), for each individual selector in the 
group.  When :scope is present, then matching could be applied to the 
entire tree, just like it is in element.find().


That is, given the group of selectors:

  elm.querySelectorAll(":scope+p, div p")

(Note: After pre-processing, there is no difference between explicit 
:scope and implied :scope in "+p")


Only ":scope+p" would be permitted to match non-descendant elements and 
the other "div p" would have to retain the backwards compatible 
selection behaviour where the subject of the selector must be a 
descendant of the context object.


That means, the implementation would need to split the group of 
selectors such that ":scope+p" (or any other selector with explicit or 
implied :scope) is potentially compared with all elements in the tree. 
Then the other selector "div p" should only be compared with descendants 
of the context object.


It will also not work for the reference combinator in some cases.  If 
switching selection behaviour depends on the presence of :scope, then 
the reference combinator will not always work effectively.


  elm.querySelectorAll("label /for/ input")

In this case with no :scope, the matching input must be a descendant of 
the context object, but the label may or may not be.  Compare that with 
this:


  elm.findAll("label /for/ input")

In this case, :scope is implied at the beginning, so the label must be a 
descendant of the context object, but the matching input elements may 
appear anywhere in the tree.


Overall, this adds significant complexity to the implementations, so 
while it may actually be technically possible in some cases, it's far 
from ideal and doesn't address all problems.


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

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

[Charles McCathieNevile]

On Wed, 20 Jun 2012 16:26:14 +0200, Lachlan Hunt  
 wrote:



On 2012-06-20 10:42, Charles McCathieNevile wrote:

In other words we have the same arguments that we had five years ago,
when we settled on querySelector as the one that provoked least  
objection.

...
But spending another few months arguing about it hasn't proven that we
are any wiser, nor (importantly) any closer to agreement.


This is why it should be an editorial decision, not a group vote.  The  
least-objectionable alternative is rarely the best alternative, and  
trying to please everyone is a fool's errand.  Hopefully, this time, the  
group will let me, as editor, evaluate the options and supporting  
rationale and make a decision based on that.


Yeah, if that works, it's fine. Back then we were in a position where  
people cared enough to object, so we chose a different way of making most  
of the people unhappy that drew less objection...


cheers

Chaals (You think this is bad, people bikeshed how I should write  
*my*name* ...)


--
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg kan noen norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com

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

[Boris Zbarsky]

On 6/20/12 11:34 AM, Marat Tanalin | tanalin.com wrote:

It's natural to suppose that searching for just _first_ matching element and 
returning immediately once it's found should be much _faster_ than searching 
for _all_ matching elements (be it 100 or 1000 elements) even if we need just 
first one.


It's natural to suppose that, but it would be wrong if the majority of 
the time is spent setting up the search (e.g. preprocessing the 
selector, which jQuery does), not actually searching



For example, I very like `querySelector()` and use it at least as much as (and 
maybe even more often than) `querySelectorAll()`.


If you're calling these directly, there's a lot less preprocessing going on.

-Boris

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

[Boris Zbarsky]

On 6/20/12 10:52 AM, Dave Methvin wrote:

This test html is based on the
msn.com  home page to be representative of a big
real-life document.


For what it's worth, that document has about 2200 DOM nodes.  That's two 
orders of magnitude smaller than "big real-life documents".  This is a 
medium-small real-life document.


Just for scale, the google.com homepage has about 500 DOM nodes.  The 
W3C homepage has about 1400 DOM nodes.  A Zimbra UI with about 200 
messages in the inbox is about 5000 nodes.  Anything that does dynamic 
UI stuff will tend to be in the 5k-50k node range.


Of course the library overhead might still kill you enough that it 
doesn't matter...


-Boris

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

[Marat Tanalin | tanalin . com]

20.06.2012, 18:14, "Lachlan Hunt" :
> 4. Support for returning elements that are not descendants of the
> context object.
>
> This feature allows a selector to be constructed such that it matches an
> element anywhere in the tree relative to the context element. This
> feature is not relevant to document.find(), since it can already return
> anything from the whole tree.
>
>    elm.find("+span")    // span is a sibling
>    elm.find("/for/ input")  // input could be anywhere
>    elm.find(":not(:scope)") // Everything except the context object
>
> This feature cannot be supported on Element.qSA, even when using eplicit
> :scope, because matching elements need to be descendants of the context
> object.

It's unclear why an _updated_ qSA version should have same limitation that 
"matching elements need to be descendants of the context object". There is 
nothing obvious that makes h1.querySelector('+ H2') impossible to work in newer 
implementations (in older ones it would not work anyway -- to the same extent 
as `elm.querySelector(">span")` that you've declared as "could work").

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

[Dave Methvin]

>
>
> It should be noted that JQuery/sizzle does not use querySelector() at all,
> AFAICS. It only uses querySelectorAll() and sometimes switches to
> .getElementById() or document.body.
>
>
I took a look at using querySelector as an optimization a while back but it
did not seem to make a significant difference in speed, at least once the
library overheads were included. This test html is based on the
msn.comhome page to be representative of a big real-life document.
http://jsperf.com/findone-vs-findall

The reason we switch to getElementById is because querySelectorAll is much
slower for that case. qSA can retrieve multiple elements in invalid
documents with duplicate IDs, but that's not a case we are worried about.

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

[Marat Tanalin | tanalin . com]

20.06.2012, 18:26, "Lachlan Hunt" :
> In particular, is there really value in adding two distinct methods that
> differ only by whether they return 1 element or a collection?  Resolving
> this issue first would help with resolving the naming issue.
>
> It should be noted that JQuery/sizzle does not use querySelector() at
> all, AFAICS. It only uses querySelectorAll() and sometimes switches to
> .getElementById() or document.body.

The whole jQuery's paragigm of always searching all matching elements is a 
potentially big shortcoming of jQuery as for (at least) performance. It's 
natural to suppose that searching for just _first_ matching element and 
returning immediately once it's found should be much _faster_ than searching 
for _all_ matching elements (be it 100 or 1000 elements) even if we need just 
first one.

So yes, we need two separate methods: one to select first matching element and 
another one to select all matching elements. They could be united into one 
single method with an optional argument, but I doubt it would be quite handy 
and nonconfusing for using. Also, a method generally should return consistent 
result as for type of returning value, so if we had one method that always 
returns collection of elements, that would force us to often use the method 
with item accessor (like find('A')[0]) that would be redundant, unusable and 
less readable.

For example, I very like `querySelector()` and use it at least as much as (and 
maybe even more often than) `querySelectorAll()`.

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

[Lachlan Hunt]

On 2012-06-20 10:42, Charles McCathieNevile wrote:

In other words we have the same arguments that we had five years ago,
when we settled on querySelector as the one that provoked least objection.
...
But spending another few months arguing about it hasn't proven that we
are any wiser, nor (importantly) any closer to agreement.


This is why it should be an editorial decision, not a group vote.  The 
least-objectionable alternative is rarely the best alternative, and 
trying to please everyone is a fool's errand.  Hopefully, this time, the 
group will let me, as editor, evaluate the options and supporting 
rationale and make a decision based on that.


Right now, that draft uses find/findAll() simply because they're the 
names that were used throughout the discussion that led to them being 
added.  There are still issues to resolve, however, which I would like 
feedback on.


In particular, is there really value in adding two distinct methods that 
differ only by whether they return 1 element or a collection?  Resolving 
this issue first would help with resolving the naming issue.


It should be noted that JQuery/sizzle does not use querySelector() at 
all, AFAICS. It only uses querySelectorAll() and sometimes switches to 
.getElementById() or document.body.


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

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

[Lachlan Hunt]

On 2012-06-18 16:45, Simon Pieters wrote:

So 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.


The find methods introduce a number of new behaviours that are not 
present in qSA. Some of these features could be introduced into qSA in a 
backwards compatible way, but some features could only be partially 
supported.  The following is an objective look at your proposal, 
detailing what can and cannot be back-ported to the older qSA methods.


(Note: All rationale below stated to apply to documents also applies 
equally to document fragments.)



1. Support for relative selector syntax.

This features implies the :scope pseudo-class when the selector begins 
with a combinator.


  elm.find(">span") ==> elm.querySelector(":scope>span")

This feature also applies to document.find() and there is no 
compatibility problems with adding support for this to document.qSA. 
However, it is only useful when refNodes are supplied (see #3 below).


There is no compatibility problems with adding support for this to 
element.qSA, however it would have limited utility.


* It cannot work when it begins with a descendant combinator as this
  case is indistinguishable from using no combinator.  The reason this
  actually works for element.find is because of feature #3 below.

* It can never match sibling elements of the context object (see #4
  below), so element.qSA("+span") cannot match anything even if :scope
  is implied.

* The reference combinator will only be effective when the subject of
  the selector is a descendant of the context object.
  label.qSA("/for/ input") would only be useful when input is a
  descendant of the label.

* This would be effective for the child combinator.

In summary:

  elm.querySelector(" span") // Not possible to imply :scope.
  elm.querySelector("+span") // Sibling. Not possible to match.
  elm.querySelector("~span") // Sibling. Not possible to match.
  elm.querySelector("/for/ input") // Limited utility.
  elm.querySelector(">span") // Could work.


2. Support for reference nodes.

This feature allows a parameter to specify a set of elements that will 
be matched by :scope.  This does not apply to Element.find.


  var ref = [...] // Collection of elements.
  document.findAll(":scope>span", ref)

This was supported on qSA in previous drafts before the new find/findAll 
methods were added.  It was only removed from qSA because it duplicated 
the functionality of the new methods with no additional benefit.  There 
is no compatibility problems with adding support for this to document.qSA.



3. Implied :scope when a reference element is present.

Like the relative selector syntax, this is another trigger for implying 
:scope.  This applies when a non-null refNodes parameter is passed to 
the document.find methods.  The context object is used when it is an 
Element node, so :scope is always implied in that case.


  elm.find("div p")
  document.find("div p", elm)

Both of those are equivalent to using explicit :scope in:

  elm.querySelector(":scope div p")

This feature cannot be supported by Element.qSA because implying :scope 
would break the following case where the div is not a descendant of the 
context object (elm).


  elm.querySelector("div p")

This cannot be equivalent to the examples above without breaking 
compatibility.


There is no compatibility problems with adding support for this to 
document.qSA.



4. Support for returning elements that are not descendants of the
   context object.

This feature allows a selector to be constructed such that it matches an 
element anywhere in the tree relative to the context element. This 
feature is not relevant to document.find(), since it can already return 
anything from the whole tree.


  elm.find("+span")// span is a sibling
  elm.find("/for/ input")  // input could be anywhere
  elm.find(":not(:scope)") // Everything except the context object

This feature cannot be supported on Element.qSA, even when using eplicit 
:scope, because matching elements need to be descendants of the context 
object.



5. Return type of the findAll method

Although not yet decided, there have been concerns raised about the 
NodeList return type of the querySelectorAll methods.  There has been 
suggestions that findAll instead return either an Array or an Array-like 
object that implements more useful functionality than NodeList currently 
does.  JS libraries tend to use the Array.slice() technique to convert 
node lists to arrays, which they can deal with more effectively.


It's not yet clear if this issue can be addressed by extending the 
current NodeList interface or using an alternative return type.



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,

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

[Charles McCathieNevile]

On Wed, 20 Jun 2012 06:19:22 +0200, Elliott Sprehn   
wrote:


On Tue, Jun 19, 2012 at 1:38 PM, Tab Atkins Jr.  
wrote:



...
This is not a good argument.  qSA is used often enough, and has a long
enough name, that the name is actually a pretty significant
misfeature.  This is a pretty core API, and both it and its precursors
(getElementByID, etc.) are very commonly renamed by libraries
precisely because you need a very short name for such a commonly used
function.



Why does it need a short name? If the name is too long to type then  
that's

an argument for better IDEs. Otherwise you end up with stuff like strncpy
to "save typing". gzip eliminates the file size issue.

I'm in agreement with Marat that find() is not as clear as most DOM APIs
usually are. findBySelector() makes much more sense.


In other words we have the same arguments that we had five years ago, when  
we settled on querySelector as the one that provoked least objection.


getElementsB(y)Selector is consistent with the platform, subject to  
getting the s wrong, awfully long. find is too short for a general  
platform that has lots of ways of finding things and things you might be  
finding. querySelector is just sucky.


But spending another few months arguing about it hasn't proven that we are  
any wiser, nor (importantly) any closer to agreement.


If you want quick typing, alias it. If you want to know what it does  
because you only use it once a month (or in my case about once every six  
months), the name is barely clear enough.


There are no good answers here, since there are significant and competing  
needs.


cheers

Chaals


--
Charles 'chaals' McCathieNevile  Opera Software, Standards Group
je parle français -- hablo español -- jeg kan noen norsk
http://my.opera.com/chaals   Try Opera: http://www.opera.com

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

[Elliott Sprehn]

On Tue, Jun 19, 2012 at 1:38 PM, Tab Atkins Jr. wrote:

> ...
> This is not a good argument.  qSA is used often enough, and has a long
> enough name, that the name is actually a pretty significant
> misfeature.  This is a pretty core API, and both it and its precursors
> (getElementByID, etc.) are very commonly renamed by libraries
> precisely because you need a very short name for such a commonly used
> function.


Why does it need a short name? If the name is too long to type then that's
an argument for better IDEs. Otherwise you end up with stuff like strncpy
to "save typing". gzip eliminates the file size issue.

I'm in agreement with Marat that find() is not as clear as most DOM APIs
usually are. findBySelector() makes much more sense.

- Elliott

- E

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

[Marat Tanalin | tanalin . com]

20.06.2012, 00:38, "Tab Atkins Jr." :
> On Mon, Jun 18, 2012 at 10:59 PM, Simon Pieters  wrote:
>
>>  On Mon, 18 Jun 2012 16:57:17 +0200, Kang-Hao (Kenny) Lu
>>   wrote:
>>  We have lots of shipped APIs with worse names. I think we should live with
>>  past mistakes, try not to make them again, and move on.
>
> This is not a good argument.  qSA is used often enough, and has a long
> enough name, that the name is actually a pretty significant
> misfeature.  This is a pretty core API, and both it and its precursors
> (getElementByID, etc.) are very commonly renamed by libraries
> precisely because you need a very short name for such a commonly used
> function.

There is a key difference between native functionality and one implemented as a 
library -- they quite differently relate to backward compatibility. A library 
can be rewritten partially or even entirely if needed (older applications can 
just continue using older versions of the library), while native functionality, 
once widely implemented, have to be supported forever and in fact cannot (and 
should never) be dropped. 

As for `querySelector()` in particular, its name is indeed not the best, but 
_not_ because it's too long, but because it's not quite _clear_ / 
_self-documenting_. `querySelector()` and `querySelectorAll()` should have been 
named `getElementBySelector()` and `getElementsBySelector()` instead.

In this regard, `find()` is far less clear (and even confusing) as for what it 
does.

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

[Tab Atkins Jr.]

On Mon, Jun 18, 2012 at 10:59 PM, Simon Pieters  wrote:
> On Mon, 18 Jun 2012 16:57:17 +0200, Kang-Hao (Kenny) Lu
>  wrote:
>> (12/06/18 22:45), Simon Pieters wrote:
>>>
>>> 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.
>>
>> I didn't read through all the QSA threads, but isn't the function name
>> itself a mistake that many people don't want to live with?
>
> We have lots of shipped APIs with worse names. I think we should live with
> past mistakes, try not to make them again, and move on.

This is not a good argument.  qSA is used often enough, and has a long
enough name, that the name is actually a pretty significant
misfeature.  This is a pretty core API, and both it and its precursors
(getElementByID, etc.) are very commonly renamed by libraries
precisely because you need a very short name for such a commonly used
function.

~TJ

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

[Brian Kardell]

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"  wrote:

> So 
> 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
>
>

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

[Simon Pieters]

On Mon, 18 Jun 2012 16:57:17 +0200, Kang-Hao (Kenny) Lu  
 wrote:



(12/06/18 22:45), Simon Pieters wrote:

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.


I didn't read through all the QSA threads, but isn't the function name
itself a mistake that many people don't want to live with?


We have lots of shipped APIs with worse names. I think we should live with  
past mistakes, try not to make them again, and move on.


--
Simon Pieters
Opera Software

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

[Travis Leithead]

> -Original Message-
> From: Kang-Hao (Kenny) Lu [mailto:kennyl...@csail.mit.edu]
> 
> (12/06/18 22:45), Simon Pieters wrote:
> > 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.
> 
> I didn't read through all the QSA threads, but isn't the function name itself 
> a
> mistake that many people don't want to live with?
> 
> I'd rather like to see querySelector() marked as "deprecated" so it doesn't 
> appear
> in tutorials in the future.

Despite being "non-optimal" according to a vocal sub-set of people, 
querySelector[All] has been deployed in browsers for around 3-4 years. 
I strongly oppose any notion of altering its behavior now.

As to find/findAll, let's just make sure we get the behavior right the 
second time so we don't go through this again.

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

[Kang-Hao (Kenny) Lu]

(12/06/18 22:45), Simon Pieters wrote:
> 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.

I didn't read through all the QSA threads, but isn't the function name
itself a mistake that many people don't want to live with?

I'd rather like to see querySelector() marked as "deprecated" so it
doesn't appear in tutorials in the future.


Cheers,
Kenny

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

[Simon Pieters]

So 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