Re: [whatwg] getElementsByClassName case sensitivity

[Stewart Brodie]

Anne van Kesteren  wrote:

> On Tue, 13 Jan 2009 11:17:08 +0100, Anne van Kesteren 
> 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]

On Tue, 13 Jan 2009 11:17:08 +0100, Anne van Kesteren   
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

Re: [whatwg] getElementsByClassName case sensitivity

[Anne van Kesteren]

On Tue, 13 Jan 2009 11:08:56 +0100, Stewart Brodie  
 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

Re: [whatwg] getElementsByClassName case sensitivity

[Ian Hickson]

On Tue, 13 Jan 2009, Stewart Brodie wrote:
> Anne van Kesteren  wrote:
> 
> > On Mon, 12 Jan 2009 15:25:33 +0100, Stewart Brodie
> >  wrote:
> > > Ian Hickson  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?

I'm not familiar with the tests, but as far as I know the spec is up to 
date here. I'm not aware of any outstanding feedback on this area. Anne?

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] getElementsByClassName case sensitivity

[Stewart Brodie]

Anne van Kesteren  wrote:

> On Mon, 12 Jan 2009 15:25:33 +0100, Stewart Brodie
>  wrote:
> > Ian Hickson  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

[Anne van Kesteren]

On Mon, 12 Jan 2009 15:25:33 +0100, Stewart Brodie  
 wrote:

Ian Hickson  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 :-)



--
Anne van Kesteren

Re: [whatwg] getElementsByClassName case sensitivity

[Stewart Brodie]

Ian Hickson  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

[Anne van Kesteren]

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

Re: [whatwg] getElementsByClassName() feedback

[Garrett Smith]

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.

Assuming an - addCallback - function that acts as an adapter for
addEventListener/attachEvent,

addCallback(document, "mousedown", docMouseDown);

function docMouseDown(ev) {
  var target = EventUtil.getTarget(ev);
  if(!hasClassName(target, "panelActuator") ) return;
}

The above code relies on a - hasClassName - function. These are
widespread on the web and the practice is very common. It might be
useful to have a native function that does the same thing. For
example, the following code assumes a - hasClassName  - function on an
element:-

function docMouseDown(ev) {
  var target = EventUtil.getTarget(ev);
  if(target.hasClassName("panelActuator"));
}

I would like to propose three methods on HTMLElement:-

hasClassName
removeClassName
addClassName

removeClassName - removes the className from the element, trimming ws.
addClassName

Existing code (library functions) would be able to leverage the native
code where available. For example, the following code could be
refactored:-

/** @param {HTMLElement} el
  * @param {String} klass className token(s) to be removed.
  * @description removes all occurrences of klass from
  * element's className.
  */
function removeClass(el, klass) {
el.className = normalizeString(el.className.replace(
  getTokenizedExp(klass, "g")," "));
}

-

function removeClass(el, klass) {
if(el.removeClassName) {
el.removeClassName(klass);
}  else {
el.className = normalizeString(el.className.replace(
  getTokenizedExp(klass, "g")," "));
}
}

. When implementation of Element removeClass is widespread enough, the
function could be replaced with inline code.

If the selectors API gets widespread enough use, it might also be
useful to have Element method | isMatchingSelector(selectorText) |.

Garrett

On Mon, Oct 8, 2007 at 1:25 PM, Ian Hickson <[EMAIL PROTECTED]> wrote:
> 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 [Ov

Re: [whatwg] getElementsByClassName case sensitivity

[Ian Hickson]

On Sun, 9 Dec 2007, David Smith wrote:
>
>   Currently getElementsByClassName is specified as always being case 
> sensitive. This would be fine, except that the primary other use of html 
> class names (CSS selector matching) is only case sensitive in "standards 
> mode". This leads to situations like 
> http://dscoder.com/getelementsbyclassname.html in which CSS and 
> getElementsByClassName match different results, which I think is a 
> rather unintuitive behavior. For this reason, I'd like to propose that 
> the case insensitivity quirk for class name matching be maintained in 
> getElementsByClassName. So far I've spoken to people on the Opera, 
> Firefox, and WebKit teams, and gotten responses ranging from agreement 
> to (paraphrasing) "I don't think it matters, but I'll implement 
> whichever way the spec ends up", so hopefully this won't be a 
> particularly controversial change to make.

I've made it consistent with how classes work in CSS (case-insensitive for 
quirks and case-sensitive otherwise).

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] getElementsByClassName

