W3C home > Mailing lists > Public > public-webapi@w3.org > July 2007

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

From: Doug Schepers <schepers@w3.org>
Date: Thu, 19 Jul 2007 16:58:56 -0400
Message-ID: <469FD090.7020208@w3.org>
To: Web API public <public-webapi@w3.org>


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 

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

-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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:16:24 UTC