Re: Proposal: Fix discrete to animation in SVG 1.1 Second Edition

Dear Olaf,

Thank you very much for your mail. I appreciate your feedback very
much. I'd like to respond to your comments one by one.

> well, with the behaviour defined in SMIL the discrete to-animation
> is comparable to a set-animation. Is it confusing too, that set sets
> the value at the begin of the active duration and not in the middle?
> And it is comparable with a values-animation, if values contains
> only one list item. Is it confusing too, that this type of animation
> sets the value at the begin of the active duration and not in the
> middle?

Regarding comparison with set-animation and values-animation I think a
much more natural comparison is with from-to animation and with
to-animation of another calcMode.

For example, with an underlying value of 100,

from=200 to=300 calcMode=linear   --> animation from 200 to 300
from=200 to=300 calcMode=discrete --> animation from 200 to 300
         to=300 calcMode=linear   --> animation from 100 to 300
         to=300 calcMode=discrete --> animation sets value to 300

Clearly the last line seems inconsistent. By comparison to the other
animations one would expect the result to be animation from 100 to
300.

Considering just the last two lines, I believe it is intuitive to
expect the calcMode=discrete animation to simply be a stepped version
of the linear case. In fact, if the target attribute is not
interpolatable the user agent will automatically fall back to
calcMode=discrete in which case I believe a comparable animation
should result.[1]

Set animation and values animation are more distant syntactically and
conceptually.

> I think, because it is defined in all SMIL versions in the same way,
> there should be no inconsistent change in  SVG 1.1 Second Edition,
> resulting mainly in even more complications.

I originally thought the same way[2] but I've since come to think that
this behaviour is so counter-intuitive as to warrant changing the
spec.

The evidence for this is:
* Every implementation I've encountered (besides the one I "fixed")
does not comform to this part of the spec. I take this as evidence
that what the spec defines does not naturally fall out of the model
but is inconsistent.
* The SVG 1.1 Test Suite does not conform to this part of the spec but
mandates what I have proposed and believe is more intuitive.
* Content authors have expressed surprise at this unexpected behaviour.[3]

Rather than trying to bend people's intuition to match an abitrary
spec, I think it is better to bend the spec to match intuition.

> It is nice, that to-animations are implemented better in
> Mozilla/Gecko than in most other viewers, this indicates, that
> a useful feature is implementable, and maybe one time, bugs
> in other viewers are fixed, it will really become usable for authors ;o)

I agree it is implementable, but I don't understand why it is useful.
As you rightly point out, the same behaviour is already possible with
set-animation and values-animation.

> Because set-animations are not applicable for the transform attribute,
> discrete to-animations could be really useful. For most other attributes
> however, discrete to-animation are typically not very interesting, because
> single-item-values-animations or set-animations can be used.

Ultimately I hope we can remove animateTransform altogether (in which
case it should be possible to target a transform attribute with set)
but until then, it seems it is still possible to set a transform value
for the entire duration of an interval using a values-animation.

Thanks again,

Best regards,

Brian Birtles

[1] http://www.w3.org/TR/smil-animation/#AnimFuncCalcMode
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=544855#c4
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=544855#c11

Received on Wednesday, 9 March 2011 00:47:09 UTC