[Ian Hickson]

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

[Gervase Markham]

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


I definitely remember that there was a thread about this a while back, 
including the concern that getElementsByClassName("foo bar") might 
erroneously lead people to believe that the class names had to be 
present in that order.


I suggest that participants in this thread reacquaint themselves with 
the discussion in the previous one before having it again.


Gerv

Re: [whatwg] getElementsByClassName

[Dan Dorman]

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

[Jonas Sicking]

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

Re: [whatwg] getElementsByClassName

[Lachlan Hunt]

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


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

Re: [whatwg] getElementsByClassName() idea

[Anne van Kesteren]

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

Re: [whatwg] getElementsByClassName() idea

[Alexey Feldgendler]

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

[Lachlan Hunt]

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

[Lachlan Hunt]

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.


Since a DOMTokenString just extends DOMString, anything that accepts a 
DOMString will automatically be able to accept a DOMTokenString, 
including getElementsByClassName.  So your example will already work. 
Conversely, if it were defined as accepting a DOMTokenString, you 
couldn't pass it a regular string.


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")'


That might be useful.  Though, I can't think of any specific use cases 
for needing it other than for class names.


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

Re: [whatwg] getElementsByClassName() idea

[Anne van Kesteren]

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

Re: [whatwg] getElementsByClassName() idea

[Alexey Feldgendler]

On Sun, 05 Nov 2006 15:33:00 +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?


-- 
Alexey Feldgendler <[EMAIL PROTECTED]>
[ICQ: 115226275] http://feldgendler.livejournal.com

Re: [whatwg] getElementsByClassName()

[Gervase Markham]

Dean Edwards wrote:

var menus = document.getElementsByClassName("menu");

That is much more intuitive for the most common case.


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.


Gerv

Re: [whatwg] getElementsByClassName()

[Alexey Feldgendler]

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()

[Dean Edwards]

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()

[Ian Hickson]

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()

[Joao Eiras]

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()

[Ian Hickson]

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.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] getElementsByClassName()

[Joao Eiras]

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()

[Ian Hickson]

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?

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] getElementsByClassName()

[Dean Edwards]

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()

[Ian Hickson]

On Sun, 22 Oct 2006, Anne van Kesteren wrote:
>
> 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") ..?

None; it's just a complementary method in line with getElementById(), 
getElementsByTagName(), and getElementsByName() methods. (Also, it returns 
a live list, instead of a static list.)


On Mon, 23 Oct 2006, James Graham wrote:
> 
> 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.

I think there's room for both. I don't have a strong opinion, though; if 
other people think we should not add getElementsByClassName() then please 
speak up.


On Mon, 23 Oct 2006, Dean Edwards wrote:
> 
> This has been debated to death. People want this function. So I think we 
> should add it. The only arguments against are that there are potentially 
> better solutions, like matchAll/matchSingle. I don't think that is a 
> good enough reason to not include it. First, it is analogous to 
> getElementsByTagName. Second, alternatives are not currently 
> implemented.
> 
> It is not uncommon for API's to provide more than one way to achieve the 
> same end. I don't see why the DOM should be any different. It is not 
> going to break anything and people want it -- so let's spec it. I 
> haven't heard a good argument against inclusion yet and we are on the 
> 87th comment in this thread.

I agree with Dean.


On Mon, 23 Oct 2006, Jonathan Worent wrote:
>
> 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:
> Para 1
> Para 2
> Para 3
> 
> 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.

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.

-- 
Ian Hickson   U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/   U+263A/,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Re: [whatwg] getElementsByClassName()

[Jonathan Worent]

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:
Para 1
Para 2
Para 3

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()

[Dean Edwards]

On 23/10/06, Charles McCathieNevile <[EMAIL PROTECTED]> wrote:

"adding stuff people want instead of referring them to vapourware" isn't a
very clear distinction. Since both are currently vapourware, it would be
helpful to ahve some rational basis for determining that one is desired
and another is not. Like James, I so far don't see that in this discussion.



This has been debated to death. People want this function. So I think
we should add it. The only arguments against are that there are
potentially better solutions, like matchAll/matchSingle. I don't think
that is a good enough reason to not include it. First, it is analogous
to getElementsByTagName. Second, alternatives are not currently
implemented.

