Anne van Kesteren ann...@opera.com wrote:
On Tue, 13 Jan 2009 11:17:08 +0100, Anne van Kesteren ann...@opera.com
wrote:
Since my initial e-mail did not seem to have done it, could you please
take a look at the source code of the respective test and tell me if you
see a problem there?
Anne van Kesteren ann...@opera.com wrote:
On Mon, 12 Jan 2009 15:25:33 +0100, Stewart Brodie
stewart.bro...@antplc.com wrote:
Ian Hickson i...@hixie.ch wrote (on 25 July 2008):
I've made [getElementsByClassName] consistent with how classes work in
CSS
(case-insensitive for quirks and
On Tue, 13 Jan 2009 11:08:56 +0100, Stewart Brodie
stewart.bro...@antplc.com wrote:
Specifically: test 14 - tests for case-sensitivity in a document that is
in quirks mode.
Are you saying that this change has now been reversed and the comparisons
are always case-sensitive, thus reintroducing
On Tue, 13 Jan 2009 11:17:08 +0100, Anne van Kesteren ann...@opera.com
wrote:
Since my initial e-mail did not seem to have done it, could you please
take a look at the source code of the respective test and tell me if you
see a problem there?
Ian Hickson i...@hixie.ch wrote (on 25 July 2008):
I've made [getElementsByClassName] consistent with how classes work in CSS
(case-insensitive for quirks and case-sensitive otherwise).
I was looking for some tests for this API and found some from Opera (found
at
On Thu, 27 Nov 2008 22:38:32 +0100, Garrett Smith [EMAIL PROTECTED]
wrote:
It is often desirable to capture events on bubble and interrogate the
EventTarget using a hasClassName function to see if it has a className
that the program is concerned with.
[...]
HTML5 already has the
On Sat, 14 Jan 2006, Karoly Negyesi wrote:
A getElementsByCSSSelector IMO would be great and introduces minimal
plus burden on browsers -- they have CSS selector code anyways.
It's very unfriendly that I can do magic with CSS2/3 selectors and then
I need to translate them myself if I want
On Tue, 6 Sep 2005, Lachlan Hunt wrote:
[DOMTokenString]
I've thought about it some more, and it may be difficult to do with the
way the add() and remove() are currently defined with no return value. I
assume that means you're intending for these functions to modify the
string itself.
On 7/9/07, Jonas Sicking [EMAIL PROTECTED] wrote:
I agree with Simon here. Allowing arrays to be passed in doesn't add any
extra value and complicates the implementation significantly. I think
that the by far most common case is going to be passing a single class
name, so adding multiple ways of
Lachlan Hunt wrote:
Simon Pieters wrote:
getElementsByClassName is defined to take an array of strings as
argument. What exactly is an array? A native ECMAScript array, or
anything with a 'length' property and the properties '0' - length-1?
Is a DOMTokenList an array that can be passed to
getElementsByClassName is defined to take an array of strings as argument.
What exactly is an array? A native ECMAScript array, or anything with a
'length' property and the properties '0' - length-1? Is a DOMTokenList an
array that can be passed to gEBCN?
Firefox has implemented it as a
On Sun, 05 Nov 2006 10:55:05 +0100, Alexey Feldgendler
[EMAIL PROTECTED] wrote:
I think this hasn't been suggested before. Perhaps the method should
accept a DOMTokenString as argument instead of an array. This allows
things like ele.getElementsByClassName(ele.className) etc. The only
problem
Lachlan Hunt wrote:
Anne van Kesteren wrote:
This allows things like ele.getElementsByClassName(ele.className) etc.
anything that accepts a DOMString will automatically accept a DOMTokenString,
including getElementsByClassName. So your example will already work.
It seems
On Sun, 05 Nov 2006 16:18:32 +0600, Anne van Kesteren [EMAIL PROTECTED] wrote:
I think this hasn't been suggested before. Perhaps the method should
accept a DOMTokenString as argument instead of an array. This allows
things like ele.getElementsByClassName(ele.className) etc. The only
problem
On Sun, 05 Nov 2006 14:27:14 +0100, Alexey Feldgendler
[EMAIL PROTECTED] wrote:
I still don't get it what's the advantage of having
getElementsByClassName take a DOMTokenString argument over a plain
DOMString.
Oh right, sorry. Yeah, I suppose a DOMString makes more sense.
--
Anne van
Dean Edwards wrote:
The point is that there is room for all of these methods for
retrieving DOM nodes. As there is no useful existing standard let's
add stuff that people actually want instead of referring them to
vapour ware.
I guess the question is why bother with getElementByClassName if a
There seems to be a question on how confusing a method would be for developers.
I went and asked 4
people I know that are just learning Javascript for the first time. For two of
them javascript is
their first programing language, the other two already know other languages.
Given this markup:
p
Ian Hickson wrote:
On Mon, 23 Oct 2006, Jonathan Worent wrote:
When asked if they would prefer a comma separated list or an array,
there were mixed feelings. Three indicated a preference to a comma
separated list, the other said he would expect to pass an array. Given
this I would suggest not
Na , Ian Hickson [EMAIL PROTECTED] escreveu:
On Mon, 23 Oct 2006, Dean Edwards wrote:
Personally, I prefer a comma delimited list. Passing an array seems
yukky.
Really? I always thought the comma-separated argument to window.open()
was
one of the ugliest APIs ever...
Are there any
Na , Ian Hickson [EMAIL PROTECTED] escreveu:
On Tue, 24 Oct 2006, Joao Eiras wrote:
The question is.. is there really the need for the array ? Most bindings
support variable arguments.
The initial proposal used varargs, but people pointed out that that made
it difficult to call the method
On Tue, 24 Oct 2006, Joao Eiras wrote:
Na , Ian Hickson [EMAIL PROTECTED] escreveu:
On Tue, 24 Oct 2006, Joao Eiras wrote:
The question is.. is there really the need for the array ? Most
bindings support variable arguments.
The initial proposal used varargs, but people pointed
Ian Hickson wrote:
On Mon, 23 Oct 2006, Dean Edwards wrote:
Personally, I prefer a comma delimited list. Passing an array seems
yukky.
Really? I always thought the comma-separated argument to window.open() was
one of the ugliest APIs ever...
This isn't the same thing. We are faking
On Tue, 24 Oct 2006 06:17:20 +0700, Joao Eiras [EMAIL PROTECTED] wrote:
It's an array. Most languages support arrays. Why would there be a
problem?
The question is.. is there really the need for the array ?
Most bindings support variable arguments.
Array: getElementsByClassName([c1, c2]);
On Sat, 21 Oct 2006 09:36:37 +0200, Ian Hickson [EMAIL PROTECTED] wrote:
This omnibus edition of your WHATWG mail includes replies to 50 or so
separate e-mails about getElementsByClassName(). Thanks to everyone for
their comment on this issue.
So what's the use case over matchAll(.foo.bar.baz)
On Sun, 22 Oct 2006 20:03:48 +0200, Dean Edwards [EMAIL PROTECTED] wrote:
So what's the use case over matchAll(.foo.bar.baz) ..?
I didn't know that this had been implemented. Which browser is
supporting it?
It's not supported yet. What makes you think it is?
--
Anne van Kesteren
Anne van Kesteren wrote:
On Sun, 22 Oct 2006 20:03:48 +0200, Dean Edwards [EMAIL PROTECTED] wrote:
So what's the use case over matchAll(.foo.bar.baz) ..?
I didn't know that this had been implemented. Which browser is
supporting it?
It's not supported yet. What makes you think it is?
On Sun, 22 Oct 2006 20:16:06 +0200, Dean Edwards [EMAIL PROTECTED] wrote:
So what's the use case over matchAll(.foo.bar.baz) ..?
I didn't know that this had been implemented. Which browser is
supporting it?
It's not supported yet. What makes you think it is?
You asked for a comparison
This omnibus edition of your WHATWG mail includes replies to 50 or so
separate e-mails about getElementsByClassName(). Thanks to everyone for
their comment on this issue.
On Mon, 5 Sep 2005, Brad Neuberg wrote:
That's right. We are defining HTML5 and the DOM extensions to support
it.
Shadow2531 wrote:
I was *messing* around with 2 different *examples*.
1.) http://shadow2531.com/opera/js/getElementsByClassName/000.html
That one supports:
getElementsByClassName(string);
getElementsByClassName(array);
If the string has spaces in it, it's considered that nothing will
match
On 2/15/06, Ric Hardacre [EMAIL PROTECTED] wrote:
Shadow2531 wrote:
I was *messing* around with 2 different *examples*.
1.) http://shadow2531.com/opera/js/getElementsByClassName/000.html
That one supports:
getElementsByClassName(string);
getElementsByClassName(array);
If the
On 2/3/06, Gervase Markham [EMAIL PROTECTED] wrote:
Shadow2531 wrote:
O.K. Then, it should be getElementByClassName*s*() where you have
have 1 or more classname arguments. If you pass more than 1 class
name, both class names have to be present in the classname attribute
for the element
Dean Edwards wrote:
Jim Ley wrote:
That is not immediately apparent, and neither is it apparent that a
classname specific shortname is worthwhile when a CSSSelector one
would be more appropriate.You don't continually add methods,
methods are complexity, they need writing, they need
Hi,
James Graham wrote:
Lachlan Hunt wrote:
James Graham wrote:
Also I would be surprised if there weren't multiple implementations
of getElementsByClassname floating around in javascript libraries. So
you can't really call it unimplemented.
While there are many JavaScript implementations
On 2/5/06, Ian Hickson [EMAIL PROTECTED] wrote:
I can certainly see myself speccing a getElementsBySelector() API as part
of Selectors 2. But either way, the spec for gEBS is simple; it returns
the same type as getElementsByTagName(), it is accessible from Document
and Element nodes and
On Mon, 06 Feb 2006 17:14:18 +0200, Brad Fults [EMAIL PROTECTED] wrote:
On 2/5/06, Ian Hickson [EMAIL PROTECTED] wrote:
...
If this is anywhere in the near future, I'm all for dropping
getElementsByClassName() in favor of this broader solution. But if
this is high in the sky and won't be
On Mon, 6 Feb 2006, Brad Fults wrote:
On 2/5/06, Ian Hickson [EMAIL PROTECTED] wrote:
I can certainly see myself speccing a getElementsBySelector() API as part
of Selectors 2. But either way, the spec for gEBS is simple; it returns
the same type as getElementsByTagName(), it is accessible
Jim Ley wrote:
That is not immediately apparent, and neither is it apparent that a
classname specific shortname is worthwhile when a CSSSelector one
would be more appropriate.You don't continually add methods,
methods are complexity, they need writing, they need testing etc. you
have to
On 2/5/06, James Graham [EMAIL PROTECTED] wrote:
Jim Ley wrote:
So something with no implementation should be taken over something
with an existing implementation, that's pretty odd.
Surely you can see that's a insane argument given the relative
complexity of implementing the
On 2/4/06, Lachlan Hunt [EMAIL PROTECTED] wrote:
While there are many JavaScript implementations (I even wrote one myself
a few months ago), all the custom JS implementations count for exactly
zero native implementations in UAs, which is what really counts.
I'm not sure what relevance that
On 2/5/06, James Graham [EMAIL PROTECTED] wrote:
Jim Ley wrote:
On 2/5/06, James Graham [EMAIL PROTECTED] wrote:
DOM 3 XPath is of course only defined for XML, whilst it's no trouble
defining it for valid HTML, it's not currently, for this reason I
would prefer just having a CSSSelector
Jim Ley wrote:
On 2/5/06, James Graham [EMAIL PROTECTED] wrote:
Jim Ley wrote:
On 2/5/06, James Graham [EMAIL PROTECTED] wrote:
DOM 3 XPath is of course only defined for XML, whilst it's no trouble
defining it for valid HTML, it's not currently, for this reason I
would prefer just having a
On Sun, 5 Feb 2006, Lachlan Hunt wrote:
Ian has already indicated that the specification of a method to
collect DOM elements based on a CSS selector is best left to the CSS
WG.
I'd like to know why this is the case. Defining a DOM method seems like
it would be out of scope for
On 2/5/06, Ian Hickson [EMAIL PROTECTED] wrote:
On Sun, 5 Feb 2006, Lachlan Hunt wrote:
Probably doesn't matter which group does it since it'd end up being me
doing the work either way...
Well the review processes are slightly different :)
I can certainly see myself speccing a
Jim Ley wrote:
On 2/4/06, Lachlan Hunt [EMAIL PROTECTED] wrote:
Jim Ley wrote:
For example, if an author
marked up dates in their document like this (due to the lack of a date
element)
span class=date2006-02-03T01:30Z/date
A nice use case, and one well met by XBL including the currently
On Sun, 5 Feb 2006, dolphinling wrote:
Actually, the javascript solution would be _superior_ to the XBL one in
this case. The screenreader wouldn't pick up on the XBL at all, and
would read the content as-is, likely confusing the user.
Um, there's no reason an aural browser couldn't
Ian Hickson wrote:
On Sun, 5 Feb 2006, dolphinling wrote:
Actually, the javascript solution would be _superior_ to the XBL one in
this case. The screenreader wouldn't pick up on the XBL at all, and
would read the content as-is, likely confusing the user.
Um, there's no reason an aural
On Sat, 04 Feb 2006 03:49:23 +0200, Brad Fults [EMAIL PROTECTED] wrote:
On 2/3/06, Jim Ley [EMAIL PROTECTED] wrote:
...
I can't believe that you're so insistent upon this extremely narrow
set of use cases and that there aren't any other popular use cases for
getElementsByClassName().
If
On 2/4/06, Brad Fults [EMAIL PROTECTED] wrote:
I can't believe that you're so insistent upon this extremely narrow
set of use cases and that there aren't any other popular use cases for
getElementsByClassName().
It's the only one that's ever been voiced without the extreme
prompting now
On 2/4/06, Lachlan Hunt [EMAIL PROTECTED] wrote:
Jim Ley wrote:
For example, if an author
marked up dates in their document like this (due to the lack of a date
element)
span class=date2006-02-03T01:30Z/date
A nice use case, and one well met by XBL including the currently
implemented
Le 2006-02-03 à 19:20, Simon Pieters a écrit :
I have a some markup like this:
ul
lia href=#tab1Tab 1/a/li
lia href=#tab2Tab 2/a/li
/ul
div id=tab1 class=pane
...
/div
div id=tab2 class=pane
...
/div
With the help of a style sheet, the
Jim Ley wrote:
On 2/4/06, Brad Fults [EMAIL PROTECTED] wrote:
The reasons why XBL is not currently an acceptable substitute are
numerous, including its extremely limited implementation,
So something with no implementation should be taken over something
with an existing implementation, that's
James Graham wrote:
Also I would be surprised if there weren't multiple
implementations of getElementsByClassname floating around in javascript
libraries. So you can't really call it unimplemented.
While there are many JavaScript implementations (I even wrote one myself
a few months ago),
On 2/3/06, Gervase Markham [EMAIL PROTECTED] wrote:
Musing...
If you have:
p class=foo barFred/p
p class=bar fooBarney/p
p class=foo baz barWilma/p
which should be picked up by getElementsByClassName(foo bar)?
In the string split mode, it would pick up all three. However, I
suggest
Shadow2531 wrote:
I just threw them together as a proof of concept, but I have no doubt
that the class attribute value should be a space separated list of
classnames and the getElementByClassName function should split up the
class attribute value into an array and then search for the class
On 2/3/06, Shadow2531 [EMAIL PROTECTED] wrote:
O.K. Then, it should be getElementByClassName*s*() where you have
have 1 or more classname arguments. If you pass more than 1 class
name, both class names have to be present in the classname attribute
for the element to match.
I just to be
Shadow2531 wrote:
O.K. Then, it should be getElementByClassName*s*() where you have
have 1 or more classname arguments. If you pass more than 1 class
name, both class names have to be present in the classname attribute
for the element to match.
This seems like a sensible change. Call it
On 2/3/06, Gervase Markham [EMAIL PROTECTED] wrote:
This seems like a sensible change. Call it getElementsByClassNames()
would make it obvious that if you supply multiple class names, you get
only elements with all those names. And it would be a reasonably obvious
reduction that if you just
Gervase Markham wrote:
Brad Fults wrote:
I see this is still an open issue[1]. Is this now implemented as #1
(space-delimited class names to match)?
I suggest either going with the space-delimited approach (as it's
language-agnostic and well-defined at least) or with Aankhen's
suggestion
On 2/3/06, Gervase Markham [EMAIL PROTECTED] wrote:
This seems like a sensible change. Call it getElementsByClassNames()
would make it obvious that if you supply multiple class names, you get
only elements with all those names. And it would be a reasonably obvious
reduction that if you just
Jim Ley wrote:
Rather than talk about technical details, can be talk about the actual
use cases please, working groups keep on creating things which need
implementing, testing etc. without once giving the use case. This
thread is now 21 messages old and there's not one use case which is
ROBO Design wrote:
I believe there's some disagreement on what is this function supposed to
do.
Well, not according to the current spec, which says:
1. Should it return *all* elements which have *all* the class names wanted?
this one. Of course, you may disagree with the spec.
4. Should
On Fri, 03 Feb 2006 15:31:37 +0200, Ric Hardacre [EMAIL PROTECTED]
wrote:
this also raises the possibility of some confusion as the order of
inheritance is important:
foo
{
color: red;
}
bar
{
color: blue;
}
in the quoted example Fred and Wilma would be blue and barney red. so
On Fri, 03 Feb 2006 15:39:26 +0200, Gervase Markham [EMAIL PROTECTED]
wrote:
ROBO Design wrote:
...
Well, not according to the current spec, which says:
1. Should it return *all* elements which have *all* the class names
wanted?
this one. Of course, you may disagree with the spec.
Ric Hardacre wrote:
Gervase Markham wrote:
If you have:
p class=foo barFred/p
p class=bar fooBarney/p
p class=foo baz barWilma/p
which should be picked up by getElementsByClassName(foo bar)?
this also raises the possibility of some confusion as the order of
inheritance is important:
foo
On 2/3/06, Gervase Markham [EMAIL PROTECTED] wrote:
Jim Ley wrote:
Rather than talk about technical details, can be talk about the actual
use cases please, working groups keep on creating things which need
implementing, testing etc. without once giving the use case. This
thread is now 21
Jim Ley wrote:
I know nothing of this attaching events to a class name of which you
speak. Can you give me a reference to a document or proposal describing it?
It's the one use case described in this mailing list,
See e.g.
Lachlan Hunt wrote:
Ric Hardacre wrote:
Gervase Markham wrote:
If you have:
p class=foo barFred/p
p class=bar fooBarney/p
p class=foo baz barWilma/p
which should be picked up by getElementsByClassName(foo bar)?
this also raises the possibility of some confusion as the order of
On 2/3/06, Gervase Markham [EMAIL PROTECTED] wrote:
Jim Ley wrote:
the document of course shows no use cases at all.
Is there some doubt that the ability to tag an arbitrary set of elements
and later easily get an array of those elements is a useful feature for
web development?
I've yet
Jim Ley wrote:
On 2/3/06, Gervase Markham [EMAIL PROTECTED] wrote:
Jim Ley wrote:
the document of course shows no use cases at all.
Is there some doubt that the ability to tag an arbitrary set of elements
and later easily get an array of those elements is a useful feature for
web
Jim Ley wrote:
Yes, but they're all using it to attach events to every one of the
class, which is why you have to look at use cases, the reason they're
doing it is not because getElementsByClassName is missing, but because
addEventListenerToClass or -moz-binding etc. are missing.
But why
Gervase Markham wrote:
Brad Fults wrote:
I see this is still an open issue[1]. Is this now implemented as #1
(space-delimited class names to match)?
I suggest either going with the space-delimited approach (as it's
language-agnostic and well-defined at least) or with Aankhen's
suggestion of
On 2/3/06, Jim Ley [EMAIL PROTECTED] wrote:
On 2/3/06, Gervase Markham [EMAIL PROTECTED] wrote:
Jim Ley wrote:
Yes, but they're all using it to attach events to every one of the
class, which is why you have to look at use cases, the reason they're
doing it is not because
Jim Ley wrote:
On 2/3/06, Michel Fortin [EMAIL PROTECTED] wrote:
Le 2006-02-03 à 09:30, Jim Ley a écrit :
So to generalize the use case, when I want to attach an event to a
child element or an element linked by any other mean to the element
having that class, I can't use
Lachlan Hunt wrote:
For example, using this CSS-like syntax (but it's not CSS).
selector {
event-name: function();
}
I just remembered BECSS, which is pretty much that exact thing. Strange
how didn't occur to me at all, though it must have been buried in my
subconscious somewhere :-).
On 9/5/05, Lachlan Hunt [EMAIL PROTECTED] wrote:
Aankhen wrote:
I suggest #2, which implies consistently treating the first argument
passed to the function as a single class name to match (this means
foo bar would always return no elements,
No, as already demonstrated, #2 does return
Jim Ley wrote:
On 9/5/05, Lachlan Hunt [EMAIL PROTECTED] wrote:
No, as already demonstrated, #2 does return matches in some cases.
Surely that's just an implementation bug? rather than indicative of
any underlying problem in the spec.
Yes, it was a bug, but I didn't think the spec was
Jim Ley wrote:
On 9/5/05, Lachlan Hunt [EMAIL PROTECTED] wrote:
I may not be understanding what you mean, but if optional parameters
aren't language independant, shouldn't it be defined in a more language
independant way, so that any non-ECMAScript languages can still
implement this?
Yes, DOM
I think variable number of arguments for that function may be cause of
many problems.
As far as I'm aware W3C DOM never uses functions with variable number of
arguments, so design of getElementsByClassName() stands out.
Functions with variable number of arguments are problematic in some
Anne van Kesteren wrote:
Quoting Kornel Lesinski [EMAIL PROTECTED]:
It will also solve IMHO unclear case of getElementsByClassName(foo
bar) matching bar foo. It would, as opposed to behavior where
space is both separator and part of class name.
This is not how the CLASS attribute works.
On 9/5/05, Lachlan Hunt [EMAIL PROTECTED] wrote:
1. Equivalent to (foo, bar) (or [class~=foo][class~=bar], or
.foo.bar in CSS)
2. The way it currently works. ie. matches foo bar, not bar foo
3. Error, return nothing.
I suggest #2, which implies consistently treating the first argument
80 matches
Mail list logo
