Re: Selectors API naming

On Jan 27, 2007, at 5:36 PM, Charles McCathieNevile wrote:

> "they give no idea what they will do, are more likely to conflict  
> with function
> names in existing code that do other things, and if you want to  
> shorten things
> document.foo() is already a pain and you would write a wrapper even  
> for that,
> called get() or something".

OK, so I'm going to assume the following pairs were ruled out for  
because it seemed unclear what they will do and because they are more  
likely to conflict:

match()/matchAll()
get()/getAll()

The following was considered clear, but the two names too confusably  
similar:

getElementBySelector()/getElementsBySelector()

Thus, the following was the winner:

getElementBySelector()/getElementListBySelector()

How about the following (suggested in various places on the thread):

cssQuery()/cssQueryAll()
bySelector()/bySelectorAll()
bySelector()/listBySelector()
getBySelector()/getBySelectorAll()

Note that CSS selectors today cannot address non-element nodes,  
however, this may not be the case for all time. If they ever become  
able to address text nodes directly, it will actually be better not  
to have "Element" in the name.

Here are other brief names that make the connection to Selectors (AKA  
CSS Selectors) clear in varying degrees:

queryCSS()
matchCSS()
cssMatch()
matchSelector()
matchSel()
bySel()
querySel()
querySelector()

(Various forms of long names left as an excercise to the reader).

Please consider both of these sets of names to be my constructive  
alternate proposals, as requested. I think all of them satisfy the  
requirement that it is clear what they do (look things up by  
selector), are unlikely to conflict with names in existing code(*)  
Note that cssQuery in particular was proposed by Björn, a member of  
the Working Group, so I hope it was considered during the discussion.  
Perhaps it was rejected, but the reason is not mentioned in the  
minutes or your note.

Regards,
Maciej

* - This seems unlikely in any case since they are Document methods;  
and surely things like getAttribute and setAttribute exist in non-DOM  
code, but thanks to the magic of object oriented programming and the  
fact that such names are class-scoped this is not a big problem.

Received on Monday, 29 January 2007 05:54:41 UTC