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

On Thu, 21 Jun 2012 15:56:45 +0200, Kang-Hao (Kenny) Lu  
<kennyluck@csail.mit.edu> 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 (<name goes here>) who were
> strongly opposed to X and a group vote happened and a decision was made
> by (<name goes here>). 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

Received on Thursday, 21 June 2012 15:28:50 UTC