It is not uncommon for API's to provide more than one way to achieve
the same end. I don't see why the DOM should be any different. It is
not going to break anything and people want it -- so let's spec it. I
haven't heard a good argument against inclusion yet and we are on the
87th comment in this thread.

-dean

Re: [whatwg] getElementsByClassName()

[Charles McCathieNevile]

On Mon, 23 Oct 2006 11:49:37 +0200, James Graham <[EMAIL PROTECTED]> wrote:


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.


"adding stuff people want instead of referring them to vapourware" isn't a  
very clear distinction. Since both are currently vapourware, it would be  
helpful to ahve some rational basis for determining that one is desired  
and another is not. Like James, I so far don't see that in this discussion.


cheers

Chaals

--
  Charles McCathieNevile, Opera Software: Standards Group
  hablo español  -  je parle français  -  jeg lærer norsk
[EMAIL PROTECTED]  Try Opera 9 now! http://opera.com

Re: [whatwg] getElementsByClassName()

[James Graham]

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()

[Dean Edwards]

On 22/10/06, Anne van Kesteren <[EMAIL PROTECTED]> wrote:

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.


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.

-dean

Re: [whatwg] getElementsByClassName()

[Anne van Kesteren]

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

Re: [whatwg] getElementsByClassName()

[Dean Edwards]

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()

[Anne van Kesteren]

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

Re: [whatwg] getElementsByClassName()

[Dean Edwards]

Anne van Kesteren wrote:

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") ..?



I didn't know that this had been implemented. Which browser is 
supporting it?


-dean

Re: [whatwg] getElementsByClassName()

[Anne van Kesteren]

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

Re: [whatwg] getElementsByClassName()

[Ian Hickson]

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:
> 
> Fred
> Barney
> Wilma
> 
> which should be picked up by getElementsByClassName("foo bar")?
> 
> In the "string split" mode, it would pick up all t

Re: [whatwg] getElementsByClassName()

[Shadow2531]

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()

[Ric Hardacre]

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()

[Shadow2531]

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()

[BÁRTHÁZI András]

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()

[Ric Hardacre]

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()

[Dean Edwards]

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()

[Ian Hickson]

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()

[Anne van Kesteren]

Quoting Brad Fults <[EMAIL PROTECTED]>:

What will it take to kick start the process for
getElementsBySelector()? I suppose a few browser implementations would
be good fuel.


1. A testsuite
2. A specification that conforms to that testsuite
3. People updating 1 and 2 based on implementation feedback

(This is not specific to this feature.)


--
Anne van Kesteren

Re: [whatwg] getElementsByClassName()

[ROBO Design]

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()

[Brad Fults]

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()

[dolphinling]

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

Re: [whatwg] getElementsByClassName()

[Ian Hickson]

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()

[dolphinling]

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)

2006-02-03T01:30Z



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

Re: [whatwg] getElementsByClassName()

[Jim Ley]

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()

[Ian Hickson]

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()

