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

[whatwg] getElementsByClassName()

From: Lachlan Hunt <lachlan.hunt@lachy.id.au>
Date: Mon, 05 Sep 2005 19:52:25 +1000
Message-ID: <431C1559.20304@lachy.id.au>
Jim Ley wrote:
> On 9/5/05, Lachlan Hunt <lachlan.hunt at lachy.id.au> 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 very clear on how to 
handle the issue.

> 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") : "";

That seems to work well.

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

Thanks, I didn't know about that syntax.

> 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,

Yes, I guess, if it is erroneous, then #3 does make the most sense.

> 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.

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?

-- 
Lachlan Hunt
http://lachy.id.au/
Received on Monday, 5 September 2005 02:52:25 UTC

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