Re: [SVG1.1F2 LC] precise data type definition of something like "<coordinate>+"

Chris Lilley:

> We decided to adopt the same approach as SVGT1.2, so <foo>+ has been
> replaced by <list-of-foo> throughout.

Well, as indicated in the discussion about 
to-animations tests
it basically moves the 'undefinedness' to the problem, that some
authors tend to use to-animation without understanding the
consequences, if used for list like content or now even for
x, y, dx, dy, rotate (with only one number as value or with
always the same number of numbers as value, what is
neither a mathematical nor practical problem to calculate
such animations).

However the advantage of writing <list-of-foo> instead of <foo>+
is at least, that it is simpler to explain authors, why something
does not work, what they expect, that should be working - still
they cannot realise what they are interested in, but there is 
at least a specified reason for it (not just bugs in viewers ;o)

> In addition, we added the useful clarifications of section "Paced animation
> and complex types" from SVGT1.2 to SVG 1.1 Second Edition.

Yes, good news, maybe that helps together with a fix of the tests within
animate-elem-82-t.svg in the test suite for SVGT1.2 and SVG 1.1 Second Edition 
to improve the quality of viewers and the usability of this feature in the

> Since the changes adopted in SVGT1.2 were largely motivated by your earlier
> comments, we hope that the consistency afforded by adopting the same
> wording in SVG 1.1 Second Edition resolves your comment.
> ISSUE-2341 ACTION-2818

Of course, it improves the quality of those feature (paced animation) in
theory and practice. Related to <list-of-foo> it typically clarifies, that
for arbitrary lists paced animation is meaningless - what is a good point,
authors should understand (instead of specifying such a calcMode for any
attribute without an understanding, what it does under these circumstances ;o)

The change from <foo>+ to <list-of-foo> clearly improves the quality of the
recommendation text. Whether it helps authors to get intended effects or
viewers with desired behaviour - I don't know ;o)
Even for viewBox, what is already clearly <list-of-foo>, there was 
already a discussion, why one cannot have the effect of a smooth
change with a continuous to-animation (basically only because this
is excluded implictly by <list-of-foo> restrictions with a specific rule,
not because of mathematically unsolvable problems).
Well, maybe CSS-transitions, once defined and implemented for SVG, 
may help authors, wanting to have such a feature for arbitrary 
properties/attributes. Within the CSS-list one can follow discussions
of people, that seem to believe, that even more complex entities like
gradients can be animated/transitioned somehow on a higher level than
numbers as simple attribute values as in SVG. We will see, whether
this will be more successful respectively better implemented than
to-animations in SVG currently ;o) - If not, no surprise looking at
realisations of additive and to-animations in SVG, if yes, this might 
indicate, that the restrictions for <list-of-foo> related to additive
behaviour (and therefore somehow to-animations as well) are too 
precautious and unnecessarily simple for implementors, preventing 
meaningful applications for authors.


Received on Tuesday, 30 November 2010 10:34:11 UTC