What's in a name?
There's a little debate going on in the WebAPI working group at the W3C about the naming of some methods.
The proposed names in the Selectors API spec include match() and matchAll(). Feedback was given to the WG that this was a too generic and it would be better to have descriptive names such as getElementBySelector/getElementsBySelector that follow the names of existing DOM functions of getElement(s)By*. This was met with initial resistance and there's certainly a good argument for keeping names short. However having consistency of naming and having the name describe the functionality is something we believe is important.
Many tools now offer auto-complete and developers may type "get" and see a drop-down of available methods on the object that start with those letters. Experienced web developers may not use those development techniques but an increasing number of less experienced developers for whom speed of development is essential do use these tools to help them find the functionality they are looking for. Consistent naming helps deliver a better developer experience. We all know that developers rarely look at the API documentation in the same way that I only get around to looking at the instruction manual for a new gadget if I'm completely at a loss for how the thing works.
It looks like public feedback at http://lists.w3.org/Archives/Public/public-webapi/2006Dec/ and on Anne's post would agree that a descriptive name is important. Although there are certainly people who want to save themselves a few keystrokes as well and would be happy calling something foo().
Of course as has been pointed out we haven't been super consistent in the past around naming. However the argument that we haven't been consistent or good about names in the past is a poor reason for failing to try to be consistent in the future. There is probably not such thing as the perfect name but we should at least strive for the best we can come up with.
Thanks
-Dave
