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

(12/06/21 23:28), Charles McCathieNevile wrote:
> 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:
>>> 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 (<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.

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 (<pointer goes here>) with X people, Y % of
them are Web developers (<pointer to the statistics goes here>). 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 that I think what Lachy
concluded ("selectElement") is better then what we have right now, I
don't think that's the best name.

(12/06/21 22:42), Lachlan Hunt wrote:
> 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.

Well, without detailed statistics it can't be proved that the editor
making the decision would have been the best we can do. For example, in
that document, I prefer "cssQuery" over "selectElement" but as I said,
"selectElement" is better than "querySelector".


Cheers,
Kenny

Received on Thursday, 21 June 2012 16:28:41 UTC