Re: [whatwg] getElementsByClassName case sensitivity
Anne van Kesteren ann...@opera.com wrote: On Tue, 13 Jan 2009 11:17:08 +0100, Anne van Kesteren ann...@opera.com wrote: Since my initial e-mail did not seem to have done it, could you please take a look at the source code of the respective test and tell me if you see a problem there? http://tc.labs.opera.com/apis/getElementsByClassName/014.htm To be perfectly clear, there is no discrepancy between CSS handling and the getElementsByClassName method and the test is testing that there is not. Wow, epic fail. I missed it should match two elements. The test is indeed out of date. * updates the test now. Excellent - thanks! -- Stewart Brodie Software Engineer ANT Software Limited
Re: [whatwg] getElementsByClassName case sensitivity
Anne van Kesteren ann...@opera.com wrote: On Mon, 12 Jan 2009 15:25:33 +0100, Stewart Brodie stewart.bro...@antplc.com wrote: Ian Hickson i...@hixie.ch wrote (on 25 July 2008): I've made [getElementsByClassName] consistent with how classes work in CSS (case-insensitive for quirks and case-sensitive otherwise). I was looking for some tests for this API and found some from Opera (found at http://tc.labs.opera.com/apis/getElementsByClassName/) but given the dates on them predate the latest spec changes (which causes some to fail now), I was wondering if up to date versions are now kept somewhere else instead? The tests already take this change into account. It was agreed upon way earlier prolly over IRC or so, but the specification hadn't catched up with reality yet. I'm not sure what other tests you might believe to be out of date (and why) and would be interested in knowing being the author and all :-) Specifically: test 14 - tests for case-sensitivity in a document that is in quirks mode. Are you saying that this change has now been reversed and the comparisons are always case-sensitive, thus reintroducing the discrepancy between CSS's handling of classes and this new method? -- Stewart Brodie Software Engineer ANT Software Limited
Re: [whatwg] getElementsByClassName case sensitivity
On Tue, 13 Jan 2009 11:08:56 +0100, Stewart Brodie stewart.bro...@antplc.com wrote: Specifically: test 14 - tests for case-sensitivity in a document that is in quirks mode. Are you saying that this change has now been reversed and the comparisons are always case-sensitive, thus reintroducing the discrepancy between CSS's handling of classes and this new method? Since my initial e-mail did not seem to have done it, could you please take a look at the source code of the respective test and tell me if you see a problem there? http://tc.labs.opera.com/apis/getElementsByClassName/014.htm To be perfectly clear, there is no discrepancy between CSS handling and the getElementsByClassName method and the test is testing that there is not. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] getElementsByClassName case sensitivity
On Tue, 13 Jan 2009 11:17:08 +0100, Anne van Kesteren ann...@opera.com wrote: Since my initial e-mail did not seem to have done it, could you please take a look at the source code of the respective test and tell me if you see a problem there? http://tc.labs.opera.com/apis/getElementsByClassName/014.htm To be perfectly clear, there is no discrepancy between CSS handling and the getElementsByClassName method and the test is testing that there is not. Wow, epic fail. I missed it should match two elements. The test is indeed out of date. * updates the test now. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] getElementsByClassName case sensitivity
Ian Hickson i...@hixie.ch wrote (on 25 July 2008): I've made [getElementsByClassName] consistent with how classes work in CSS (case-insensitive for quirks and case-sensitive otherwise). I was looking for some tests for this API and found some from Opera (found at http://tc.labs.opera.com/apis/getElementsByClassName/) but given the dates on them predate the latest spec changes (which causes some to fail now), I was wondering if up to date versions are now kept somewhere else instead? -- Stewart Brodie Software Engineer ANT Software Limited
Re: [whatwg] getElementsByClassName() feedback
On Thu, 27 Nov 2008 22:38:32 +0100, Garrett Smith [EMAIL PROTECTED] wrote: It is often desirable to capture events on bubble and interrogate the EventTarget using a hasClassName function to see if it has a className that the program is concerned with. [...] HTML5 already has the functionality you request in form of the classList DOM attribute on HTML elements. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
[whatwg] getElementsByClassName() feedback
On Sat, 14 Jan 2006, Karoly Negyesi wrote: A getElementsByCSSSelector IMO would be great and introduces minimal plus burden on browsers -- they have CSS selector code anyways. It's very unfriendly that I can do magic with CSS2/3 selectors and then I need to translate them myself if I want to change them on-the-fly. You may find this specification to be of interest: http://dev.w3.org/cvsweb/~checkout~/2006/webapi/selectors-api/Overview.html?content-type=text/html;%20charset=utf-8 On Tue, 24 Oct 2006, Dean Edwards wrote: Personally, I prefer a comma delimited list. Passing an array seems yukky. Really? I always thought the comma-separated argument to window.open() was one of the ugliest APIs ever... This isn't the same thing. We are faking varargs so whatever we do is going to look a bit ugly. Nine times out of ten this method will be called with one argument: var menus = document.getElementsByClassName(menu); That is much more intuitive for the most common case. True. On Tue, 24 Oct 2006, Gervase Markham wrote: Why not allow a string in the single class name case, but require an array for multiple class names? Alternatively, we could make it more obvious that it takes an array by calling it document.getElementsByClassNames([..., ...]); This gives a little hint, and is a more accurate description of what the function does. Also true... On Sun, 5 Nov 2006, Anne van Kesteren wrote: I think this hasn't been suggested before. Perhaps the method should accept a DOMTokenString as argument instead of an array. This allows things like ele.getElementsByClassName(ele.className) etc. The only problem is how to get a DOMTokenString without first getting .className from somewhere. Perhaps it should be a constructor as well. 'x = new DOMTokenString(aaa bbb)' We could, though that's far more awkward. * The examples use a mix of accepting arrays and strings. This should be fixed I assume. Fixed. * In HTML, XHTML, SVG and MathML elements you can drop XHTML as it's clearly defined in the specification what HTML elements means. Ok. On Sun, 5 Nov 2006, Anne van Kesteren wrote: Hixie, the title attribute of the remove(token) definition says dom-tokenstring-add rather than dom-tokenstring-remove... Fixed. On Fri, 2 Feb 2007, Robert Sayre wrote: I landed support for this on the Mozilla trunk, and it will appear in upcoming Firefox alphas and betas. The array argument turned out to be quite a pain to implement, so we cut it. If other implementors feel it's worth it, we can put that support back in. Ok. I've changed the spec to use a space-separated list. On Sat, 7 Jul 2007, Lachlan Hunt wrote: It could be defined to accept either a space separated string or an array. Using the [Overloads] extended attributed defined in the Language Bindings for DOM Specifications draft [1], it could be defined like this: NodeList getElementsByClassName(in DOMString classNames); [Overloads=getElementsByClassName] NodeList getElementsByClassNameArray(in DOMString[] classNames); For ECMAScript, that effectively means that getElementsByClassName() can be called with either a space separated string of class names or an array. I've dropped the array form altogether. On Mon, 9 Jul 2007, Jonas Sicking wrote: I agree with Simon here. Allowing arrays to be passed in doesn't add any extra value and complicates the implementation significantly. I think that the by far most common case is going to be passing a single class name, so adding multiple ways of passing multiple class names seems like overkill. Agreed. On Tue, 10 Jul 2007, Dan Dorman wrote: Granted, the most common case will indeed be asking for a single class name. But, if we're going to the trouble of accepting multiple class names, it seems shortsighted to restrict the parameter for the multi-class case to a space-separated string, which is really just a kludgey way of representing a list (or array). Agreed as well, but implementation feedback seems to be that accepting an array is more expensive than it's worth. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] getElementsByClassName
On Tue, 6 Sep 2005, Lachlan Hunt wrote: [DOMTokenString] 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. I've changed the approach to address this. (Thanks to you and Maciej and others.) 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. I think unless we have an actual use case we can leave the implied space separator as is. It can always be extended later. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] getElementsByClassName
On 7/9/07, Jonas Sicking [EMAIL PROTECTED] wrote: I agree with Simon here. Allowing arrays to be passed in doesn't add any extra value and complicates the implementation significantly. I think that the by far most common case is going to be passing a single class name, so adding multiple ways of passing multiple class names seems like overkill. Granted, the most common case will indeed be asking for a single class name. But, if we're going to the trouble of accepting multiple class names, it seems shortsighted to restrict the parameter for the multi-class case to a space-separated string, which is really just a kludgey way of representing a list (or array). Dan
Re: [whatwg] getElementsByClassName
Lachlan Hunt wrote: Simon Pieters wrote: getElementsByClassName is defined to take an array of strings as argument. What exactly is an array? A native ECMAScript array, or anything with a 'length' property and the properties '0' - length-1? Is a DOMTokenList an array that can be passed to gEBCN? It could be defined to accept either a space separated string or an array. Using the [Overloads] extended attributed defined in the Language Bindings for DOM Specifications draft [1], it could be defined like this: NodeList getElementsByClassName(in DOMString classNames); [Overloads=getElementsByClassName] NodeList getElementsByClassNameArray(in DOMString[] classNames); For ECMAScript, that effectively means that getElementsByClassName() can be called with either a space separated string of class names or an array. [1] http://dev.w3.org/cvsweb/~checkout~/2006/webapi/Binding4DOM/Overview.html?content-type=text/html;%20charset=utf-8#Overloads I agree with Simon here. Allowing arrays to be passed in doesn't add any extra value and complicates the implementation significantly. I think that the by far most common case is going to be passing a single class name, so adding multiple ways of passing multiple class names seems like overkill. / Jonas
[whatwg] getElementsByClassName
getElementsByClassName is defined to take an array of strings as argument. What exactly is an array? A native ECMAScript array, or anything with a 'length' property and the properties '0' - length-1? Is a DOMTokenList an array that can be passed to gEBCN? Firefox has implemented it as a space separated string as argument. This seems more practical for the simple case and you can still pass an element's .className as argument (if DOMTokenList.toString is defined to return a string with the tokens being space separated, .classList can be passed as argument too). I don't think that the argument of being able to use classes containing spaces is relevant since no Web technology I know of can have classes containing spaces. I think that the argument of authors not understanding that the order doesn't matter applies equally much to CSS .foo.bar vs .bar.foo. For these reasons, I think the spec should use space separated string as argument instead of array (and perhaps define DOMTokenList.toString to be useful). Finally, an editorial comment, the example uses both string as argument and array as argument. This might be confusing unless both are accepted. -- Simon Pieters
Re: [whatwg] getElementsByClassName() idea
On Sun, 05 Nov 2006 10:55:05 +0100, Alexey Feldgendler [EMAIL PROTECTED] wrote: I think this hasn't been suggested before. Perhaps the method should accept a DOMTokenString as argument instead of an array. This allows things like ele.getElementsByClassName(ele.className) etc. The only problem is how to get a DOMTokenString without first getting .className from somewhere. Perhaps it should be a constructor as well. 'x = new DOMTokenString(aaa bbb)' How is it better than DOMString? It inherits from DOMString. http://www.whatwg.org/specs/web-apps/current-work/#domtokenstring defines it. Hixie, the title attribute of the remove(token) definition says dom-tokenstring-add rather than dom-tokenstring-remove... -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] getElementsByClassName() idea
Lachlan Hunt wrote: Anne van Kesteren wrote: This allows things like ele.getElementsByClassName(ele.className) etc. anything that accepts a DOMString will automatically accept a DOMTokenString, including getElementsByClassName. So your example will already work. It seems getElementsByClassName has been changed to accept an array, not a DOMString and I didn't realise. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] getElementsByClassName() idea
On Sun, 05 Nov 2006 16:18:32 +0600, Anne van Kesteren [EMAIL PROTECTED] wrote: I think this hasn't been suggested before. Perhaps the method should accept a DOMTokenString as argument instead of an array. This allows things like ele.getElementsByClassName(ele.className) etc. The only problem is how to get a DOMTokenString without first getting .className from somewhere. Perhaps it should be a constructor as well. 'x = new DOMTokenString(aaa bbb)' How is it better than DOMString? It inherits from DOMString. http://www.whatwg.org/specs/web-apps/current-work/#domtokenstring defines it. I still don't get it what's the advantage of having getElementsByClassName take a DOMTokenString argument over a plain DOMString. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] getElementsByClassName() idea
On Sun, 05 Nov 2006 14:27:14 +0100, Alexey Feldgendler [EMAIL PROTECTED] wrote: I still don't get it what's the advantage of having getElementsByClassName take a DOMTokenString argument over a plain DOMString. Oh right, sorry. Yeah, I suppose a DOMString makes more sense. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] getElementsByClassName()
Dean Edwards wrote: The point is that there is room for all of these methods for retrieving DOM nodes. As there is no useful existing standard let's add stuff that people actually want instead of referring them to vapour ware. I guess the question is why bother with getElementByClassName if a full getElementByCSSSelector-type method is available?. Possible answers would include speed and ease of use but I'm not sure either applies here. -- Eternity's a terrible thought. I mean, where's it all going to end? -- Tom Stoppard, Rosencrantz and Guildenstern are Dead
Re: [whatwg] getElementsByClassName()
There seems to be a question on how confusing a method would be for developers. I went and asked 4 people I know that are just learning Javascript for the first time. For two of them javascript is their first programing language, the other two already know other languages. Given this markup: p class=foo barPara 1/p p class=bar fooPara 2/p p class=foo bazPara 3/p All expected that getElementsByClassName(foo bar); would match foo bar exactly in the class name and only return Para 1. When asked if they would prefer a comma separated list or an array, there were mixed feelings. Three indicated a preference to a comma separated list, the other said he would expect to pass an array. Given this I would suggest not using a space delimited list. _ Jonathan Worent _ Webmaster __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: [whatwg] getElementsByClassName()
Ian Hickson wrote: On Mon, 23 Oct 2006, Jonathan Worent wrote: When asked if they would prefer a comma separated list or an array, there were mixed feelings. Three indicated a preference to a comma separated list, the other said he would expect to pass an array. Given this I would suggest not using a space delimited list. Ok, that's a compelling argument. I've removed the string version. We're down to just the array form now. If people want to call the method with a single class, they have to use square brackets; if they want to call it with a space-separated list of classes, they have to use .split() or some such. Personally, I prefer a comma delimited list. Passing an array seems yukky. Are there any problems with passing a JavaScript array to a DOM method? Does it cast to a DOMArray or something? What about other platforms? -dean
Re: [whatwg] getElementsByClassName()
Na , Ian Hickson [EMAIL PROTECTED] escreveu: On Mon, 23 Oct 2006, Dean Edwards wrote: Personally, I prefer a comma delimited list. Passing an array seems yukky. Really? I always thought the comma-separated argument to window.open() was one of the ugliest APIs ever... Are there any problems with passing a JavaScript array to a DOM method? Does it cast to a DOMArray or something? What about other platforms? It's an array. Most languages support arrays. Why would there be a problem? The question is.. is there really the need for the array ? Most bindings support variable arguments.
Re: [whatwg] getElementsByClassName()
Na , Ian Hickson [EMAIL PROTECTED] escreveu: On Tue, 24 Oct 2006, Joao Eiras wrote: The question is.. is there really the need for the array ? Most bindings support variable arguments. The initial proposal used varargs, but people pointed out that that made it difficult to call the method with an arbitrary number of arguments, which is why it now takes an array. Ok then, but there could be that option for both Java's and ecmascript's bindings. Instantiating an array adds bloat to the code and inefficiency. So this would be something to keep.
Re: [whatwg] getElementsByClassName()
On Tue, 24 Oct 2006, Joao Eiras wrote: Na , Ian Hickson [EMAIL PROTECTED] escreveu: On Tue, 24 Oct 2006, Joao Eiras wrote: The question is.. is there really the need for the array ? Most bindings support variable arguments. The initial proposal used varargs, but people pointed out that that made it difficult to call the method with an arbitrary number of arguments, which is why it now takes an array. Ok then, but there could be that option for both Java's and ecmascript's bindings. I agree that varargs seems like a good idea, but you and I seem to be the only ones who think that. :-( As far as Java goes, I don't really have an opinion. For areas where interoperability isn't important, people implementing the APIs can take whatever liberties they want. Instantiating an array adds bloat to the code and inefficiency. So this would be something to keep. I really don't think that instantiating an array is something that's even remotely going to appear on the radar when you compare it to the rest of what the method is doing (crawling the entire DOM and creating a live NodeList that tracks DOM changes). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] getElementsByClassName()
Ian Hickson wrote: On Mon, 23 Oct 2006, Dean Edwards wrote: Personally, I prefer a comma delimited list. Passing an array seems yukky. Really? I always thought the comma-separated argument to window.open() was one of the ugliest APIs ever... This isn't the same thing. We are faking varargs so whatever we do is going to look a bit ugly. Nine times out of ten this method will be called with one argument: var menus = document.getElementsByClassName(menu); That is much more intuitive for the most common case. Are there any problems with passing a JavaScript array to a DOM method? Does it cast to a DOMArray or something? What about other platforms? It's an array. Most languages support arrays. Why would there be a problem? Just checking. ;-) -dean
Re: [whatwg] getElementsByClassName()
On Tue, 24 Oct 2006 06:17:20 +0700, Joao Eiras [EMAIL PROTECTED] wrote: It's an array. Most languages support arrays. Why would there be a problem? The question is.. is there really the need for the array ? Most bindings support variable arguments. Array: getElementsByClassName([c1, c2]); Varargs: getElementsByClassName(c1, c2); In the first case, there are just two more characters, but this method has two advantages that can't be ignored: 1. All languages have arrays, but not all languages support varargs. 2. It's easy to call the array version with an array that's constructed dynamically, without knowing the number of items in advance. Not all languages even with varargs support allow you to call a varargs function like that. -- Alexey Feldgendler [EMAIL PROTECTED] [ICQ: 115226275] http://feldgendler.livejournal.com
Re: [whatwg] getElementsByClassName()
On Sat, 21 Oct 2006 09:36:37 +0200, Ian Hickson [EMAIL PROTECTED] wrote: This omnibus edition of your WHATWG mail includes replies to 50 or so separate e-mails about getElementsByClassName(). Thanks to everyone for their comment on this issue. So what's the use case over matchAll(.foo.bar.baz) ..? -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] getElementsByClassName()
On Sun, 22 Oct 2006 20:03:48 +0200, Dean Edwards [EMAIL PROTECTED] wrote: So what's the use case over matchAll(.foo.bar.baz) ..? I didn't know that this had been implemented. Which browser is supporting it? It's not supported yet. What makes you think it is? -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] getElementsByClassName()
Anne van Kesteren wrote: On Sun, 22 Oct 2006 20:03:48 +0200, Dean Edwards [EMAIL PROTECTED] wrote: So what's the use case over matchAll(.foo.bar.baz) ..? I didn't know that this had been implemented. Which browser is supporting it? It's not supported yet. What makes you think it is? You asked for a comparison with an unimplemented standard. We could be here all day doing that. What's the use case of matchAll over XPath? -dean
Re: [whatwg] getElementsByClassName()
On Sun, 22 Oct 2006 20:16:06 +0200, Dean Edwards [EMAIL PROTECTED] wrote: So what's the use case over matchAll(.foo.bar.baz) ..? I didn't know that this had been implemented. Which browser is supporting it? It's not supported yet. What makes you think it is? You asked for a comparison with an unimplemented standard. We could be here all day doing that. Neither getElementsByClassName nor matchAll have implementations (though both have scripted implementations). I don't really see your point. Regarding XPath, Selectors allows you to select several things that XPath would only allow you to do through extensions, such as selecting all valid form controls and it's also considered to be faster (because you can only go down in the tree) as well as easier to use for authors given that it's widely used in CSS already. -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] getElementsByClassName()
This omnibus edition of your WHATWG mail includes replies to 50 or so
separate e-mails about getElementsByClassName(). Thanks to everyone for
their comment on this issue.
On Mon, 5 Sep 2005, Brad Neuberg 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.
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.
Well, as you later point out, we don't want to lock ourselves in. But I
agree that it is important to consider the common case first.
On Tue, 6 Sep 2005, Kornel Lesinski wrote:
Even if it isn't reused, such function is not a rocket science. Can't
you trust implementors to trim and split string properly?
Yeah, you're probably right.
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?
ECMA262 Edition 3 section 15.3.4.3.
Why is that better than using string?
It probably isn't. It seems, though, that one option (suggested by Brad
below) is to accept a string or an array, thus:
if (x) find.push(class1);
if (y) find.push(class2);
document.getElementsByClassName(find);
This would probably be easier to read.
On Mon, 7 Nov 2005, ROBO Design wrote:
I opt for using just one argument with multiple class names separated
with a space.
I wouldn't like having multiple arguments, because when authors need to
get a list of elements based on multiple class names, and the number of
classes is not known by the author before writing the script, s/he's
required to use eval(). This sucks IMHO :).
Fair point.
b) Idea: getElementsByClassName() could accept multiple argument, each
argument being a class name. The only difference from the current
definition of the spec: if any argument contains space characters, split
the string into an array and consider them as multiple class names.
getElementsByClassName(we all like dogs) =
getElementsByClassName(we, all, like, dogs) =
getElementsByClassName(we all, like dogs)
In this way you satisfy everybody.
True. It seems slightly better (since then you can easily pass an array)
to make the function accept a string or an array.
We could also have a getElementBySelector() method, but it seems that
it would be best to let the CSSWG define that.
The specification already defined getElementsByClassName(). So, why not
getElementsBySelector() too? Or this can be better handled via XPath
expressions?
Now covered by the following W3C spec:
http://dev.w3.org/cvsweb/~checkout~/2006/webapi/selectors-api/Overview.html?content-type=text/html;%20charset=utf-8
On Thu, 2 Feb 2006, Brad Fults wrote:
I suggest either going with the space-delimited approach (as it's
language-agnostic and well-defined at least) or with Aankhen's
suggestion of a single array argument.
I think the latter is better and more intuitive in design, however. The
function should take a single argument at all times.
If the argument is a string, that string is used as a single class
name and matched against the elements in the document.
Else if the argument is an array, each element of the array is taken
as a string and will be treated as a class name.
The elements which have all of the class names existing in the array
will match and be returned in the NodeList.
That seems reasonable, although I could see someone wanting to just pass
an element's class attribute value to the method directly, and have it
work even if the attribute has multiple class names in it.
On Fri, 3 Feb 2006, Gervase Markham wrote:
If you have:
p class=foo barFred/p
p class=bar fooBarney/p
p class=foo baz barWilma/p
which should be picked up by getElementsByClassName(foo bar)?
In the string split mode, it would pick up all three. However, I
suggest that designers might be misled by this interface into thinking
that it only picks up the
Re: [whatwg] getElementsByClassName()
Shadow2531 wrote: I was *messing* around with 2 different *examples*. 1.) http://shadow2531.com/opera/js/getElementsByClassName/000.html That one supports: getElementsByClassName(string); getElementsByClassName(array); If the string has spaces in it, it's considered that nothing will match and returns null. If it's an array, all must be present for an element to match. 2.) http://shadow2531.com/opera/js/getElementsByClassName/001.html Now this one supports the same 2 types, but the string handling is different. The string is space-separated. So, with this second example, you can do: document.getElementsByClassName(aaa); document.getElementsByClassName([bbb, ccc]); document.getElementsByClassName(bbb ccc); (The second 2 produce the same result. The 3rd one might just be cleaner in certain situations) I'm liking what options the second example provides. (not necessarily the code as I just threw it together and didn't think about exceptions, optimization and code size. Plus I just used a global function for the example.) Do you agree with the string being space-separated? It seems to make sense at least for html where a classname can't have spaces. looks good to me, the only quirk of this would be that you cant choose class=foo bar specifically over class=foo with gebcn(foo bar) but if this is the stated behaviour then i guess that's ok. on a side note, it might also be worth stating that in this case gebcn(foo bar) should only return the class=foo bar element once, not twice (one instance for foo and one instance for bar). just for completeness ric
Re: [whatwg] getElementsByClassName()
On 2/15/06, Ric Hardacre [EMAIL PROTECTED] wrote: Shadow2531 wrote: I was *messing* around with 2 different *examples*. 1.) http://shadow2531.com/opera/js/getElementsByClassName/000.html That one supports: getElementsByClassName(string); getElementsByClassName(array); If the string has spaces in it, it's considered that nothing will match and returns null. If it's an array, all must be present for an element to match. 2.) http://shadow2531.com/opera/js/getElementsByClassName/001.html Now this one supports the same 2 types, but the string handling is different. The string is space-separated. So, with this second example, you can do: document.getElementsByClassName(aaa); document.getElementsByClassName([bbb, ccc]); document.getElementsByClassName(bbb ccc); (The second 2 produce the same result. The 3rd one might just be cleaner in certain situations) I'm liking what options the second example provides. (not necessarily the code as I just threw it together and didn't think about exceptions, optimization and code size. Plus I just used a global function for the example.) Do you agree with the string being space-separated? It seems to make sense at least for html where a classname can't have spaces. looks good to me, the only quirk of this would be that you cant choose class=foo bar specifically over class=foo with gebcn(foo bar) but if this is the stated behaviour then i guess that's ok. gebcn(foo bar) should match any element that has *both* foo and bar, but *not necessarily just* foo and bar. If the element doesn't have both foo and bar, the element doesn't match. Therefore, gebcn(foo bar) wouldn't match class=foo because bar is not present. None of the methods of searching in my examples will work as a getElementsByClassAttributeValue. I don't think gebcn is supposed to do that anyway. on a side note, it might also be worth stating that in this case gebcn(foo bar) should only return the class=foo bar element once, not twice (one instance for foo and one instance for bar). just for completeness Correct, each element should only be evaluated once and if just one class you search for in the element's class attribute is not present, the element does not match and it moves on to the next element. That was the idea at least., but maybe my examples don't fully do what I meant or were you just clarifying? :) -- Shadow2531
Re: [whatwg] getElementsByClassName()
On 2/3/06, Gervase Markham [EMAIL PROTECTED] wrote: Shadow2531 wrote: O.K. Then, it should be getElementByClassName*s*() where you have have 1 or more classname arguments. If you pass more than 1 class name, both class names have to be present in the classname attribute for the element to match. This seems like a sensible change. Call it getElementsByClassNames() would make it obvious that if you supply multiple class names, you get only elements with all those names. And it would be a reasonably obvious reduction that if you just supply a single name, you would get all elements which had that one class name. So we've ended up with: elem.getElementsByClassNames(foo); and elem.getElementsByClassNames([foo, bar]); or elem.getElementsByClassNames(foo, bar); or both. Are there similar functions in the DOM at the moment which can take multiple arguments? Do you pass an array or multiple individual arguments, or can you do both? Gerv I was *messing* around with 2 different *examples*. 1.) http://shadow2531.com/opera/js/getElementsByClassName/000.html That one supports: getElementsByClassName(string); getElementsByClassName(array); If the string has spaces in it, it's considered that nothing will match and returns null. If it's an array, all must be present for an element to match. 2.) http://shadow2531.com/opera/js/getElementsByClassName/001.html Now this one supports the same 2 types, but the string handling is different. The string is space-separated. So, with this second example, you can do: document.getElementsByClassName(aaa); document.getElementsByClassName([bbb, ccc]); document.getElementsByClassName(bbb ccc); (The second 2 produce the same result. The 3rd one might just be cleaner in certain situations) I'm liking what options the second example provides. (not necessarily the code as I just threw it together and didn't think about exceptions, optimization and code size. Plus I just used a global function for the example.) Do you agree with the string being space-separated? It seems to make sense at least for html where a classname can't have spaces. -- Shadow2531
Re: [whatwg] getElementsByClassName()
Dean Edwards wrote:
Jim Ley wrote:
That is not immediately apparent, and neither is it apparent that a
classname specific shortname is worthwhile when a CSSSelector one
would be more appropriate.You don't continually add methods,
methods are complexity, they need writing, they need testing etc. you
have to have a reason to add a method.
A good API should expose a meaningful interface to its consumer. If we
are allowed to define data according to a skew on its structure (HTML
className) then the interface to that data should reflect this.
The getElementsByClassName() method has already been compared to the
getElementsByTagName() and getElementById() methods. class is another
way to slice the data. It is a core part of HTML, the language we are
extending.
To me, getElementsByClassName() is a missing feature of the DOM to
support HTML4. I'd be happy if that were fixed in HTML5.
I think this is a very clear explanation of the reasons to include it,
it's not as if we're discussing GetElementsByOnMouseOver() here. But
let's throw out a use case off the top of my head:
i'm making a shopping cart and each product has a checkbox next to it,
to select it for deletion, there are also other checkboxes on the page,
one to agree to the terms, another to sign up for the mailing list,
another to sign up for advertisements from our business partners,
another one up at the top right by a search box for a search option and
finally the select all for deletion checkbox. when i click on the
latter i want to check all the individual checkboxes for each product.
as they're in the basket i'm specifically styling them class=prodchck.
so to check them all all i need to do is:
function checkall()
{
var a = document.getElementsByClassName(prodchck);
for( var i = 0 ; i a.length ; i++ )
a[i].checked = true;
}
Re: [whatwg] getElementsByClassName()
Hi, James Graham wrote: Lachlan Hunt wrote: James Graham wrote: Also I would be surprised if there weren't multiple implementations of getElementsByClassname floating around in javascript libraries. So you can't really call it unimplemented. While there are many JavaScript implementations (I even wrote one myself a few months ago), all the custom JS implementations count for exactly zero native implementations in UAs, which is what really counts. But it suggests that its not hard to implement, which was my (poorly made) point. It's not hard to implement in JavaScript, but there's no an effective way to do it. You have to get all the elements of the page, and then check each if it has a specific className. And if you want to do it in the right way, you have to split clssNames by spaces, and then check, if it meets with the specified className. Bye, Andras
Re: [whatwg] getElementsByClassName()
On 2/5/06, Ian Hickson [EMAIL PROTECTED] wrote: I can certainly see myself speccing a getElementsBySelector() API as part of Selectors 2. But either way, the spec for gEBS is simple; it returns the same type as getElementsByTagName(), it is accessible from Document and Element nodes and selects a subset of the descendants of that node, it takes a single argument (a string representing a selector), its first version doesn't support namespaces, and it raises an exception SYNTAX_ERR if the string can't be successfully parsed by the UA. If this is anywhere in the near future, I'm all for dropping getElementsByClassName() in favor of this broader solution. But if this is high in the sky and won't be seen for years to come, I'll take the former sooner. What will it take to kick start the process for getElementsBySelector()? I suppose a few browser implementations would be good fuel. -- Brad Fults NeatBox
Re: [whatwg] getElementsByClassName()
On Mon, 06 Feb 2006 17:14:18 +0200, Brad Fults [EMAIL PROTECTED] wrote: On 2/5/06, Ian Hickson [EMAIL PROTECTED] wrote: ... If this is anywhere in the near future, I'm all for dropping getElementsByClassName() in favor of this broader solution. But if this is high in the sky and won't be seen for years to come, I'll take the former sooner. Everybody, of course, would favour the broader solution. Yet, as you stated, if getElementsBySelector() won't come soon, then getElementsByClassName() would be a welcomed addition. What will it take to kick start the process for getElementsBySelector()? I suppose a few browser implementations would be good fuel. Yes, that would certainly be a good fuel, but it will take some time. -- http://www.robodesign.ro ROBO Design - We bring you the future
Re: [whatwg] getElementsByClassName()
On Mon, 6 Feb 2006, Brad Fults wrote: On 2/5/06, Ian Hickson [EMAIL PROTECTED] wrote: I can certainly see myself speccing a getElementsBySelector() API as part of Selectors 2. But either way, the spec for gEBS is simple; it returns the same type as getElementsByTagName(), it is accessible from Document and Element nodes and selects a subset of the descendants of that node, it takes a single argument (a string representing a selector), its first version doesn't support namespaces, and it raises an exception SYNTAX_ERR if the string can't be successfully parsed by the UA. [...] What will it take to kick start the process for getElementsBySelector()? I suppose a few browser implementations would be good fuel. If you can get two browsers to interoperably implement the spec above, and then provide test cases to show this, then it'll increase the pressure on the CSSWG to get on with writing a spec for it. If you can get the two implementations to happen in the next month or so, then I might even be able to slide it into the Selectors 1 specification (no guarentees, but if there are two implementations in makes it easier)... -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] getElementsByClassName()
Jim Ley wrote: That is not immediately apparent, and neither is it apparent that a classname specific shortname is worthwhile when a CSSSelector one would be more appropriate.You don't continually add methods, methods are complexity, they need writing, they need testing etc. you have to have a reason to add a method. A good API should expose a meaningful interface to its consumer. If we are allowed to define data according to a skew on its structure (HTML className) then the interface to that data should reflect this. The getElementsByClassName() method has already been compared to the getElementsByTagName() and getElementById() methods. class is another way to slice the data. It is a core part of HTML, the language we are extending. To me, getElementsByClassName() is a missing feature of the DOM to support HTML4. I'd be happy if that were fixed in HTML5. Re CSSSelector: There are many ways to skin a cat. ;-) -dean
Re: [whatwg] getElementsByClassName()
On 2/5/06, James Graham [EMAIL PROTECTED] wrote: Jim Ley wrote: So something with no implementation should be taken over something with an existing implementation, that's pretty odd. Surely you can see that's a insane argument given the relative complexity of implementing the _entire_xbl_spec_ vs. implementing a single DOM method. Of course, I wasn't actually making the argument. So the only reason to add a getElementByCSSSelector method is because we feel that either a) DOM3 XPath is too hard to implement and getElementsByCSSSelector is much easier or b) because the added authoring simplicity provided by using widely understood CSS selectors is worth the substantial increase in complexity that providing two methods to solve the same problem will bring. DOM 3 XPath is of course only defined for XML, whilst it's no trouble defining it for valid HTML, it's not currently, for this reason I would prefer just having a CSSSelector method and not bothering with an XPath one, defining XPath for HTML is a bit of a pain - indeed I'm not completely confident it's possible on an invalid HTML document until after the document has finished loading. I do however know that arguing we shouldn't implement feature x because more complex features y and z provide a superset of x's features is wrong if a cost benefit analysis shows that x is better value for complexity than y or z. Of course it should! but remember also the cost of not doing x is relevant, and the likelyhood of y or z being implemented anyway. There's little point in requiring feature x be implemented if feature y and z are being implemented anyway, that's just bloat. Jim.
Re: [whatwg] getElementsByClassName()
On 2/4/06, Lachlan Hunt [EMAIL PROTECTED] wrote: While there are many JavaScript implementations (I even wrote one myself a few months ago), all the custom JS implementations count for exactly zero native implementations in UAs, which is what really counts. I'm not sure what relevance that has; if you look at the major UAs out there, one (IE) is pretty much stagnant, and the rest don't implement a whole lot of new features unless those features are found in a W3C WHATWG spec. So UA implementations aren't currently a fertile ground for spotting new and useful things to put on a standards track. And really, after all these years of harping at browser developers to stick to the standards, are we now going to cut off innovation by saying we'll only look at new ideas if they've been implemented by browser developers without previous standardization? That seems like one heck of a big catch-22 to me, and looks like it'd leave a lot of good ideas out in the cold because they've only been implemented in JavaScript. -- May the forces of evil become confused on the way to your house. -- George Carlin
Re: [whatwg] getElementsByClassName()
On 2/5/06, James Graham [EMAIL PROTECTED] wrote: Jim Ley wrote: On 2/5/06, James Graham [EMAIL PROTECTED] wrote: DOM 3 XPath is of course only defined for XML, whilst it's no trouble defining it for valid HTML, it's not currently, for this reason I would prefer just having a CSSSelector method and not bothering with an XPath one, defining XPath for HTML is a bit of a pain - indeed I'm not completely confident it's possible on an invalid HTML document until after the document has finished loading. In practice it works fine in Mozilla for HTML which, given it's DOM functionality, isn't so surprising since both XML and HTML end up constructing a DOM. in practice isn't really good enough for a specification any more, it was when HTML 4.01 or DOM 1 or DOM 2 or CSS 1 or CSS 2 came out, it is no longer, and specifications are actually getting proper reviews now. I think it would be better to just leave XPath in HTML unspecified - wish individuals and UA's luck if they want to try to use it on HTML, but don't try and help them too much. Jim.
Re: [whatwg] getElementsByClassName()
Jim Ley wrote: On 2/5/06, James Graham [EMAIL PROTECTED] wrote: Jim Ley wrote: On 2/5/06, James Graham [EMAIL PROTECTED] wrote: DOM 3 XPath is of course only defined for XML, whilst it's no trouble defining it for valid HTML, it's not currently, for this reason I would prefer just having a CSSSelector method and not bothering with an XPath one, defining XPath for HTML is a bit of a pain - indeed I'm not completely confident it's possible on an invalid HTML document until after the document has finished loading. In practice it works fine in Mozilla for HTML which, given it's DOM functionality, isn't so surprising since both XML and HTML end up constructing a DOM. in practice isn't really good enough for a specification any more, it was when HTML 4.01 or DOM 1 or DOM 2 or CSS 1 or CSS 2 came out, it is no longer, and specifications are actually getting proper reviews now. If it really is unspecified in HTML (even though a DOM is constructed) a reasonable specification could be derived from the Mozilla behavior. That is approximately the path that has been taken with canvas (Safari), XMLHttpRequest (IE), HTML parsing (Mozilla, Safari, Opera) and so on. Indeed firming up the specification of useful, implemented, behaviors is one of the aims of the WHATWG.
Re: [whatwg] getElementsByClassName()
On Sun, 5 Feb 2006, Lachlan Hunt wrote: Ian has already indicated that the specification of a method to collect DOM elements based on a CSS selector is best left to the CSS WG. I'd like to know why this is the case. Defining a DOM method seems like it would be out of scope for the CSS working group and seems to be in the scope of the WHATWG. Other than that, it could be left up the the DOM WG or possibly the Web API WG although it doesn't quite fit anything anything mentioned in their charter. Probably doesn't matter which group does it since it'd end up being me doing the work either way... At the time where I made that comment, the CSSWG was planning on creating a CSSOM spec to replace the DOM2 CSS spec. That plan still vaguely exists, though it isn't a high priority for the CSS group. I can certainly see myself speccing a getElementsBySelector() API as part of Selectors 2. But either way, the spec for gEBS is simple; it returns the same type as getElementsByTagName(), it is accessible from Document and Element nodes and selects a subset of the descendants of that node, it takes a single argument (a string representing a selector), its first version doesn't support namespaces, and it raises an exception SYNTAX_ERR if the string can't be successfully parsed by the UA. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] getElementsByClassName()
On 2/5/06, Ian Hickson [EMAIL PROTECTED] wrote: On Sun, 5 Feb 2006, Lachlan Hunt wrote: Probably doesn't matter which group does it since it'd end up being me doing the work either way... Well the review processes are slightly different :) I can certainly see myself speccing a getElementsBySelector() API as part of Selectors 2. But either way, the spec for gEBS is simple; it returns the same type as getElementsByTagName(), it is accessible from Document and Element nodes and selects a subset of the descendants of that node, it takes a single argument (a string representing a selector), its first version doesn't support namespaces, and it raises an exception SYNTAX_ERR if the string can't be successfully parsed by the UA. As a general outline this is very good, ducking the tricky issue of namespaces is sensible, and much I prefer this sort of proposal to a specific className one. Cheers, Jim.
Re: [whatwg] getElementsByClassName()
Jim Ley wrote: On 2/4/06, Lachlan Hunt [EMAIL PROTECTED] wrote: Jim Ley wrote: For example, if an author marked up dates in their document like this (due to the lack of a date element) span class=date2006-02-03T01:30Z/date A nice use case, and one well met by XBL including the currently implemented -moz-binding, met much superiorly as that has quite interesting effects for the screen reader user who is in the middle of reading one of the dates... Actually, the javascript solution would be _superior_ to the XBL one in this case. The screenreader wouldn't pick up on the XBL at all, and would read the content as-is, likely confusing the user. -- dolphinling http://dolphinling.net/
Re: [whatwg] getElementsByClassName()
On Sun, 5 Feb 2006, dolphinling wrote: Actually, the javascript solution would be _superior_ to the XBL one in this case. The screenreader wouldn't pick up on the XBL at all, and would read the content as-is, likely confusing the user. Um, there's no reason an aural browser couldn't support XBL. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] getElementsByClassName()
Ian Hickson wrote: On Sun, 5 Feb 2006, dolphinling wrote: Actually, the javascript solution would be _superior_ to the XBL one in this case. The screenreader wouldn't pick up on the XBL at all, and would read the content as-is, likely confusing the user. Um, there's no reason an aural browser couldn't support XBL. Hmm, I suppose not. Something still strikes me as making the javascript solution better, though. Perhaps it's a question of localized content vs. localized presentation of content. -- dolphinling http://dolphinling.net/
Re: [whatwg] getElementsByClassName()
On Sat, 04 Feb 2006 03:49:23 +0200, Brad Fults [EMAIL PROTECTED] wrote:
On 2/3/06, Jim Ley [EMAIL PROTECTED] wrote:
...
I can't believe that you're so insistent upon this extremely narrow
set of use cases and that there aren't any other popular use cases for
getElementsByClassName().
If there are no use cases for this function then what are the use
cases for getElementById()? I suppose this should be
addEventToElementById()? How about getElementsByTagName()? That one
too, eh?
The point of getElementsByClassName() is superior control over the
DOM. Where getElementById() falls short by only returning one element
and getElementsByTagName() falls short by only returning one,
document-mandated type of element, getElementsByClassName() gives the
author the control to collect arbitrary sets of elements which all
share the same class or set of classes.
...
Completely irrelevant. See getElementById() or getElementsByTagName().
The requirement for a loaded document is to be expected when one
wishes to manipulate the constructed DOM from that document.
...
Hello!
Very good point. There are many use-cases for getElementsByClassNames().
This is not a useless function, it's a very useful one.
For example:
Lets take the IMDB site. Comments are marked as being positive or
negative, so users can pick which type of comments they want to see. Each
comment *could* (it is not currently AFAIK) styled accordingly (like
change the background-color for negative comments, or whatever). It is
fair to assume that the negative and positive comments will have their own
class name. With getElementsByClassNames() you can have a UserJS that
manipulates those comments (for example, it could parse them all and save
a local db of negative comments :) ).
Or ... another use-case would be a site-wide JavaScript for my site that
finds all emoticons from comments (yes, each emoticon has
class=emoticon). I could do cool things with 'em using
getElementsByClassNames(). If I currently want to manipulate all the
emoticons from JS I have to use getElementsByTagName('img') then check for
.className=emoticon which is slow and not very efficient.
Now ... we could go on and provide many more imaginary use-cases ... or we
can go on and discuss something else :).
--
http://www.robodesign.ro
ROBO Design - We bring you the future
Re: [whatwg] getElementsByClassName()
On 2/4/06, Brad Fults [EMAIL PROTECTED] wrote: I can't believe that you're so insistent upon this extremely narrow set of use cases and that there aren't any other popular use cases for getElementsByClassName(). It's the only one that's ever been voiced without the extreme prompting now generating some.The WHAT specifications (like the W3 specifications, indeed most specifications) are creating features, and never voicing why they're necessary, the use cases are simply not made - there probably are use cases for them, but they _must_ be voiced, otherwise you simply cannot review them. The requirement for a loaded document is to be expected when one wishes to manipulate the constructed DOM from that document. No such requirement exists in web-browsers today, why are you suddenly inventing it? I want my designer to be able to specify an arbitrary set of elements in the markup for a web app that are to be widgets. Now if the web app is sent out to a client that supports function X, I want to construct this X-widget around each of the elements in the set previously defined. This use case is fulfilled by the -moz-binding and similar proposals, it does this more successfully (as it does not lead to the inconsistent UI problem) I don't see the point in having both className selectors and -moz-binding XBL approaches, but thanks for the details. Now that we can get past why we're specifying such a function, I feel the need to reiterate the constraints on its specification, but we can't know the constraints until we know why we're specifying it... 2. getElementsByClassName() must be *binding language* agnostic. That is, we cannot assume that it will only be used in JS. I don't agree that it's necessary to do this, one of the historic problems of the DOM in the ECMAScript context (and others) is that individual language strenghts are not gained. There is nothing obviously wrong with having language specific API's. If getElementsByClassName() receives an array (synonymous with list), which all binding languages I am aware of are capable of supplying, Do some binding languages not require the type of the parameter to be specified as either an array or a string? I do not personally see the use case for a class specific operator, either a CSS Selector method, that selects on any CSS selector, or nothing seems appropriate. Cheers, Jim.
Re: [whatwg] getElementsByClassName()
On 2/4/06, Lachlan Hunt [EMAIL PROTECTED] wrote: Jim Ley wrote: For example, if an author marked up dates in their document like this (due to the lack of a date element) span class=date2006-02-03T01:30Z/date A nice use case, and one well met by XBL including the currently implemented -moz-binding, met much superiorly as that has quite interesting effects for the screen reader user who is in the middle of reading one of the dates... Cheers, Jim.
Re: [whatwg] getElementsByClassName()
Le 2006-02-03 à 19:20, Simon Pieters a écrit :
I have a some markup like this:
ul
lia href=#tab1Tab 1/a/li
lia href=#tab2Tab 2/a/li
/ul
div id=tab1 class=pane
...
/div
div id=tab2 class=pane
...
/div
With the help of a style sheet, the script transforms this into
some sort of tab view. It search for each div of class pane. It
looks for links pointing to each of these div elements and attach
an event to each so that when you click on the link it shows the
pane (and hides other panes).
You could do this with the following CSS:
.pane:not(:target) { display:none; }
Thus getElementsByClassName() is not needed for this use case.
Hum, I suppose so, but that's only because I have skipped the part
where I also want the link to be styled differently when its pane is
shown, not just the targeted pane. The thing must look like a
multiple-tab view after all.
But surely, combining this CSS with a way to listen to changes to the
current :target element (so I can style the links) could do the
work beautifully. In fact, an event to catch changes made to the
fragment identifier would be very useful here and in many other
situations (I'm thinking of all these AJAX apps that wish to keep a
permanent link by changing the fragment identifier while still
working well with the back button).
Michel Fortin
[EMAIL PROTECTED]
http://www.michelf.com/
Re: [whatwg] getElementsByClassName()
Jim Ley wrote: On 2/4/06, Brad Fults [EMAIL PROTECTED] wrote: The reasons why XBL is not currently an acceptable substitute are numerous, including its extremely limited implementation, So something with no implementation should be taken over something with an existing implementation, that's pretty odd. Surely you can see that's a insane argument given the relative complexity of implementing the _entire_xbl_spec_ vs. implementing a single DOM method. Also I would be surprised if there weren't multiple implementations of getElementsByClassname floating around in javascript libraries. So you can't really call it unimplemented. If other authors and designers do see use cases and have concrete examples of where this function would add a great deal of power and flexibility to their tool set, it is worth consideration and design. But a CSSSelector method has more power, not less, and adds little in implementation complexity surely? Indeed. And DOM3 XPath (which is already implemented in one or more browsers) does almost everything that a CSS selector based method can do (possibly one can't do the equivalent of :hover although supporting dynamic pseudo-classes may make the implementation more complex than DOM3 - you'd have to ask some implementors). So the only reason to add a getElementByCSSSelector method is because we feel that either a) DOM3 XPath is too hard to implement and getElementsByCSSSelector is much easier or b) because the added authoring simplicity provided by using widely understood CSS selectors is worth the substantial increase in complexity that providing two methods to solve the same problem will bring. I have no idea if either a) or b) is true. I do however know that arguing we shouldn't implement feature x because more complex features y and z provide a superset of x's features is wrong if a cost benefit analysis shows that x is better value for complexity than y or z. In this case you seem to be counting all the costs of implementing getElementsByClassName and ignoring all the costs of other, more general, proposals.
Re: [whatwg] getElementsByClassName()
James Graham wrote: Also I would be surprised if there weren't multiple implementations of getElementsByClassname floating around in javascript libraries. So you can't really call it unimplemented. While there are many JavaScript implementations (I even wrote one myself a few months ago), all the custom JS implementations count for exactly zero native implementations in UAs, which is what really counts. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] getElementsByClassName()
On 2/3/06, Gervase Markham [EMAIL PROTECTED] wrote: Musing... If you have: p class=foo barFred/p p class=bar fooBarney/p p class=foo baz barWilma/p which should be picked up by getElementsByClassName(foo bar)? In the string split mode, it would pick up all three. However, I suggest that designers might be misled by this interface into thinking that it only picks up the first one - which matches exactly. So I think a multiple-argument interface would remove this possible confusion, and make things more obvious than a whitespace-splitting interface. getElementsByClassName(foo, bar) ideally, but if that's hard, then getElementsByClassName([foo, bar]); So I agree with Brad, I think :-) Gerv In http://my.opera.com/community/forums/topic.dml?id=121081 I wrote 2 prototypes for Opera and Firefox: getElementsByClassName() http://my.opera.com/burnout426/homes/files/getElementsByClassName.zip and getElementsByClassNameNS() http://my.opera.com/burnout426/homes/files/getElementsByClassNameNS.zip. I just threw them together as a proof of concept, but I have no doubt that the class attribute value should be a space separated list of classnames and the getElementByClassName function should split up the class attribute value into an array and then search for the class name to see if there's a match (Or use regex to be simpler). I also added a case insensitve search option. As the case above, getElementByClassName(foo bar) doesn't make sense to me because there are 2 class names in there and it's getElementByClassName, not getElementsByClassName*s*(). In getElementByClassName(foo bar) , foo bar should be normalized foo and therefore match all 3 because they all have foo in the class attribute value. getElementsByClassName*s*() should be a separate function and I agree, getElementsByClassNames*s*(foo, bar) would be great if possible. Just my thoughts, burnout426
Re: [whatwg] getElementsByClassName()
Shadow2531 wrote: I just threw them together as a proof of concept, but I have no doubt that the class attribute value should be a space separated list of classnames and the getElementByClassName function should split up the class attribute value into an array and then search for the class name to see if there's a match (Or use regex to be simpler). I also added a case insensitve search option. IMO there should be no option; if class names are defined as case-insensitive, we should search case-insensitively, and if they aren't, we shouldn't. As the case above, getElementByClassName(foo bar) doesn't make sense to me because there are 2 class names in there and it's getElementByClassName, not getElementsByClassName*s*(). In getElementByClassName(foo bar) , foo bar should be normalized foo and therefore match all 3 because they all have foo in the class attribute value. I think this behaviour would violate the rule of least surprise. Better behaviour would be to match nothing, treating foo bar as a single class name. Rationale: just because HTML doesn't allow class names with spaces doesn't mean no other languages do, and the coding error would be much easier to spot (you'd get no elements at all). getElementsByClassName*s*() should be a separate function and I agree, getElementsByClassNames*s*(foo, bar) would be great if possible. I also think it's not ideal to have two functions with such similar names. Gerv
Re: [whatwg] getElementsByClassName()
On 2/3/06, Shadow2531 [EMAIL PROTECTED] wrote: O.K. Then, it should be getElementByClassName*s*() where you have have 1 or more classname arguments. If you pass more than 1 class name, both class names have to be present in the classname attribute for the element to match. I just to be clear. If you do getElementByClassName(this, that, other), should that only match elements that have all those in their class attribute value or does it match any element that has this and any element that has that and any element that has other? I just want to be sure on the intended behavior. burnout426
Re: [whatwg] getElementsByClassName()
Shadow2531 wrote: O.K. Then, it should be getElementByClassName*s*() where you have have 1 or more classname arguments. If you pass more than 1 class name, both class names have to be present in the classname attribute for the element to match. This seems like a sensible change. Call it getElementsByClassNames() would make it obvious that if you supply multiple class names, you get only elements with all those names. And it would be a reasonably obvious reduction that if you just supply a single name, you would get all elements which had that one class name. So we've ended up with: elem.getElementsByClassNames(foo); and elem.getElementsByClassNames([foo, bar]); or elem.getElementsByClassNames(foo, bar); or both. Are there similar functions in the DOM at the moment which can take multiple arguments? Do you pass an array or multiple individual arguments, or can you do both? Gerv
Re: [whatwg] getElementsByClassName()
On 2/3/06, Gervase Markham [EMAIL PROTECTED] wrote: This seems like a sensible change. Call it getElementsByClassNames() would make it obvious that if you supply multiple class names, you get only elements with all those names. And it would be a reasonably obvious reduction that if you just supply a single name, you would get all elements which had that one class name. Rather than talk about technical details, can be talk about the actual use cases please, working groups keep on creating things which need implementing, testing etc. without once giving the use case. This thread is now 21 messages old and there's not one use case which is fulfilled by a getElementsByClassName. All the ones suggested are fulfilled by the ability to attach events to a particular class name. Jim.
Re: [whatwg] getElementsByClassName()
Gervase Markham wrote:
Brad Fults wrote:
I see this is still an open issue[1]. Is this now implemented as #1
(space-delimited class names to match)?
I suggest either going with the space-delimited approach (as it's
language-agnostic and well-defined at least) or with Aankhen's
suggestion of a single array argument.
Musing...
If you have:
p class=foo barFred/p
p class=bar fooBarney/p
p class=foo baz barWilma/p
which should be picked up by getElementsByClassName(foo bar)?
this also raises the possibility of some confusion as the order of
inheritance is important:
foo
{
color: red;
}
bar
{
color: blue;
}
in the quoted example Fred and Wilma would be blue and barney red. so
the distinction between class=foo bar and class=bar foo is real, not
merely syntactic. a search for foo should pick up either but a search
for foo bar should only find the first, so IMO a comma seperated list
would be better in that respect:
1. getElementsByClassName(foo bar,foo tang,woo tang)
this use of explicit class matching could, however be considered an
advanced use of the function, with emphasis on the simpler:
2. getElementsByClassName(bar,tang)
as an aside this then yields another level of even more complex
behavioural possibilities:
3. getElementsByClassName(foobar)
though in this example the ClassName, having not being explicitly
declared in the markup. is not what is being selected, but a derived
inheritance, perhaps warranting a new function
4. getElementsByRelationship(foo:firstChild)
what this would mean, therefore is that
5. div class=foo bar
would be selected by example 1. whereas
6. div class=foodiv class=bar
would be selected by example 3. specifically and example 4. if the
designer wanted to make assumptions about the resuting DOM
Ric
Re: [whatwg] getElementsByClassName()
On 2/3/06, Gervase Markham [EMAIL PROTECTED] wrote: This seems like a sensible change. Call it getElementsByClassNames() would make it obvious that if you supply multiple class names, you get only elements with all those names. And it would be a reasonably obvious reduction that if you just supply a single name, you would get all elements which had that one class name. So we've ended up with: elem.getElementsByClassNames(foo); and elem.getElementsByClassNames([foo, bar]); or elem.getElementsByClassNames(foo, bar); or both. O.K. Are there similar functions in the DOM at the moment which can take multiple arguments? Do you pass an array or multiple individual arguments, or can you do both? For getElementsByClassNames( var ) var could be an object or a string. The function could use typeof to check which one it is. If it's an object, the function could check its elements to make sure they are strings. So, you could pass a list or a string. For getElementsByClassNames(string1, string2, string3, stringN), the function has an 'arguments' array that will output string1,string2,string3,stringN. So, it should be possible to support, passing 1 or more strings, or 1 or more arrays, or a mixture. We don't want to go crazy though. I'd prefer to just be able to pass one or more strings and keep it at that. However, if you had an array of strings, you'd then be forced to build a call to getElementsByClassNames() via eval() or use some other method. Do we need to be able to pass an array of arbitrary classnames? burnout426
Re: [whatwg] getElementsByClassName()
Jim Ley wrote: Rather than talk about technical details, can be talk about the actual use cases please, working groups keep on creating things which need implementing, testing etc. without once giving the use case. This thread is now 21 messages old and there's not one use case which is fulfilled by a getElementsByClassName. All the ones suggested are fulfilled by the ability to attach events to a particular class name. I thought we were discussing it because it was in the spec? :-) I know nothing of this attaching events to a class name of which you speak. Can you give me a reference to a document or proposal describing it? Gerv
Re: [whatwg] getElementsByClassName()
ROBO Design wrote: I believe there's some disagreement on what is this function supposed to do. Well, not according to the current spec, which says: 1. Should it return *all* elements which have *all* the class names wanted? this one. Of course, you may disagree with the spec. 4. Should the order matter? No, because class name ordering does not matter in the source or in CSS. I also believe this function will always be confusing, no matter what. To drop all confusion just rename it to getElementsByCSSselector() and you get the exact idea to as what you are supposed to provide as an argument (if you know CSS). Yet, this is something Ian Hickson said is beyond the purpose of WHATWG. That turns the function into something which is dependent on CSS rather than just dependent on the markup language. That is a reasonably large change in scope IMO. CSS selector parsers in JS have been written (I believe Dean Edwards has one); but such things would be much easier to implement if you had getElementsByClassNames() to go with getElementsById(). Gerv
Re: [whatwg] getElementsByClassName()
On Fri, 03 Feb 2006 15:31:37 +0200, Ric Hardacre [EMAIL PROTECTED]
wrote:
this also raises the possibility of some confusion as the order of
inheritance is important:
foo
{
color: red;
}
bar
{
color: blue;
}
in the quoted example Fred and Wilma would be blue and barney red. so
the distinction between class=foo bar and class=bar foo is real, not
merely syntactic. a search for foo should pick up either but a search
for foo bar should only find the first, so IMO a comma seperated list
would be better in that respect:
1. getElementsByClassName(foo bar,foo tang,woo tang)
this use of explicit class matching could, however be considered an
advanced use of the function, with emphasis on the simpler:
2. getElementsByClassName(bar,tang)
as an aside this then yields another level of even more complex
behavioural possibilities:
3. getElementsByClassName(foobar)
though in this example the ClassName, having not being explicitly
declared in the markup. is not what is being selected, but a derived
inheritance, perhaps warranting a new function
4. getElementsByRelationship(foo:firstChild)
what this would mean, therefore is that
5. div class=foo bar
would be selected by example 1. whereas
6. div class=foodiv class=bar
would be selected by example 3. specifically and example 4. if the
designer wanted to make assumptions about the resuting DOM
Ric
This is way too wild :).
A comma separated list, or any list separated by any other character can't
be used. The reason has been over-stated (search the mailing list):
basically who what if some other styling language defines that class names
can contain the space char, or the comma char?
AFAIK, Ian said that something like getElementsCSSselector() is something
for the CSS WG from W3C. Defining getElementsByRelationship() would
already touch that subject. He only wants to define
getElementsByClassNames().
--
http://www.robodesign.ro
ROBO Design - We bring you the future
Re: [whatwg] getElementsByClassName()
On Fri, 03 Feb 2006 15:39:26 +0200, Gervase Markham [EMAIL PROTECTED] wrote: ROBO Design wrote: ... Well, not according to the current spec, which says: 1. Should it return *all* elements which have *all* the class names wanted? this one. Of course, you may disagree with the spec. I'd personally like this: getElementsByClassNames([array, of,class,names], bool any) if any = true then get all elements that have any of the class names provided, otherwise get all elements that have *all* class names provided. 4. Should the order matter? No, because class name ordering does not matter in the source or in CSS. True, but Ric has made an interesting point about the order of class names, which does actually matter. Do we want getElementsByClassNames() to work as the final page render or just logically? I don't even know how to say it, but here's the idea: You have the foo bar example provided by Ric, in which Fred and Wilma paragraphs are blue, and Barney is red. Do you want to be able to make the distinction between Fred, Wilma and Barney with getElementsByClassNames([foo, bar]) ? If the order doesn't matter ... you can't. This is getting way beyond control. ... That turns the function into something which is dependent on CSS rather than just dependent on the markup language. That is a reasonably large change in scope IMO. True. -- http://www.robodesign.ro ROBO Design - We bring you the future
Re: [whatwg] getElementsByClassName()
Ric Hardacre wrote:
Gervase Markham wrote:
If you have:
p class=foo barFred/p
p class=bar fooBarney/p
p class=foo baz barWilma/p
which should be picked up by getElementsByClassName(foo bar)?
this also raises the possibility of some confusion as the order of
inheritance is important:
foo
{
color: red;
}
bar
{
color: blue;
}
in the quoted example Fred and Wilma would be blue and barney red.
According to which rules specified in CSS will that be the case? Given
that CSS (assuming you meant to use class selectors instead), all three
markup samples will be blue. The order of the class names in the markup
is irrelevant. The order of the rules specified in the CSS is relevant
and the latter rule of equal specificity takes precedence.
--
Lachlan Hunt
http://lachy.id.au/
Re: [whatwg] getElementsByClassName()
On 2/3/06, Gervase Markham [EMAIL PROTECTED] wrote: Jim Ley wrote: Rather than talk about technical details, can be talk about the actual use cases please, working groups keep on creating things which need implementing, testing etc. without once giving the use case. This thread is now 21 messages old and there's not one use case which is fulfilled by a getElementsByClassName. All the ones suggested are fulfilled by the ability to attach events to a particular class name. I thought we were discussing it because it was in the spec? :-) Firstly it has to justify its inclusion in the spec. Until we know what it's _for_ how can we possibly design it? Or comment on any individual design? I know nothing of this attaching events to a class name of which you speak. Can you give me a reference to a document or proposal describing it? It's the one use case described in this mailing list, See e.g. http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2006-January/005434.html the document of course shows no use cases at all. Jim.
Re: [whatwg] getElementsByClassName()
Jim Ley wrote: I know nothing of this attaching events to a class name of which you speak. Can you give me a reference to a document or proposal describing it? It's the one use case described in this mailing list, See e.g. http://listserver.dreamhost.com/pipermail/whatwg-whatwg.org/2006-January/005434.html the document of course shows no use cases at all. Is there some doubt that the ability to tag an arbitrary set of elements and later easily get an array of those elements is a useful feature for web development? If you would like use cases, I present all of the web pages currently using a JS implementation of getElementsByClassName based on getElementsByTagName(*) and some manual class name inspection logic. Gerv
Re: [whatwg] getElementsByClassName()
Lachlan Hunt wrote:
Ric Hardacre wrote:
Gervase Markham wrote:
If you have:
p class=foo barFred/p
p class=bar fooBarney/p
p class=foo baz barWilma/p
which should be picked up by getElementsByClassName(foo bar)?
this also raises the possibility of some confusion as the order of
inheritance is important:
foo
{
color: red;
}
bar
{
color: blue;
}
in the quoted example Fred and Wilma would be blue and barney red.
According to which rules specified in CSS will that be the case?
Given that CSS (assuming you meant to use class selectors instead), all
three markup samples will be blue. The order of the class names in the
markup is irrelevant. The order of the rules specified in the CSS is
relevant and the latter rule of equal specificity takes precedence.
just checked it, i was wrong, oops!
ric
Re: [whatwg] getElementsByClassName()
On 2/3/06, Gervase Markham [EMAIL PROTECTED] wrote: Jim Ley wrote: the document of course shows no use cases at all. Is there some doubt that the ability to tag an arbitrary set of elements and later easily get an array of those elements is a useful feature for web development? I've yet to hear of an actual reason to do so, people keep saying it seems useful... If you would like use cases, I present all of the web pages currently using a JS implementation of getElementsByClassName based on getElementsByTagName(*) and some manual class name inspection logic. Yes, but they're all using it to attach events to every one of the class, which is why you have to look at use cases, the reason they're doing it is not because getElementsByClassName is missing, but because addEventListenerToClass or -moz-binding etc. are missing. It's the classic mistake of looking at making the workarounds easier, when you should be looking at making the underlying use easier. Jim.
Re: [whatwg] getElementsByClassName()
Jim Ley wrote: On 2/3/06, Gervase Markham [EMAIL PROTECTED] wrote: Jim Ley wrote: the document of course shows no use cases at all. Is there some doubt that the ability to tag an arbitrary set of elements and later easily get an array of those elements is a useful feature for web development? I've yet to hear of an actual reason to do so, people keep saying it seems useful... If you would like use cases, I present all of the web pages currently using a JS implementation of getElementsByClassName based on getElementsByTagName(*) and some manual class name inspection logic. Yes, but they're all using it to attach events to every one of the class, which is why you have to look at use cases, the reason they're doing it is not because getElementsByClassName is missing, but because addEventListenerToClass or -moz-binding etc. are missing. It's the classic mistake of looking at making the workarounds easier, when you should be looking at making the underlying use easier. Jim. Hmm, i've used getElementsByTagName in the past couple of days, specifically to walk a table row's data cells to retrieve and write data. This was part of a HTML4 datagrid implimentation and the first time i'd found a use for said function. Having this alongside getElementById but missing out getElementsByClassName seems short-sighted to me. There may be a use we havent thought of yet, and it seems like a logical function to round out the family, rather than bloat. Ric
Re: [whatwg] getElementsByClassName()
Jim Ley wrote: Yes, but they're all using it to attach events to every one of the class, which is why you have to look at use cases, the reason they're doing it is not because getElementsByClassName is missing, but because addEventListenerToClass or -moz-binding etc. are missing. But why implement addEventListenerToClass() when you could implement getElementsByClassName(), which has a far more general utility? As soon as a single non-event-listener-related application comes along, you find you've implemented the wrong thing. Here's a use case, then: the about:license document I just checked into the Mozilla codebase. When the page is called with the spelling about:licence instead of about:license, I use getElementsByClassName() to search for elements with the class correctme, and do a search and replace within them to correct the spelling. However, I can't correct it everywhere as I shouldn't be mutating legal documents. But I can do it in commentary, titles, contents and so on. Gerv
Re: [whatwg] getElementsByClassName()
Gervase Markham wrote:
Brad Fults wrote:
I see this is still an open issue[1]. Is this now implemented as #1
(space-delimited class names to match)?
I suggest either going with the space-delimited approach (as it's
language-agnostic and well-defined at least) or with Aankhen's
suggestion of a single array argument.
Musing...
If you have:
p class=foo barFred/p
p class=bar fooBarney/p
p class=foo baz barWilma/p
which should be picked up by getElementsByClassName(foo bar)?
this also raises the possibility of some confusion as the order of
inheritance is important:
foo
{
color: red;
}
bar
{
color: blue;
}
in the quoted example Fred and Wilma would be blue and barney red. so
the distinction between class=foo bar and class=bar foo is real, not
merely syntactic. a search for foo should pick up either but a search
for foo bar should only find the first, so IMO a comma seperated list
would be better in that respect:
1. getElementsByClassName(foo bar,foo tang,woo tang)
this use of explicit class matching could, however be considered an
advanced use of the function, with emphasis on the simpler:
2. getElementsByClassName(bar,tang)
as an aside this then yields another level of even more complex
behavioural possibilities:
3. getElementsByClassName(foobar)
though in this example the ClassName, having not being explicitly
declared in the markup. is not what is being selected, but a derived
inheritance, perhaps warranting a new function
4. getElementsByRelationship(foo:firstChild)
what this would mean, therefore is that
5. div class=foo bar
would be selected by example 1. whereas
6. div class=foodiv class=bar
would be selected by example 3. specifically and example 4. if the
designer wanted to make assumptions about the resuting DOM
Ric
Re: [whatwg] getElementsByClassName()
On 2/3/06, Jim Ley [EMAIL PROTECTED] wrote: On 2/3/06, Gervase Markham [EMAIL PROTECTED] wrote: Jim Ley wrote: Yes, but they're all using it to attach events to every one of the class, which is why you have to look at use cases, the reason they're doing it is not because getElementsByClassName is missing, but because addEventListenerToClass or -moz-binding etc. are missing. But why implement addEventListenerToClass() when you could implement getElementsByClassName(), which has a far more general utility? As soon as a single non-event-listener-related application comes along, you find you've implemented the wrong thing. Er, no the use case people have is that they want everything that has class X to respond to a particular event, if you model that with getElementsByClassName then you cannot change a class on an element and have it respond, without re-running the attachment, and manage the fact you've already attached it to some classes etc. I can't believe that you're so insistent upon this extremely narrow set of use cases and that there aren't any other popular use cases for getElementsByClassName(). If there are no use cases for this function then what are the use cases for getElementById()? I suppose this should be addEventToElementById()? How about getElementsByTagName()? That one too, eh? The point of getElementsByClassName() is superior control over the DOM. Where getElementById() falls short by only returning one element and getElementsByTagName() falls short by only returning one, document-mandated type of element, getElementsByClassName() gives the author the control to collect arbitrary sets of elements which all share the same class or set of classes. It does not simplify the situation at all. It can also only happen once the element with the class is available, that fails the consistency of UI axiom, since your element will respond differently after the function has run. Completely irrelevant. See getElementById() or getElementsByTagName(). The requirement for a loaded document is to be expected when one wishes to manipulate the constructed DOM from that document. Here's a use case, then: the about:license document I just checked into the Mozilla codebase. When the page is called with the spelling about:licence instead of about:license, I use getElementsByClassName() to search for elements with the class correctme, and do a search and replace within them to correct the spelling. However, I can't correct it everywhere as I shouldn't be mutating legal documents. But I can do it in commentary, titles, contents and so on. What an extremely odd use case, but it is at least a use case, thankyou. I'm not sure it's really one significant enough to warrant implementing it given the large number of other methods of achieving the same spelling correction. Especially as the majority of them can be done without requiring javascript at all. Jim. So here's a shiny use case for us all: I want my designer to be able to specify an arbitrary set of elements in the markup for a web app that are to be widgets. Now if the web app is sent out to a client that supports function X, I want to construct this X-widget around each of the elements in the set previously defined. The construction of each X-widget also depends on various other rendered states of the web app as well as the support level of the client. In order to support sane and graceful degradation, the markup for the app will be sent down in its barest form and the widgets will be added via JS on the client side, taking the constraints into consideration and acting accordingly. It is obvious here that getElementsByClassName() is a perfect fit for the NodeList that I want to manipulate and much better than iterating over every node in the document or something else to that effect. This case is not restricted to event-driven behavior in the least, yet leverages the power of getElementsByClassName() superbly. Now that we can get past why we're specifying such a function, I feel the need to reiterate the constraints on its specification, as some have apparently forgotten them or neglected to read the discussion in its entirety: 1. getElementsByClassName() must be host language agnostic. That is, it must work with HTML, XHTML, SVG, MathML, and any other markup languages which are approved for its use. Assumptions like class names cannot contain a space may be ones that we can't make in light of this requirement (IMHO). 2. getElementsByClassName() must be *binding language* agnostic. That is, we cannot assume that it will only be used in JS. It should be designed, as with all of the other DOM functions to my knowledge, without special features which are specific to any one binding language. That said, I believe a variable number of arguments is completely out. 3. getElementsByClassName() should succeed as expected in the simplest use case. From our use case above, this means calling
Re: [whatwg] getElementsByClassName()
Jim Ley wrote:
On 2/3/06, Michel Fortin [EMAIL PROTECTED] wrote:
Le 2006-02-03 à 09:30, Jim Ley a écrit :
So to generalize the use case, when I want to attach an event to a
child element or an element linked by any other mean to the element
having that class, I can't use addEventListenerToClass.
So this shows that addEventListenerToCSSSelector is really what you
want so you can attach it to A's that are children of the class
doesn't it?
I don't agree with that, there are many valid use cases for a
getElementsByClassName and while it is true that many of them are event
related, that doesn't mean they all are. For example, if an author
marked up dates in their document like this (due to the lack of a date
element)
span class=date2006-02-03T01:30Z/date
A script could get all the elements with the class name of date, parse
it and modify it to the user's preferred time zone and format. So, for
example, the script could change it to this for a typical Australian user:
span class=date03 Feb 2006 12:30 (local time)/span
Whereas, an American user may get this instead:
span class=dateFeb 02, 2006 20:30 (local time)/span
Regarding the idea for addEventListenerToSelector, while I don't think
it should be implemented as a function like that, the idea of attaching
events based on a selector is quite reasonable. What if there was a way
to declaratively attach events to elements in the same way that the
on[event] attributes in HTML do, but with same level of abstraction
provided by CSS using selectors. It could even be used for some the
event-related use cases for getElementsByClassName, simply by using a
class selector.
Of course, there is XML Events, which also seems to be declarative, but
from what I know about it (not very much), it seems to be limited to
specifying IDs of the target/observer elements and putting IDs on every
target element is not always convenient; or otherwise embedding the
event attributes (like ev:handler, ev:event, etc) throughout the markup,
just like with the HTML on[event] attributes.
There's also IE's behaviours using HTCs and the proprietary 'behavior'
property in CSS, but it seems rather complex and HTCs look quite messy
(they seem to be a weird mixture of proprietary HTML with some XML
syntax), although perhaps they were on the right track with the concept
of making them declarative.
For example, using this CSS-like syntax (but it's not CSS).
selector {
event-name: function();
}
For example, using a real (rather nifty) javascript example, called Lightbox
http://www.huddletogether.com/projects/lightbox/
The basic way in which this works is to look for A elements with a rel
attribute containing a lightbox value. For everyone it finds, it
attaches a click event handler, which then handles all the funky
animation and loading of the image within the same page.
Using the above css-like syntax, that could be achieved by doing this:
a[rel=lightbox] {
click: showLightbox(attr(href), attr(title));
}
I know it's not an extremely well thought out idea, it's just a bit of
brainstorming, but it could always be improved. It also seems to be a
little out of scope for the WhatWG.
--
Lachlan Hunt
http://lachy.id.au/
Re: [whatwg] getElementsByClassName()
Lachlan Hunt wrote:
For example, using this CSS-like syntax (but it's not CSS).
selector {
event-name: function();
}
I just remembered BECSS, which is pretty much that exact thing. Strange
how didn't occur to me at all, though it must have been buried in my
subconscious somewhere :-).
http://www.w3.org/TR/becss
--
Lachlan Hunt
http://lachy.id.au/
Re: [whatwg] getElementsByClassName()
On 9/5/05, Lachlan Hunt [EMAIL PROTECTED] 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. Jim.
Re: [whatwg] getElementsByClassName()
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/
Re: [whatwg] getElementsByClassName()
Jim Ley wrote: On 9/5/05, Lachlan Hunt [EMAIL PROTECTED] wrote: 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? Yes, DOM currently is language agnostic, however the optional className parameters aren't compatible with languages which can't do that. So as defined now getElementsByClassName would not manage to do that. In that case, should it be redefined as: NodeList getElementsByClassName(in DOMString classNames); where classNames is a string of space separated class names? That would be just as easy to implement and would work with languages that don't support optional parameters. -- Lachlan Hunt http://lachy.id.au/
[whatwg] getElementsByClassName()
I think variable number of arguments for that function may be cause of many problems. As far as I'm aware W3C DOM never uses functions with variable number of arguments, so design of getElementsByClassName() stands out. Functions with variable number of arguments are problematic in some programming languages, and because of that W3C may not want to include such method in future DOM specfications. Such design forbids any extensibility as well - it won't be possible to add new optional parameters to that function. I suggest that getElementsByClassName() should take only one parameter: string of space-separated class names. This may simplify implementation, because same algorithm can be used to get list of class names from input and from elements. 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. -- regards, Kornel Lesinski
Re: [whatwg] getElementsByClassName()
Anne van Kesteren wrote: Quoting Kornel Lesinski [EMAIL PROTECTED]: 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. This is not how the CLASS attribute works. foo bar means the element has two classes bound to it, foo and bar. With your syntax, getElementsByClassName(bar foo) would also need to match an element with foo bar as value for the CLASS attribute. The problem is that white space handling in parameter values isn't currently defined at all, and I implemented it assuming that each parameter value would contain only one class name. Handling the (currently) erroneous parameter (foo bar)is basically a form of error recovery, and the fact that it returns anything at all is merely a result of how the regex is constructed using it. Before I can fix the implementation in any way, I need to know how white space should be handled before ( foo), after (foo ) and inside (foo bar) the parameter value. At the moment I trim any leading and trailing spaces in most cases (there's currently a bug that stops it working sometimes), but I don't really handle white space inside very well. (foo bar) could basically be handled in the following ways and I need to know which: 1. Equivalent to (foo, bar) (or [class~=foo][class~=bar], or .foo.bar in CSS) 2. The way it currently works. ie. matches foo bar, not bar foo 3. Error, return nothing. -- Lachlan Hunt http://lachy.id.au/
Re: [whatwg] getElementsByClassName()
On 9/5/05, Lachlan Hunt [EMAIL PROTECTED] wrote: 1. Equivalent to (foo, bar) (or [class~=foo][class~=bar], or .foo.bar in CSS) 2. The way it currently works. ie. matches foo bar, not bar foo 3. Error, return nothing. 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, since a class name obviously cannot contain whitespace). Special-casing foo bar and other values seems to be adding complexity without much return. 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])`. Aankhen