[James Graham]

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  
(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()

[Jim Ley]

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()

[James Graham]

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.



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.


Unless x offers significant simplicity for end users (i.e. script 
authors) above y and z. In this case that's probably not true but it's 
also not entirely clear that getElementsByCSSSelector will be 
standardized and implemented any time soon (especially if it is punted 
to the CSS WG).

Re: [whatwg] getElementsByClassName()

[James Bennett]

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()

[Jim Ley]

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()

[James Graham]

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.

Re: [whatwg] getElementsByClassName()

[Lachlan Hunt]

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()

[James Graham]

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()

[Jim Ley]

On 2/4/06, Lachlan Hunt <[EMAIL PROTECTED]> wrote:

> One issue with a Selector method though, how do we handle namespace
> prefixes?  Selectors states that the mechanism for declaring a namespace
> prefix is left up to the language implementing Selectors.  If we say the
> script uses the same prefixes declared in the markup using xmlns:foo="",
> then that ties the JS to the document and other documents that use those
> same prefixes.

I think that would be a bad idea, as I think you are, for the same
reason as the QNames in attribute context we've heard so many times
before from me.

>  If we say it uses those declared in CSS with @namespace,
> then that ties the script to the CSS.  Would we need another method
> called addNamespace(namespaceURI, prefix)?

Off the top of my head I would suggest a namespace handler object that
exists on the object, and if the stylesheet language of the document
is css it's pre-filled with the namespace's from css.  This allows us
to have simple use for the CSS case whilst still supporting the
flexibility to add namespaces later.  but that's very much off the top
of my head.

Cheers,

Jim.

Re: [whatwg] getElementsByClassName()

[Lachlan Hunt]

Jim Ley wrote:
...neither is it apparent that a classname specific shortname is 
worthwhile when a CSSSelector one would be more appropriate.


It should be called getElementsBySelector, rather than CSSSelector, 
because selectors is not specific to CSS (it's not even called "CSS 
Selectors" any more).


One issue with a Selector method though, how do we handle namespace 
prefixes?  Selectors states that the mechanism for declaring a namespace 
prefix is left up to the language implementing Selectors.  If we say the 
script uses the same prefixes declared in the markup using xmlns:foo="", 
then that ties the JS to the document and other documents that use those 
same prefixes.  If we say it uses those declared in CSS with @namespace, 
then that ties the script to the CSS.  Would we need another method 
called addNamespace(namespaceURI, prefix)?



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.


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

Re: [whatwg] getElementsByClassName()

[Jim Ley]

On 2/4/06, Brad Fults <[EMAIL PROTECTED]> wrote:
> I fully admit the possibility that this may be better accomplished
> with some other theoretical and/or vendor-specific technology, but you
> again missed the core point.

the core point is we're inventing something new to meet a use case,
you invent the best thing to meet the use case, you don't invent
things that allow you to write loads more script to fulfil the use
case.  Of course if there were lots of use cases then the general is
good.

The problem is people on this list are continually inventing methods,
without considering the use cases, hopefully by forcing people to
voice the use case and defend it against superior, already implemented
technologies like -moz-binding will mean that people will give the
information first so we are actually able to evaluate their proposals.

You cannot evaluate a proposal without knowing the use case.

> If they are useful, then getElementsByClassName() is
> also useful because it gives an author *more control* over the DOM for
> solving the *same types of tasks*.

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.

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

> its separate
> and higher learning curve, and the fact that it doesn't hurt anyone to
> have two methods to accomplish similar tasks,

It absolutely does hurt to increase complexity of implementations,
specifications and tests!

> > 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.
>
> With all due respect, whether you personally see the use case for a
> specific method to be defined for use by all web authors is largely
> irrelevant.

Well everyone's opinions on the list are largely irrelevant, the WHAT
individual has sole discretion of what goes in.

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

> It is unfair to the rest of the contributors to this specification and
> web authors in general to hold up the design and/or implementation of
> a (generally-agreed) useful tool due to simple personal differences in
> taste or opinion.

I'm not holding up anything?  This is not a democracy.  If you want a
quality specification though, you engage in debates with people who
have opposite ideas.  People have shown enough use cases that indicate
the ability to select elements by a css selector is a useful function
- they've not made the case to me at all that a class name specific
one is useful though.

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

Then why isn't className?  or why don't we just wait for that, having
both cssselector and classname is needless verbosity.  Whilst
implementation of ClassName is trivial if you CSSSelector, increasing
the memory footprint of a DOM is not useful to anyone, and a severe
limitation on getting it on many devices.

Jim.

Re: [whatwg] getElementsByClassName()

[Brad Fults]

On 2/4/06, Jim Ley <[EMAIL PROTECTED]> wrote:
> 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?

My mistake. Replace "document" with "element" and you'll have my
intended meaning. That's not a suddenly invented requirement, as is
demonstrated with both getElementById() and getElementsByTagName().

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

I fully admit the possibility that this may be better accomplished
with some other theoretical and/or vendor-specific technology, but you
again missed the core point.

The utility and power of getElementsByClassName() is derived from the
same exact vein that both getElementById() and getElementsByTagName()
derive theirs. If they are useful, then getElementsByClassName() is
also useful because it gives an author *more control* over the DOM for
solving the *same types of tasks*. Your elusive use case already
exists in the use and abuse of the other two aforementioned functions.

Now if you want to debate the utility of either of these two existing
DOM functions, I think you will meet a much larger and strongly
opposed group of authors who depend on and use getElementById() and
getElementsByTagName() on a daily basis.

The reasons why XBL is not currently an acceptable substitute are
numerous, including its extremely limited implementation, its separate
and higher learning curve, and the fact that it doesn't hurt anyone to
have two methods to accomplish similar tasks, especially when one of
them lies within a completely different tool set.

> but thanks for
> the details.

Furthermore, your haughty and dismissive tone is neither appreciated
nor necessary in a discussion such as this.

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

I agree. However, as far as I'm aware, we're not defining a binding
language API, but rather the core DOM components to which such an API
would provide a language-specific interface.

> > 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 presume that all binding languages considered can either accomplish
method overloading or else use dynamic typing, either of which would
make this possible. If there are cases where this is not true, let
them be stated and then further examined here. Without such cases I
will continue to (reasonably) assume that any binding languages will
be able to deliver this functionality.

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

With all due respect, whether you personally see the use case for a
specific method to be defined for use by all web authors is largely
irrelevant. 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.

It is unfair to the rest of the contributors to this specificatio

Re: [whatwg] getElementsByClassName()

[Michel Fortin]

Le 2006-02-03 à 19:20, Simon Pieters a écrit :


I have a some markup like this:


Tab 1
Tab 2



...



...


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]

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)
>
> 2006-02-03T01:30Z

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()

