If you want to be accurate, the methods should be named
getElementByCSSSelector
getElementsByCSSSelector
and be integrated with the CSS DOM module.
There's one thing I don't understand ? Why returning a StaticNodelist ?
if I want something static I just use some xpath to get a snapshot.
CSS
On Dec 20, 2006, at 14:51, Anne van Kesteren wrote:
No, the Selectors specification is separate from CSS.
That belief only exists within the small ivory tower known as The
CSS Working Group. To those of us who actually use the stuff for
work, that distinction is a totally moot political
This is actually in reply to a number of people.
Ian Hickson [mailto:[EMAIL PROTECTED] wrote:
[Chris Wilson wrote]
and that makes the APIs feel like they were designed together.
Sure... But we have to learn from the lessons we were taught by DOM and
the way that authors are writing code. One
On Wed, 20 Dec 2006 18:55:42 +0100, Chris Wilson
[EMAIL PROTECTED] wrote:
Anne van Kesteren [mailto:[EMAIL PROTECTED] wrote:
[Dave Massy wrote:]
As I mentioned previously a more complete example of staticNodeList
usage would also be appreciated.
It's not clear to me what you mean with
Chris Wilson [EMAIL PROTECTED]
Not that I'm overly energised with naming, but...
As Martijn said, I believe people will map document.matchAll almost as
often to $$ as document.getElementsBySelector - so I'd much rather stick
with the pattern, and presume that if developers want to map to a()
On 12/20/06, Jim Ley [EMAIL PROTECTED] wrote:
Not that I'm overly energised with naming, but...
...
I agree with this view entirely. getSomething is a pattern worth keeping
for developer sanity.
JS programmers use short names for these things. Like $() instead of
getElementById. The names
Robert Sayre [EMAIL PROTECTED]
On 12/20/06, Jim Ley [EMAIL PROTECTED] wrote:
Not that I'm overly energised with naming, but...
...
I agree with this view entirely. getSomething is a pattern worth keeping
for developer sanity.
JS programmers use short names for these things. Like $()
On 12/20/06, Robert Sayre [EMAIL PROTECTED] wrote:
On 12/20/06, Jim Ley [EMAIL PROTECTED] wrote:
No, one group of JS programmers do that, it is not representative of the
entire industry at all
Mappings to getElementById in some popular JS libraries:
Yahoo UI: get()
Prototype.js: $()
On Dec 20, 2006, at 23:02, Ian Hickson wrote:
This thread is going nowhere. I propose that we let the document's
editor
take into account all the input and then have the editor make a
decision
that addresses everyone's concerns as much as possible. There's no
point
us arguing over names,
Hi-
Ian Hickson wrote:
This thread is going nowhere. I propose that we let the document's
editor take into account all the input and then have the editor make a
decision that addresses everyone's concerns as much as possible.
I agree that most of the useful arguments have been made.
On Wed, 20 Dec 2006, Robin Berjon wrote:
On Dec 20, 2006, at 23:02, Ian Hickson wrote:
This thread is going nowhere. I propose that we let the document's
editor take into account all the input and then have the editor make a
decision that addresses everyone's concerns as much as
On Wed, 20 Dec 2006 23:25:34 +0100, Doug Schepers
[EMAIL PROTECTED] wrote:
I agree that most of the useful arguments have been made. Stripping
away the arguments themselves, there are only 3 stances:
1) Shorter names are preferred;
2) More descriptive names are preferred;
3) Names
Hi-
Some context...
Ian Hickson wrote:
I propose that we let the document's editor
take into account all the input and then have the editor make a decision
that addresses everyone's concerns as much as possible.
[...]
I have confidence in Anne; I'm sure he would not design by theology,
On Wed, 20 Dec 2006 23:46:08 +0100, Doug Schepers [EMAIL PROTECTED] wrote:
One of the arguments that was made was also that the existing methods
have failed, which would make #3 the odd one out and probably #2 as
well. I don't really care what the final name, but it should match
the first
On 12/20/06, Anne van Kesteren [EMAIL PROTECTED] wrote:
One of the arguments that was made was also that the existing methods have
failed, which would make #3 the odd one out and probably #2 as well. I
don't really care what the final name, but it should match the first
principle...
I don't
On Wed, 20 Dec 2006, Doug Schepers wrote:
Given the editor's strong stance for your own viewpoint, it seems that
your deference to him is not altruistic.
This is the only item that's been heavily argued on the mailing list. I'd
be saying the same thing if Anne had suggested the opposite.
Jon Ferraiolo [EMAIL PROTECTED] wrote:
FWIW - Dojo's function is actually [window.]dojo.byId()
and I believe that Yahoo's is [window.]YAHOO.util.get()
Yes, those are the canonical locations. They are usually copied
around. But we arguing about the right side of the last period anyway.
On
? I never claimed there were technical problems with matchAll or
select either - just that they didn't fit the pattern established by
the other DOM Recommendation APIs, and therefore weren't the best choice
for an API that was supposed to fit in the larger scope of the web
object model platform.
On 12/20/06, Chris Wilson [EMAIL PROTECTED] wrote:
? I never claimed there were technical problems with matchAll or
select either - just that they didn't fit the pattern established by
the other DOM Recommendation APIs,
Web authors don't encounter a consistent pattern, and what is and
isn't
Robert Sayre [mailto:[EMAIL PROTECTED] wrote:
On 12/20/06, Chris Wilson [EMAIL PROTECTED] wrote:
? I never claimed there were technical problems with matchAll or
select either - just that they didn't fit the pattern established
by
the other DOM Recommendation APIs,
Web authors don't
I know it's kind of late in the game to be discussing this, but I prefer
getElementBySelector(), simply because it matches what has come before. In
all seriousness, you'll hear people complain about having to use select as
the function name, claiming that is too long. If people want shorter
Hi-
I agree. I think getElementsBySelector() is a good name that follows
a meaningful naming convention.
Having a slightly longer name for a method doesn't prevent people from
making shorter aliases, but having an unclear name does prevent people
from understanding it intuitively.
Hi-
Robert Sayre wrote:
On 12/20/06, Doug Schepers [EMAIL PROTECTED] wrote:
That those methods have failed is not conclusive.
Well, the possibility has certainly been widely discussed.
http://www.google.com/search?q=DOM+sucks
Huh? The first 2 pages (at least) of that search seemed to
On 12/20/06, Doug Schepers [EMAIL PROTECTED] wrote:
Huh? The first 2 pages (at least) of that search seemed to complain
about the lack of consistency in support among different browsers, not
about the supposed failure of the longer DOM method names. [1]
Can't say it much better than
DOM
Hi, Robert-
Robert Sayre wrote:
On 12/20/06, Doug Schepers [EMAIL PROTECTED] wrote:
Huh? The first 2 pages (at least) of that search seemed to complain
about the lack of consistency in support among different browsers, not
about the supposed failure of the longer DOM method names. [1]
On Wednesday, December 20, 2006 10:25 pm, Doug Schepers wrote:
Hi, Robert-
I think that the substance of that critique is about the functionality
and the implementation (memory and speed) footprint of DOM.
I just dropped a comment on that discussion, because to be frank it's one of
the
26 matches
Mail list logo
