W3C home > Mailing lists > Public > www-svg@w3.org > September 2008

Re: baseVal / animVal clarfication

From: Sigurd Lerstad <sigurd@lerstad.com>
Date: Fri, 5 Sep 2008 12:31:59 +0200
Message-ID: <EEE63E509C0047249F826EC49D4D0D8F@dellcomputer>
To: "www-svg" <www-svg@w3.org>

>
> [...]
>
> I don’t have a strong opinion either way, but I think it may be slightly
> more useful for authors to have animVal specifically return an object
> different from baseVal, so you could do this kind of thing:
>
>  <circle id='r' r='100'>
>    <animate attributeName='r' to='200' dur='5s' begin='click'/>
>  </circle>
>  <text id='t'/>
>  <script>
>    t = document.getElementById('t');
>    r = document.getElementById('c').r.animVal;
>    setInterval(function() { t.textContent = r.value }, 500);
>  </script>
>
> I.e., remember the SVGLength object without worrying about whether
> animations are active or not currently.  OTOH, requiring the two
> attributes to return the same value when animations are not active would
> provide a way for authors to detect from script whether an animation was
> being applied to an SVGAnimatedLength.  (But not for SVGAnimatedString
> or some other primitive types.)
>

I agree with you that it's more useful that it returns two different 
objects. My main concern is the additional memory usage. This is mostly 
problematic with large objects like SVGPointList and SVGPathSegList. The way 
I'm thinking of solving that is to have two different objects, one mutable 
and the other immutable, but which point to the same data if the property is 
not being animated, while that would work for this:

polygon.points.appendItem(somePoint);    // ok
polygon.animatedPoints.appendItem(somePoint);    // read-only error

it does not work for this:

polygon.points.getItem(0).x = 10;    // ok
polygon.animatedPoints.getItem(0).x = 10;    // ok (should have been 
read-only error)

After testing Batik/Opera, I've come to the conclusion that they both behave 
like this.

--
Sigurd Lerstad
Received on Friday, 5 September 2008 10:32:35 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:40 GMT