[Jim Ley]

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()

[ROBO Design]

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()

[Lachlan Hunt]

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()

[Chris Casciano]

On Feb 3, 2006, at 9:30 AM, 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.



Jumping in a little late here, and with a theoretical case only in that 
I haven't implemented the specific combination of scripting the 
animations and the markup, but work with me here


* Take a form that has been processed with some validation error 
conditions met
* Use CSS class "error" to mark some specific text elements your 
favorite shade of red
* Add on of those fancy "somethings changed here" javascript animations 
the AJAXy kids love to use


And you have something like this (please forgive markup errors):


Some information was missing. Please fill out the 
entire form




Who are you?
Name: />




Favorite Sports (Pick at least one)
 Hockey
 for="football">Football
 for="baseball">Baseball






And a script that on document load (or some other event based trigger 
like a fresh validation attempt.. point being the event listener is 
elsewhere) that would grab all of the elements in the page with class 
"error" and give them an animated/fading border and background for a 
few seconds.


Just the first case that popped into my head. Another rough case would 
be a file serving application[1] where a "thumbnail" isn't always an 
 but sometimes a No Preview Available or perhaps a 
flash or sound player  (or maybe in the future SVG) but in all 
cases the element used is categorized by class="preview".


if pressed I could probably look over some old work with scripting 
animations/dhtml and find cases where this would also be very helpful, 
but they would be less applicable to your typical html usage.


[1] in an app like this one: http://files.lussumo.com/

--
[ Chris Casciano ]
[ [EMAIL PROTECTED] ] [ http://placenamehere.com ]

Re: [whatwg] getElementsByClassName()

[Lachlan Hunt]

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)


2006-02-03T01:30Z

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:


03 Feb 2006 12:30 (local time)

Whereas, an American user may get this instead:

Feb 02, 2006 20:30 (local time)


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()

[Brad Fults]

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 expecte

Re: [whatwg] getElementsByClassName()

[Ric Hardacre]

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:

Fred
Barney
Wilma

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("foo>bar")

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. 

would be selected by example 1. whereas

6. 

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()

[Simon Pieters]

Hi,

From: Michel Fortin <[EMAIL PROTECTED]>

I have a some markup like this:


Tab 1
Tab 2



...



...


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.

Regards,
Simon Pieters

Re: [whatwg] getElementsByClassName()

[Michel Fortin]

Le 2006-02-03 à 11:37, Jim Ley a écrit :


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?


Not in the case of my last mail: 'A' elements can be everywhere on  
the page (in this specific example, they are in some sort of table of  
contents at the top).


I would still need getElementsByClassNames to first get the div  
elements. Then, for each of these div elements I'd have to use  
addEventListenerToCSSSelector with rule "a[href='#{div id}']", where  
{div id} is replaced by the id attribute of the div. If I really  
wanted to, I could have been listening for new DOM elements of class  
"pane" and, for each of them, add an event handler to the  
corresponding A elements.


Anyway, I just wanted to show one valid use for a  
getElementsByClassNames function and (maybe) for more advanced  
functions (like those with CSS selectors). All these functions would  
accomplish however can already be achieved by looping over the  
elements, so it's not like they are absolutely necessary. And you  
would need something a lot more powerful to handle my complex case  
with only one function call (maybe addEventListenerToXPath?) which  
I'm not asking for because it's probably overkill almost all of the  
time. Obviously a line has to be drawn somewhere.



Michel Fortin
[EMAIL PROTECTED]
http://www.michelf.com/

Re: [whatwg] getElementsByClassName()

