W3C home > Mailing lists > Public > whatwg@whatwg.org > September 2005

[whatwg] getElementsByClassName()

From: Jim Ley <jim.ley@gmail.com>
Date: Mon, 5 Sep 2005 10:04:21 +0100
Message-ID: <851c8d3105090502047a44280f@mail.gmail.com>
On 9/5/05, Lachlan Hunt <lachlan.hunt at lachy.id.au> 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 matches in some cases.

Surely that's just an implementation bug?   rather than indicative of
any underlying problem in the spec.

The ElementClassName file :
className = className.replace(/^\s*([^\s]*)\s*$/, "$1")
doesn't enforce the classnames have no spaces in them and results it
in continuing to test the className attributes with a regexp
containing the space.

a quick untested fix would I think be:

className = className.match(/^\s*(\S+)\s*$/) ?
className.replace(/^\s*(\S+)\s*$/,"$1") : "";

(also using \S rather than [^\s], but that's purely style of course)

> > Special-casing "foo bar" and other values seems to be adding
> > complexity without much return.
> It's not about special casing, it's about defining error recovery
> consistently between implementations.  As it's currently defined, ("foo
> bar" is, I believe, erroneous since each parameter represents a single
> class name.  

I think it is defined in the spec, it's erroneous, and your
implementation is just broken as above, I'd quite like it to be
defined as 3, mainly because a DOM binding with optional parameters
isn't language independant, and if it's a ECMAScript tied DOM, then
the DOM needs to be a lot more ECMAScript like.

Received on Monday, 5 September 2005 02:04:21 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:24 UTC