Re: [whatwg] Re: getElementsByClassName
On Tue, 06 Sep 2005 00:54:56 +0100, Ian Hickson [EMAIL PROTECTED] wrote:
I fear that if we use a string that must be parsed, we will encourage
buggy implementations.
Not at all. Actually this should improve implementations, because same
parsing algorithm is used for both input string and class attribute.
Unfortunately in practice the two parts of that code are likely to be
completely unrelated parts of the codebase, so that reuse is unlikely.
Even if it isn't reused, such function is not a rocket science. Can't you
trust implementors to trim and split string properly?
For example I may want first to find set of classes I'd like to match
against. With solution I propose it's easy and intuitive to anyone who
used .className:
if (x) find += class1;
if (y) find += class2;
getElementsByClassName(find);
but with varargs function it's really cumbersome:
if (x) find.push(class1);
if (y) find.push(class2);
switch(find.length)
{
case 1: getElementsByClassName(find[0]); break;
case 2: getElementsByClassName(find[0],find[1]); break;
...
}
You can just do:
if (x) find.push(class1);
if (y) find.push(class2);
document.getElementsByClassName.apply(document, find);
...which seems much better to me than using a string.
It's the first time I see apply method used. I couldn't find it in
ECMA262-3 nor in WA1.0. Can you give me a hint where it's defined?
Why is that better than using string?
--
regards, Kornel Lesinski
Re: [whatwg] Re: getElementsByClassName
Kornel Lesinski wrote: On Tue, 06 Sep 2005 00:54:56 +0100, Ian Hickson [EMAIL PROTECTED] wrote: You can just do: if (x) find.push(class1); if (y) find.push(class2); document.getElementsByClassName.apply(document, find); ...which seems much better to me than using a string. It's the first time I see apply method used. I couldn't find it in ECMA262-3 nor in WA1.0. Can you give me a hint where it's defined? Why is that better than using string? It's a method of Function(). http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Reference:Objects:Function:apply -- Lachlan Hunt http://lachy.id.au/
[whatwg] Re: getElementsByClassName
On 9/5/05, Ian Hickson [EMAIL PROTECTED] wrote: If multiple class names really need to be handled, my suggestion would be to take a single array as a parameter, e.g. `getElementsByClassName([foo])` and `getElementsByClassName([foo, bar])`. What is the problem with allowing multiple arguments in JS? One of the earlier messages said something which I basically interpreted as variable arguments = bad, so I suggested an alternative. If it were up to me, I'd just use them. :-) Aankhen
Re: [whatwg] Re: getElementsByClassName
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/
Re: [whatwg] Re: getElementsByClassName
Ian Hickson wrote: On Tue, 6 Sep 2005, Dean Edwards wrote: That's right. We are defining HTML5 and the DOM extensions to support it. If other languages want to add different class name delimiters, let them. My hunch is that they will follow suit. This is a good opportunity to make it clear. HTML has always led the way. It also ensures backward-compatibility. Well, it's clear that HTML classes can't contain spaces... I'm not really sure what you're asking for here. :-) Sorry. It seemed that previous emails were suggesting there could be other delimiters. My mistake. ;-) -dean
Re: [whatwg] Re: getElementsByClassName
Ian Hickson wrote: On Tue, 6 Sep 2005, Lachlan Hunt wrote: http://whatwg.org/specs/web-apps/current-work/#domtokenstring 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. Let me know how that goes. That interface hasn't really been looked at much yet. I've thought about it some more, and it may be difficult to do with the way the add() and remove() are currently defined with no return value. I assume that means you're intending for these functions to modify the string itself. However, in JavaScript a String() is immutable and all other methods that do modifications actually return a new string, not modify itself. Then, there's also the question of assuming the token delimiter will always be a space. Will there need to be a way to specify what the delimiter is, or is that intended to be dependant upon the language? For example, in HTML .className would return a DOMTokenString delimited by spaces, but in FooBarML it may be semi-colons, commas, or anything else. 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? Well, it's highly theoretical. It seems such a note might be more confusing than helpful. What do you think? I think fixing the grammar of this paragraph and adding one more sentence won't be too confusing Current text: | The space character (U+0020) is not special in the method's arguments. | In HTML, XHTML, SVG and MathML it is impossible for an element to | belong to a class whose name contains a space character, however, and | so typically the method would return no nodes if one of its arguments | contained a space. Suggested text: The space character (U+0020) is not special in the method's arguments. In HTML, XHTML, SVG and MathML it is impossible for an element to belong to a class whose name contains a space character and thus, for these languages, the method would return no nodes if one of its arguments contained a space. This does not, however, prevent other languages from allowing spaces in class names. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] Re: getElementsByClassName
--- Dean Edwards [EMAIL PROTECTED] wrote: Ian Hickson wrote: On Tue, 6 Sep 2005, Dean Edwards wrote: It would be better to define that class names should not contain white space. Well, we can't really control that, I mean, other languages can invent whatever they want (and frequently do). I thought we were controlling that. Isn't that what we are doing? We're defining what class means for HTML(5), and what the behaviour of getElemetsByClassName() in the DOM should be. But if someone invents FooBarML that has classes with spaces in it, CSS will match them (for example, .a\ b), and I don't see why getElementsByClassName should not be capable of matching them given that it falls simply out of the current definition. However, this is all highly theoretical. That's right. We are defining HTML5 and the DOM extensions to support it. If other languages want to add different class name delimiters, let them. My hunch is that they will follow suit. This is a good opportunity to make it clear. HTML has always led the way. It also ensures backward-compatibility. Exactly; what exactly would some theoretical language gain by allowing spaces in class values? Might as well keep it simple and not allow them, following current practice. Brad -dean
