[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