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 17:55:05 +0000
Message-ID: <4203B6F9.2040400@strath.ac.uk>
To: www-svg@w3.org

Thomas DeWeese wrote:
> Hi all,
>     This is a feature that has been in a specification and
> implemented by viewers for over 4 years.  I think deprecation
> needs to be reserved for features that introduce real
> technical issues, not things that someone finds to be a
> minor nuisance to implement. 

I guess that means you don't fall into the camp that believes the SVG 
spec is too big and really needs to be simplified.

> This is just silly, the code is
> attached for Java, are we really concerned about 8 lines of
> code?

Personally I don't care if this method only requires one line of code. 
SVGSVGElement:getElementById is just one example of something that 
*doesn't have a good enough reason to exist given the size of the spec*. 
My main argument would be that the spec needs simplified for *content 
authors*. Any benefits for implementers are of course a welcome bonus.

> public Element getElementByID(String id) {
>     Element e = getOwnerDocument().getElementByID(id);
>     Node n = e;
>     while (n != null) {
>     if (n == this) return e;
>     n = n.getParentNode();
>     }
>     return null;
> }
> Bjoern Hoehrmann wrote:
>> * Thomas DeWeese wrote:
>>>> 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.
>> From http://groups.yahoo.com/group/svg-developers/message/47300 it would
>> seem that this method confuses authors to believe one can re-use IDs in
>> a document. 
>    If you got rid of any feature that confused authors you wouldn't
> be left with anything.  And BTW the confusion on re-using ID's is
> not limited to this method.

Maybe not, but removing it would help.

>> And http://www.w3.org/mid/41FD3969.2070508@mit.edu suggests
>> that it confuses implementers, too. Among the not really that hard to
>> implement features there seem to be more useful methods...
>    This is the message that started this thread, isn't that kind
> of circular?

Why, aren't things in this thread admissable as evidence? :-) Anyway, 
regardless, I would still argue that the main reason for deprecation 
should be that the method isn't useful enough to warrant its continued 
Received on Friday, 4 February 2005 17:53:10 UTC

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