[whatwg] getElementsByClassName()

Jim Ley jim.ley at gmail.com
Sun Feb 5 02:59:39 PST 2006


On 2/5/06, James Graham <jg307 at cam.ac.uk> 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.



More information about the whatwg mailing list