[whatwg] Re: getElementsByClassName

[Lachlan Hunt]

Ian Hickson wrote:
> On Sun, 4 Sep 2005, Lachlan Hunt wrote:
>>It also includes Element.hasClassName(), Element.addClassName() and 
>>Element.removeClassName(), which I think should also be added to WA1.
> 
> I envisage somehow making className implement the DOMTokenString 
> interface:
> 
>    http://whatwg.org/specs/web-apps/current-work/#domtokenstring
> 
> ...so that you would have Element.className.add(), 
> Element.className.has(), etc.

Cool, I'll see what I can do about implementing that.  I think I may be 
able to extend the String() object quite easily for that, though I'll 
have to think about it a little more.

>>What should each of these function calls return?  I've listed the ones that my
>>script currently selects.  Are any of them incorrect?
>>
>>04. getElementsByClassName(" foo");       | A, B, C, D, E, F, G
>>05. getElementsByClassName("foo ");       | A, B, C, D, E, F, G
>>06. getElementsByClassName(" foo ");      | A, B, C, D, E, F, G
>>07. getElementsByClassName("foo bar");    | E, F
> 
> Incorrect; none of the above elements are in classes that have a space 
> character in the class name.

Fixed.  All of those now return none, the other results are unchanged.

>>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.
> 
> What if an element is in the class "foo bar"?

So, you're saying that it's possible that some hypothetical langauge may 
define a class attribute with any character as the delimiter, not just 
white space?  So, for example, a language could use semi-colons like 
this: foo:class="foo bar;baz" and thus, for that language, gEBCN("foo 
bar") would match that?  In which case, would it be worth adding a note 
to the spec stating that implementations should not assume that all 
languages will use white space delimiters between class names?

> On Mon, 5 Sep 2005, Lachlan Hunt wrote:
> 
>>The problem is that white space handling in parameter values isn't 
>>currently defined at all...
> 
> The spec now defines this better. Basically, "foo bar" would never match 
> anything in HTML, XHTML, MathML or SVG.

Thanks, that's much better.

>>At the moment I trim any leading and trailing spaces...
> 
> The spec doesn't mention trimming, so, no trimming. :-)

Ok, trimming removed.

-- 
Lachlan Hunt
http://lachy.id.au/