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

(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 (<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."

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

Received on Thursday, 21 June 2012 13:57:21 UTC