RE: Selectors API naming

The DOM L3 XPath specification is a Note, not a Recommendation.  I would
expect to have the same discussion about minimalism and polluting the
document object if it were to be Proposed.

-----Original Message-----
From: Robert Sayre [mailto:sayrer@gmail.com] 
Sent: Wednesday, December 20, 2006 11:35 AM
To: Martijn
Cc: Jim Ley; Chris Wilson; Ian Hickson; Dave Massy; Anne van Kesteren;
Web API WG (public)
Subject: Re: Selectors API naming

On 12/20/06, Martijn <martijn.martijn@gmail.com> wrote:
>
> So would thes popular JS libraries stop using those names if
> document.getElementById was called document.id for example?

Who can say?

> It seems to me they wouldn't as it would still be too long for their
> taste (the maximum length in these examples is 4 characters).

Well, they tend to like putting things in the global namespace, so
they maybe they would use "id()".

>
> > I guess that's the nice thing about getElementsBySelector. It's like
> > picking 6 names all at once. :)
>
> I don't think getElementsBySelector is picking 6 names at once at all.

I've been doing experimental implementations of
document.getElementsBy* methods and I'm willing to guarantee that it
is effectively picking many names. I can't even remember the ones I'm
working on. The problem is that it requires JavaScript programmers to
type 22 characters before encountering characters that uniquely
identify it, and 19 characters before it's clear that the method will
return a NodeList. The JS library authors of the world seem to
understand this argument.

If XPath can use "evaluate"[1], I don't see what's wrong with
"matchSingle/matchAll".

-- 

Robert Sayre

[1]
<http://www.w3.org/TR/DOM-Level-3-XPath/xpath.html#XPathEvaluator-evalua
te>

Received on Wednesday, 20 December 2006 19:49:08 UTC