Re: Changing attributeType="CSS"

Jonathan Watt:
> On 2009-10-31 12:06 PM, Dr. Olaf Hoffmann wrote:
> > Jonathan Watt:
> >>> And in some cases one has
> >>> to find out even more details (for example if a meaningful
> >>> distance exists is concering paced animation for complex
> >>> types).
> >>
> >> I don't follow why this relates to determining whether a property is
> >> animatable.
> >
> > You have to do more than just to indicate, that this is animatable,
> > you have to do some research, how to animate this without creating
> > a conflict with what is already defined in SMIL implictly.
>
> I don't see any conflict between the proposal for attributeType="CSS" and
> "what is already defined in SMIL implictly". Can you give a concrete
> example of a conflict that you see?
>
> > Of course we can say, that this belongs to the process to determine
> > the animatibility of a property or attribute, but this is in some cases
> > not as trivial as to note 'animatable', else we get the funny situation
> > as with the animation of 'transform' in SVG 1.1 or within some
> > drafts of SVG tiny 1.2 for some complex types.
>
> For complex types there will sometimes be ambiguity about exactly *how*
> they should animate, yes. We should clarify the cases where we realize
> there's an issue ahead of time, and if implementers raise new questions
> about others as they implement, then we should clarify them at that point.
>

This is what I meant, it is not directly the question, whether it is 
animatable or not, but what has to be written in the specification
for example whether it is additive or not or only discrete or if there 
is a meaningful way to perform a paced animation. This applies to 
both attributes and properties. 
This means just, if you remove general restrictions, you have to
look at the same time on each property or attribute to see, what
you have to add as information about for example additive
behaviour.
This does not mean, that one should not remove general restrictions.
It means only, that one has to be careful, if this is done.
It means: Don't forget to fix all these nasty little things  *before* you
remove general restrictions.
The best for a proposal would be to create a list containing all
questionable properties (or attributes) and to provide what has
to be written for each of them to avoid a situation with ambiguous
behaviour for one of them.

> >> Are there any properties for which you would want to specifically
> >> prohibit animation? If so, why? If not, maybe the animatable entry in
> >> the property tables should just be removed.
> >
> > If we have a look into SVG tiny 1.2 property table, we find only
> > 'direction' and 'unicode-bidi' to be indicated as not animatable.
> > It is not explained, why they are not animatable, but one can
> > guess, that this happened to protect author from doing things,
> > that can confuse the audience on a very basic level of understanding
> > the document purpose itself.
>
> There's no way to prevent an author from confusing their audience if that's
> what they want to do. I see no good reason to animate these properties, but
> equally I see no good reason to explicitly prohibit them from being
> animated.
>
> > In SVG 1.1 we have others:
> > 'writing-mode', 'glyph-orientation-vertical',
> > 'glyph-orientation-horizontal', 'enable-background'.
>
> You can change these with script, so I see no good reason to actively
> *prohibit* changing them with SMIL.
>

Personally I'm not against removing such restrictions, because in
most cases I cannot see important reasons either.
The same applies for example fot the matrix type of transform -
not obvious for me, why this is not animatable ;o)
The related CSS property is animatable (but the behaviour
is unfortunately a little bit opaque hidden in a C-source code,
maybe with some missing procedures - and from my point
of view the SMIL approach of animating it would be quite
different).

Maybe Chris Lilley has still in mind, why those properties and
some attributes were indicated to be not animatable. He or someone 
else from the 'old times' is hopefully able to explain, what the intention 
is or was.
For me it is no big difference, I just have to add 10 to 100 more
tests to my animation test suite - no big deal ;o)
And in doubt, then I will find out, if there is something forgotten
or ambiguous in the behaviour.
I think, except for something like the matrix type of transform 
they should be typically non additive and discrete, therefore almost simple.
But glyph-orientation-* 'angle' - additive or not? Discrete or not?
It is defined, how to round, the value could be animated continuously
as well.
Needs to be clarified however before one can remove the restriction.

> >> I'm saying that with the current CSS proposals for transitions and
> >> animations you can animate more properties than you can with SMIL
> >> animation. Why would we (or anyone) want that to be the case?
> >
> > I read and commented these proposals already and this is anyway not much
> > related to SMIL animation. It uses a completely different approach and
> > should not be mixed with the more advanced and more complex SMIL
> > approach.
>
> I never proposed mixing.
>
> > It has some advantages in its simplicity and especially the transition
> > proposal provides an interesting functionality, one does not have with
> > SMIL at all or not in a simple way.
> >
> > And looking in the current CSS transition draft indeed the opposite is
> > true, there are only a few properties indicated to be animatable,
>
> I only looked in CSS animations for restrictions and saw none - I
> erroneously assumed that the same was true of transitions. Anyway, my point
> is that I don't see any need to restrict what SMIL can animate relative to
> *either* of these CSS proposals.
>

This could be an issue for the CSS animation proposal es well.
http://www.w3.org/TR/2009/WD-css3-animations-20090320/

In 1 it notes:
'This specification is an extension to CSS Transitions'
and in 3:
'Animations are similar to transitions in that they change the presentational 
value of CSS properties over time. The principal difference is that while 
transitions trigger implicitly when property values change, animations are 
explicitly executed when the animation properties are applied.'

My interpretation was - if there is no other principal difference - that the
transition proposal defines as well, what is animatable, especially it 
http://www.w3.org/TR/2009/WD-css3-transitions-20090320/
interestingly notes in 5 'Animatable properties' and not 'Transitionable 
properties'.

Maybe one has to ask the authors of the proposals to clarify, what this
means ;o)

However, one can animate discrete, but one cannot transition discrete.
On the other hand, for discrete animation on needs a more precise
time interval model as SMIL has, but not the CSS proposals.
On has to define precisely such 'events' like :hover, :active and
:focus as well to compare to SMIL concerning a proper timing,
else authors have to use SMIL anyway to get something predictable ;o)



Olaf

Received on Saturday, 31 October 2009 15:03:13 UTC