W3C home > Mailing lists > Public > www-svg@w3.org > February 2005

Re: getElementById method on SVGSVGElement

From: Jonathan Watt <jonathan.watt@strath.ac.uk>
Date: Fri, 04 Feb 2005 02:42:31 +0000
Message-ID: <4202E117.2090008@strath.ac.uk>
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?

Received on Friday, 4 February 2005 02:40:36 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 8 March 2017 09:47:02 UTC