Changing attributeType="CSS"

[Jonathan Watt-3]

http://www.w3.org/TR/SVG11/animate.html#AttributeTypeAttribute

For the attribute "attributeType" the spec says this about the value "CSS":

  "CSS"
    This specifies that the value of "attributeName" is the name
    of a CSS property defined as animatable in this specification.

If the author has explicitly specified "CSS" then clearly they want to target
CSS, and limiting the permitted properties unnecessarily limits the capabilities
of SMIL animation [compared to CSS animation]. It would seem better not to
impose an artificial limit, and to enable parity between SMIL animation and CSS
animation.

Mozilla would like to propose striking the words "defined as animatable in this
specification".

Jonathan

[Chris Lilley]

On Friday, October 30, 2009, 5:23:38 PM, Jonathan wrote:

JW> http://www.w3.org/TR/SVG11/animate.html#AttributeTypeAttribute

JW> For the attribute "attributeType" the spec says this about the value "CSS":

JW>   "CSS"
JW>     This specifies that the value of "attributeName" is the name
JW>     of a CSS property defined as animatable in this specification.

JW> If the author has explicitly specified "CSS" then clearly they want to target
JW> CSS, and limiting the permitted properties unnecessarily limits the capabilities
JW> of SMIL animation [compared to CSS animation]. It would seem better not to
JW> impose an artificial limit, and to enable parity between SMIL animation and CSS
JW> animation.

JW> Mozilla would like to propose striking the words "defined as animatable in this
JW> specification".

How about 'defined as animatable'?

The mai value of the CSS and XML options is to resolve ambiguity for occasional name clashes. Mostly, the default value works fine.


--
 Chris Lilley                    mailto:chris@...
 Technical Director, Interaction Domain
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG

[Dr. Olaf Hoffmann]

I think, SMIL requires, that a format specifies, which attributes
and properties are animatable. 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).
If 'defined as animatable in this specification' is removed,
what defines, what is animatable and what could be the
purpose to indicate which one is animatable and which
one not? It might have reasons, if something is indicated
to be not animatable (maybe it would help to indicate the
reason in the specification, however, to avoid more
questions).

One problem was already discussed and improved for the
case 'auto' in SVG tiny 1.2:
If 'width' and 'height' from CSS is animated, how to animate
the attributes 'width' and 'height' for example for a rect?
What to animate, if 'CSS' is indicated? Currently nothing for
a rect, because they are not applicable and not indicated
to be animatable for rect. No problem, no conflict with the
related attributes.

And about:
"It would seem better not to impose an artificial limit, and to
enable parity between SMIL animation and CSS animation.'

attributeType is always related to SMIL animation and
nothing else. For attributeType XML an attribute is animated
and for attributeType CSS a property, both with SMIL
animation. And in both cases the SVG specification notes
for every attribute or property, whether it is animatable or not.
I cannot see any disparity, expecially because for attributeType
XML is noted too:  'The attribute must be defined as animatable in this
specification'.

Or do you mean the current CSS proposals for transitions and animation?
I think, this attribute is not related to these proposals, they define on
their own, what is animatable concerning CSS animation and such a
property animated within CSS is 'somehow' integrated at some level
in the SMIL sandwich model automatically, I think, because it is derived
from a stylesheet, it has lower priority than an animation with
attributeType CSS, if the same property is animated with SMIL too at
the same time. Obviously this should be avoided by authors, because
it causes even more complexity than what we already have now
(and what was originally not really intended, as Chris Lilley mentioned
already several times, but is now nevertheless defined in the SMIL
sandwich model).

[Jonathan Watt-3]

On 2009-10-30 8:04 PM, Dr. Olaf Hoffmann wrote:
> I think, SMIL requires, that a format specifies, which attributes
> and properties are animatable.

Definition: "all properties".

> 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.

> If 'defined as animatable in this specification' is removed,
> what defines, what is animatable and what could be the
> purpose to indicate which one is animatable and which
> one not? It might have reasons, if something is indicated
> to be not animatable (maybe it would help to indicate the
> reason in the specification, however, to avoid more
> questions).

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.

> And about:
> "It would seem better not to impose an artificial limit, and to
> enable parity between SMIL animation and CSS animation.'
>
> attributeType is always related to SMIL animation and
> nothing else. For attributeType XML an attribute is animated
> and for attributeType CSS a property, both with SMIL
> animation. And in both cases the SVG specification notes
> for every attribute or property, whether it is animatable or not.
> I cannot see any disparity, expecially because for attributeType
> XML is noted too:  'The attribute must be defined as animatable in this
> specification'.

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?

