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

Dear all,

Since I haven't heard any further objections to my latest comments on
this issue I'd like to ask the SVG WG to please add this issue to the
agenda for the next telcon.

Thanks,

Brian

On 9 March 2011 09:45, Brian Birtles <birtles@gmail.com> wrote:
> 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, 16 March 2011 01:12:24 UTC