[Jim Ley]

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?

Jim.

Re: [whatwg] getElementsByClassName()

[Michel Fortin]

Le 2006-02-03 à 09:30, Jim Ley a écrit :


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.


I have been following this list for sometime and did not have much to  
say until now. But I have a use case for this function which cannot  
work by simply using addEventListenerToClass. And that's a real  
working use case for a web application I'm working on, nothing  
hypothetical.


I have a some markup like this:


Tab 1
Tab 2



...



...


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


 - - -

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.


Now, with that particular example in mind, something like  
getElementsByHref('tab1') could be useful too, but surely you can't  
have a function for each html attribute.



Michel Fortin
[EMAIL PROTECTED]
http://www.michelf.com/

Re: [whatwg] getElementsByClassName()

[Jim Ley]

On 2/3/06, Gervase Markham <[EMAIL PROTECTED]> wrote:
> Jim Ley wrote:
> As an aside, I'd be interested in hearing about any JavaScript-less
> methods (that don't involve marking up every instance of the word; this
> doesn't work, as some are e.g. in href attributes.)

I was imaging your build environment making similar sort of changes to
your script and the two resulting copies existing.

Jim.

Re: [whatwg] getElementsByClassName()

[Gervase Markham]

Jim Ley wrote:
> 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.

Oh, I get it. Sorry - I misunderstood.

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

As an aside, I'd be interested in hearing about any JavaScript-less
methods (that don't involve marking up every instance of the word; this
doesn't work, as some are e.g. in href attributes.)

Gerv

Re: [whatwg] getElementsByClassName()

[Jim Ley]

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.

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.

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

Re: [whatwg] getElementsByClassName()

[Gervase Markham]

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()

[Ric Hardacre]

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]

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()

[Ric Hardacre]

Lachlan Hunt wrote:
> Ric Hardacre wrote:
>> Gervase Markham wrote:
>>> If you have:
>>>
>>> Fred
>>> Barney
>>> Wilma
>>>
>>> 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()

[Gervase Markham]

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()

[Jim Ley]

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()

[Lachlan Hunt]

Ric Hardacre wrote:

Gervase Markham wrote:

If you have:

Fred
Barney
Wilma

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()

[ROBO Design]

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()

[ROBO Design]

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("foo>bar")

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. 

would be selected by example 1. whereas

6. 

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()

[Gervase Markham]

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()

[ROBO Design]

On Fri, 03 Feb 2006 15:24:19 +0200, Shadow2531 <[EMAIL PROTECTED]>  
wrote:



Do we need to be able to pass an array of arbitrary classnames?

burnout426


Yes.

--
http://www.robodesign.ro
ROBO Design - We bring you the future

Re: [whatwg] getElementsByClassName()

[ROBO Design]

On Fri, 03 Feb 2006 14:34:14 +0200, Gervase Markham <[EMAIL PROTECTED]>  
wrote:



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

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 believe there's some disagreement on what is this function supposed to  
do.


Example:

paragraph 1
paragraph 2
paragraph 3
paragraph 4

1. Should it return *all* elements which have *all* the class names wanted?

getElementsByClassNames(["foo", "sample"])
returning: p1, p2

2. Should it return *all* elements which have *only* the class names  
wanted?


getElementsByClassNames(["sample", "foo"])
returning: p2

3. Should it return *all* elements which have *any* of the class names  
wanted?


getElementsByClassNames(["sample", "foo"])
returning: p1, p2, p3, p4

4. Should the order matter?

It is clear that getElementsByClassNames("foo bar") can't be an option,  
because the reasons have already been over-stated.


Now... what's left to discuss: what is the function supposed to do? And  
... to pick one of the following two methods of giving the list of class  
names:


getElementsByClassNames("foo", "bar")
or...
getElementsByClassNames(["foo", "bar"])

As I previously stated, I preffer the latter method because we must be  
able to provide an arbitrary number of class names without using the  
(AFAIK deprecated) eval().


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.



--
http://www.robodesign.ro
ROBO Design - We bring you the future

Re: [whatwg] getElementsByClassName()

[Gervase Markham]

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()

[Shadow2531]

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()

[Ric Hardacre]

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:
>
> Fred
> Barney
> Wilma
>
> 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("foo>bar")

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. 

would be selected by example 1. whereas

6. 

would be selected by example 3. specifically and example 4. if the 
designer wanted to make assumptions about the resuting DOM


Ric