Jonathan

[Robert O'Callahan-3]

2009/10/31 Dr. Olaf Hoffmann <Dr.O.Hoffmann@...>

Or do you mean the current CSS proposals for transitions and animation?
I think, this attribute is not related to these proposals, they define on
their own, what is animatable concerning CSS animation

We want the set of properties animateable by CSS Transitions and SVG Animation to be the same (when specified via specifiedType="CSS"), and for this set to be every CSS property. This will minimize author confusion and maximise the power of SVG Animation. This is more important than following the letter of the SMIL spec.

For legacy compatibility reasons, we can't do this for specifiedType="auto". I propose that the set of CSS properties animated by specifiedType="auto" be fixed forever to the set of properties it animates today, as defined by the SVG spec. This will prevent compatibility problems in the future.

and such a
property animated within CSS is 'somehow' integrated at some level
in the SMIL sandwich model automatically, I think, because it is derived
from a stylesheet, it has lower priority than an animation with
attributeType CSS, if the same property is animated with SMIL too at
the same time. Obviously this should be avoided by authors, because
it causes even more complexity than what we already have now
(and what was originally not really intended, as Chris Lilley mentioned
already several times, but is now nevertheless defined in the SMIL
sandwich model).

How CSS Transitions and SMIL interact is another topic. It's worth discussing, but it needs a separate thread.

Rob
--
"He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6]

[Chris Lilley]

On Friday, October 30, 2009, 8:56:18 PM, Robert wrote:

ROC> We want the set of properties animateable by CSS Transitions and
ROC> SVG Animation to be the same

Yes.

ROC> For legacy compatibility reasons, we can't do this for
ROC> specifiedType="auto".

Could you explain what legacy compatibility reasons mean that you can't do this? Its the default settings, so it would be nice if it worked well. And it would be nice also, if authors didn't have to explicitly say attributeType="CSS" all the time. or, worse, remember which CSS properties are also specified in SVG, miss it off for those, add it for the others. Which is what you seem to be suggesting.

ROC>  I propose that the set of CSS properties
ROC> animated by specifiedType="auto" be fixed forever to the set of
ROC> properties it animates today, as defined by the SVG spec.

That would be bad; see your sentence quoted above.


--
 Chris Lilley                    mailto:chris@...
 Technical Director, Interaction Domain
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG

[Robert O'Callahan-3]

On Sat, Oct 31, 2009 at 9:41 AM, Chris Lilley <chris@...> wrote:

On Friday, October 30, 2009, 8:56:18 PM, Robert wrote:

ROC> For legacy compatibility reasons, we can't do this for
ROC> specifiedType="auto".

Could you explain what legacy compatibility reasons mean that you can't do this?

It means that anyone who's using <animate attribute="height"> instantly breaks, because it would animate the 'height' CSS property which does nothing in SVG.

Jonathan has a new idea that's better than mine. I'll let him propose it :-).

Rob
--
"He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all." [Isaiah 53:5-6]

[Dr. Olaf Hoffmann]

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.
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.


>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.

In SVG 1.1 we have others:
'writing-mode', 'glyph-orientation-vertical', 'glyph-orientation-horizontal',
'enable-background'.

If/because there is no reason explicitly mentioned, why they are not
animatable, this can be interesting to discuss of course. And if it turns
out, that there are good reasons not to animate them this should
not be changed (especially because the same or a similar effect
can be typically realised with an animation of other attributes or
properties, maybe with less influence on the basic level of
understanding).
But in general I agree, if there is no good reason known, why they
are indicated to be not animatable in the full profile, this should be
changed in the next  version of the profile.


>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.
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, much less than
available for example in SVG tiny 1.2 for animation. One reason for this
seems to be the simplicity of the CSS approach - what can change of course
with a more advanced CSS proposal with less simplicity.

I think, because the CSS approach is quite different from the SMIL
approach, this should not be mixed up. The only thing one has to do
for the CSS approach is to note explicitly and understandable the
position of the CSS-animated-or-transitioned property values within the
SMIL sandwich model, that implementors can adjust this properly, avoiding
annoyance for authors and users with implementations with different
priorities.



The main 'historical' issue with attributeType is, that it would have been
more useful in the early days of SMIL to define something like a
pseudo-namespace-prefix for CSS, then there would be no need for
such an attribute and one could simply write something like
xmlns:css="http://www.w3.org/Style/CSS/" attributeName="css:color"
as one can write
xmlns:xlink="http://www.w3.org/1999/xlink" attributeName="xlink:href".
But now it seems to be a little bit late for such an improvement.

[Dr. Olaf Hoffmann]

Robert O'Callahan:

>We want the set of properties animateable by CSS Transitions and SVG
>Animation to be the same (when specified via specifiedType="CSS"), and for
>this set to be every CSS property. This will minimize author confusion and
>maximise the power of SVG Animation. This is more important than following
>the letter of the SMIL spec.

The experiences with SMIL in the last years have shown, that this is
already complex. And I think, it would be much more confusing for authors,
if some (more) arbitrary deviations from SMIL are implemented.

It is quite annoying for authors to work around any known or unkown
bugs, gaps and deviations within implementations. This creates much
more confusion and frustration as to learn two quite different languages,
if there is at least the chance, that implementations behave predictable
as specified in each of them.
It causes frustration as well, if some feature is not available anymore,
because something was 'simplified' or 'optimised', just because those
'optimisers' or should I say 'pessimisers' did not understand, that the
previously specified things have their use cases ;o)

