- From: Jonathan Watt <jonathan.watt@strath.ac.uk>
- Date: Fri, 04 Feb 2005 17:55:05 +0000
- 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
existance.
Received on Friday, 4 February 2005 17:53:10 UTC