W3C home > Mailing lists > Public > whatwg@whatwg.org > February 2006

[whatwg] getElementsByClassName()

From: James Graham <jg307@cam.ac.uk>
Date: Sun, 05 Feb 2006 00:25:16 +0000
Message-ID: <43E545EC.2030108@cam.ac.uk>
Jim Ley wrote:
> On 2/4/06, Brad Fults <bfults at gmail.com> 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.
Received on Saturday, 4 February 2006 16:25:16 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:26 UTC