- From: Jonathan Watt <jonathan.watt@strath.ac.uk>
- Date: Fri, 04 Feb 2005 02:42:31 +0000
- To: www-svg@w3.org
- Cc: Thomas DeWeese <Thomas.DeWeese@Kodak.com>
Thomas DeWeese wrote: > > Boris Zbarsky wrote: > >> At this point, from my point of view as an implementor, it just seems >> like an extra burden to implement this, with little basis for it >> existing. I can't even forward the call to Document.getElementById, >> since the two methods have different semantics.... The net effect is >> likely to be that Document.getElementById will be significantly faster >> in Mozilla than Element.getElementById (since for the former it makes >> a lot more sense to keep a global id-to-node hashtable). > > > You _can_ forward the call you just need to check if the returned > element is a child of the element it was called on (a simple walk > of the parent tree, which for most tree's isn't much). > >> Would it make sense to deprecate this method in future SVG versions? > > > Given that the implementation is really not that hard I would > argue against it. > Anything that doesn't have a very good reason to stay should go IMO. One of the WG's highest priorities right now should be to simplify SVG to make it easier for content authors to get to grips with (and hopefully reduce implementation bloat). It's sheer size makes it unweildy, so please don't argue that things should stay on the basis that they're "easy to implement". This is a very poor reason. The real question should be is it useful enough? -Jonathan
Received on Friday, 4 February 2005 02:40:36 UTC