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