Hi Lachlan,
On Jun 22, 2007, at 10:23 PM, Lachlan Hunt wrote:
*Conclusion*
After carefully considering all of these reasons, I have update the
spec to use selectElement() and selectAllElements(), based on the
arguments given above.
http://dev.w3.org/cvsweb/~checkout~/2006/webapi/selectors-api/
Overview.html?content-type=text/html;%20charset=UTF-8
I can live with your suggested names, however, I think cssQuery() /
cssQueryAll() or cssQueryOne() / cssQuery() might be a better
compromise choice.
Arguments against cssQuery:
- Selectors are not just called "Selectors", not "CSS Selectors", and
using "css" in the API may lead people to think selectors are only
for CSS
Arguments for cssQuery:
- Significantly shorter than selectElement()
- Already the name used by some JS implementations of the spec's
functionality
- Authors often informally refer to this kind of feature as a "CSS
query API"
- In practice, the vast majority of the time selectors are used in
conjunction with CSS
Arguments for selectElement:
- Similar to the word "Selector"
Arguments against selectElement:
- Longer than cssQuery
- Very easily confusable with XPath selectSingleNode/selectNodes
which are actively used in web content (enough that we implemented
XPath in WebKit, and we include those methods)
- Very easily confusable with the UI operation of text selection, but
are actually totally unrelated to, say window.selection
For me the bottom line is that while cssQuery may be somewhat
imprecise, it is at the very least not ambiguous or confusable with
very different operations. I think the desire to stop propagating an
already common and relatively harmless misconception is outweighed by
the potential for genuine confusion.
I hope you will consider these arguments, as well as Bjoern's
objection, but I'm happy to leave the decision to you, as long as the
name does not end up outrageously long.
Regards,
Maciej