In this case, the CSS proposals just have to note, what is animatable
within the CSS approach. There is no conflict with SMIL and no
relation between the CSS transition and animation proposal and
the nasty attributeType derived from SMIL and only useful for SMIL
animation in some rare cases.
In the CSS proposal one can or should note of course, that this
approach is completely independent from SMIL animation, just to
avoid confusion for authors already familiar with the SMIL approach.

;o)

>How CSS Transitions and SMIL interact is another topic. It's worth
>discussing, but it needs a separate thread.

indeed, indeed.
I noted this already in a comment about the CSS proposals months
ago ;o)

[Jonathan Watt-3]

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.

>> 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.

>> 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.

Jonathan

[Dr. Olaf Hoffmann]

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

[Dean Jackson-7]

On 31/10/2009, at 11:22 PM, Jonathan Watt wrote:

>> 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.

I recently updated the CSS transitions specification to simply refer  
to SVG for the list of animatable properties. It was never the  
intention to produce a restricted set.

Dean

[Erik Dahlstrom]

On Fri, 30 Oct 2009 21:56:03 +0100, Robert O'Callahan  
<robert@...> wrote:

> On Sat, Oct 31, 2009 at 9:41 AM, Chris Lilley <chris@...> wrote:
>
>> On Friday, October 30, 2009, 8:56:18 PM, Robert wrote:
>>
>> ROC> For legacy compatibility reasons, we can't do this for
>> ROC> specifiedType="auto".
>>
>> Could you explain what legacy compatibility reasons mean that you can't  
>> do
>> this?
>
>
> It means that anyone who's using <animate attribute="height"> instantly
> breaks, because it would animate the 'height' CSS property which does
> nothing in SVG.

How about making the 'height' attribute a presentation attribute for  
SVG.next? I think it's possible to stay backwards compatible while adding  
the option of specifying the width/height through CSS.

Cheers
/Erik

--
Erik Dahlstrom, Core Technology Developer, Opera Software
Co-Chair, W3C SVG Working Group
Personal blog: http://my.opera.com/macdev_ed

[Dr. Olaf Hoffmann]

Erik Dahlstrom:
> How about making the 'height' attribute a presentation attribute for
> SVG.next? I think it's possible to stay backwards compatible while adding
> the option of specifying the width/height through CSS.
>
> Cheers
> /Erik

Because width and height are not essential, but more a decorative question
for an element in XHTML for example, it is a pretty good choice to
have this as property.
But for a rect element in SVG, width and height are the essential information
about what kind of rectangle we have, this is not decoration or styling or
presentation. Therefore I think, they should not be presentation attributes
or properties like fill. It would be similar to say the d attribute of path
should be only styling and decoration and the essential information is only,
that we have a path - not important, what kind of path ;o)
Of course, once started one has to continue the game: r of circle? rx, ry of
ellipse or rect? points of polyline and polygon? x1,x2,y1,y2 of a line? -
essential information or only presentation? ;o)


Olaf