|
|
Re: getElementById method on SVGSVGElement: msg#00020
web.svg
|
Subject: |
Re: getElementById method on SVGSVGElement |
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
|
|