Sorry for the delayed response. We've had a big windstorm up here in the Pacific Northwest that continues to leave many without power, internet or phone.
We'd really like to see naming to be meaningful for this and all APIs. The goal should be to have a DOM that holds together as one, and therefore the names matter – they need to seem like one intelligently-designed API. Generic names such as select() and match() don't help anyone unless they are for performing generic operations. To suggest that names don't matter and "aaaaa" is fine is just wrong in our opinion. We need to have an API set that people can read and understand without having to go to reference material all the time to ask themselves "Hmm. Now what does select() do in this particular situation?". Thanks -Dave -----Original Message----- From: Anne van Kesteren [mailto:[EMAIL PROTECTED] Sent: Friday, December 15, 2006 3:00 AM To: Ian Hickson Cc: Dave Massy; Web API WG (public) Subject: Re: Selectors API naming On Fri, 15 Dec 2006 07:58:03 +0100, Ian Hickson <[EMAIL PROTECTED]> wrote: > My only concern here is that we avoid the mistake that was made with > getElementsByTagName and getElementById -- the names should be easy to > type and short. I honestly think that if the one-item method is shorter > than about 6 or 7 characters, then we've made a mistake. You mean longer than? > So I think "matchSelector" is too long. I think "matchSingle" is too > long. I think "select" and "match" are fine. I'd love to use "select"... > It doesn't matter what the words actually are. I think "aaaaa" is fine > too (though it wouldn't be my first choice). As Maciej points out, we > just have to make sure we don't pick a name that makes everyone just > alias the > method to $ or $$ or something equivalent. Yeah, I agree with this. -- Anne van Kesteren <http://annevankesteren.nl/> <http://www.opera.com/>
