Re: Setting animVal.value?

Hi Brian.

Brian Birtles:
> Is there a reason for making the contents of animVal readonly only when it
> is animated?

I don’t think there is a good reason for it being read only only when
animated.

> For example, consider SVGAnimatedLength. For the animVal member we're told:
> 
>    If the given attribute or property is being animated, contains the
>    current animated value of the attribute or property, and both the
>    object itself and its contents are readonly. If the given attribute or
>    property is not currently being animated, contains the same value
>    as 'baseVal'.[1]
> 
> So it would seem that when the length is not being animated (which I presume
> here to mean that there is no active interval nor a frozen animation
> targeting that length) it is synonymous with baseVal, so that, for example,
> setting animVal.value, is equivalent to setting baseVal.value.

It does seem to say that, yes.

> On the other hand, when the length is being animated, the contents of
> animVal are readonly.
> 
> So I wonder why anyone would try to set the contents of animVal? The only
> use case I can conceive of is as a means to determine if the length is
> currently being animated, i.e. try to set animVal.value and catch the
> exception. If an exception is caught, then it is being animated.
> 
> Was that the intention of the specification?

I can’t speak for the original authors of the SVG DOM, but I doubt that
was the intention.

> If not, can I suggest it would be better to simply make the contents
> of animVal always readonly. This would have the advantage of being
> more predictable for script (as well as being easier to implement).

Yes I think that would be better.  I think animVal should always be a
distinct object from baseVal, but whose contents will happen to be the
same as the baseVal contents when the attribute is not animated.

Very brief testing showed that Batik 1.7, Opera 10a2, a Firefix nightly,
a WebKit nightly and a Chrome something-or-other all returned distinct
objects for SVGCircleElement.r.{baseVal,animVal}:

  <svg xmlns="http://www.w3.org/2000/svg">
    <circle id='c' r='10'/>
    <script>
      r = document.getElementById('c').r;
      alert([r.baseVal, r.animVal, r.baseVal === r.animVal]);
    </script>
  </svg>

> On a related note, the behaviour of readonly attributes here seems
> inconsistent. On the one hand, animVal is readonly and the behaviour when
> setting it is determined by WebIDL[2] which defers to the language-specific
> behaviour for readonly attributes which might be to fail silently. When
> animVal.value is readonly, however, it throws a DOMException
> (NO_MODIFICATION_ALLOWED_ERR). That seems a little inconsistent.

It is a bit inconsistent, I agree.  I suppose that comes from the “read
only-ness” being specified at a different level.  The animVal IDL
attribute is designated as readonly, so the JS property for it can never
be assigned to.  In some other language bindings, you might get a getter
method but no setter method.  SVGLength objects on the other hand can
sometimes have read only contents and sometimes read/write contents.
There’s currently no way to express that the JS property is ReadOnly
sometimes.  I’m not sure that there are other objects in the DOM that
behave like this, either.

> Finally, I think there's a copy-and-paste bug in SVG 1.1 SE where the
> description of the exceptions for SVGLength.value says:
> 
>   Raised when the list cannot be modified.[3]
> 
> I think "list" should be "length." This occurs in various places in this
> part of the spec (e.g. SVGAngle etc. too).

Thanks, fixed.

Cameron

-- 
Cameron McCormack ≝ http://mcc.id.au/

Received on Friday, 7 August 2009 01:46:03 UTC