- From: Jim Ley <jim.ley@gmail.com>
- Date: Sun, 5 Feb 2006 10:59:39 +0000
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.
Received on Sunday, 5 February 2006 02:59:39 UTC