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, DO
On 9/5/05, Lachlan Hunt <[EMAIL PROTECTED]> wrote:
> Jim Ley wrote:
> > className = className.match(/^\s*(\S+)\s*$/) ?
> > className.replace(/^\s*(\S+)\s*$/,"$1") : "";
>
> That seems to work well.
Good, Good.
> > mainly because a DOM binding with optional parameters
> > isn't language independa
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 ve
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 doe
Aankhen wrote:
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 treatin
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
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 wor
Kornel Lesinski wrote:
That's why I propose to make this function use exactly the syntax that
class attribute uses.
getElementsByClassName("bar foo") should match class="foo bar",
class="bar baz foo", etc.
For multiple classes it makes more sense to use:
el.getElementsBySelector(".foo.bar")
On Sun, 04 Sep 2005 17:51:43 +0100, Anne van Kesteren
<[EMAIL PROTECTED]> wrote:
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
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. "foo bar" means the ele
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
p
Hi,
I have a partial implementation of getElementsByClassName() [1] that
is designed to support HTML, XHTML, MathML and SVG documents (including
mixed namespace documents). It also includes Element.hasClassName(),
Element.addClassName() and Element.removeClassName(), which I think
should al
12 matches
Mail list logo
