Robin Berjon wrote:
I *think* that the original intent was to deal with the case where
different implementations may be dealing with different parts of the
same tree (eg a plugin handling a subtree embedded in another document).
This would have allowed that implementation to know that the id
attribute on an element in the SVG namespace is an ID (as the DOM
allows). In retrospect I'm unsure how useful this turned out to be.
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).
Would it make sense to deprecate this method in future SVG versions?
It's the former AFAIK, and indeed should be clarified with an erratum.
If I may ask, are the various errata for SVG 1.1 that I have seen brought up on
this list being tracked somewhere? Is there a timeframe for publishing these
errata?
-Boris