Selectors API Names (was: CSS Query API: selectorQuery(...))

Hi-

Just to alleviate any confusion, Bjoern is referring to the Selectors 
API spec [1] (not "CSS Query API", which is not the name of a WebAPI 
spec).

[1] http://www.w3.org/TR/selectors-api/

Regards-
-Doug Schepers
W3C Staff Contact, SVG, CDF, and WebAPI


Bjoern Hoehrmann wrote:
> Hi,
> 
>   The WebAPI Working Group is considering to conduct a poll to finally
> put the method naming issue in the CSS Query API specification to rest;
> Charles asked us to propose alternatives to selectElement/selectAllEle-
> ments. To this end, I would like to propose using two [1] of 
> 
>   selectorQuery(...) / .selectorQueryAll(...) / .selectorQueryOne(...)
> 
> instead. I believe these names offer the following benefits:
> 
>   * This is the only set of names where I know of no working 
>     group member with a good reason to strongly dislike them.
> 
>   * Many working group members have indicated these names work
>     for them. Even Anne!
> 
>   * They are lexically distant from the selectNodes and select-
>     SingleNode XPath methods that serve a very similar purpose.
> 
>   * They are lexically distant from DOM Range manipulation
>     methods like DOM T&R's .selectNode, Dojo's .selectElement
> 
>   * They are quite unlikely to clash with other future DOM
>     methods and attributes designed for other purposes.
> 
>   * In particular, DOM attributes that reflect XML attributes;
>     selectElement='' is much more likely than selectorQuery='',
>     c.f. SVG's targetElement='...'
> 
>   * They are just as long as the .select(All)Element(s) names.
> 
> I understand somebody has to make the same proposal (or second this
> one) for it to be considered; if you think these names should be
> considered, or even think these would be better than selectElement,
> you are very welcome to do that.
> 
> [1] There have been arguments that the shorter name should return a
>     single element so authors write possibly more efficient code,
>     and that the shorter name should return many elements because
>     that is required more often and saves a few keystrokes. I think
>     this is out of scope of the proposal and should be a separate
>     question in the poll, if we are going to conduct one.
> 
> Thanks,

--

Received on Thursday, 19 July 2007 21:00:10 UTC