Re: Some thoughts on css transforms in svg

Sorry for the 'holidelayed' answer...

Dean Jackson:
> On 13/03/2010, at 7:21 AM, Dr. Olaf Hoffmann wrote:
> > Dean Jackson:
> >> On 12/03/2010, at 11:36 PM, Dr. Olaf Hoffmann wrote:
> >>> Especially for animation the CSS-draft is
> >>> pretty incompatible to SVG/SMIL due to this
> >>> decomposition.
> >>> And a SMIL animation is always performed on
> >>> the provides values.
> >>
> >> SVG animation does not go into detail about how to calculate the
> >> interpolation for a complex type like matrix. I would argue that the
> >> decomposition approach in CSS is just as valid as any other.
> >
> > For SVG the details about interpolation are always defined in SMIL,
> > not in SVG (there are only a few exceptions), therefore one cannot
> > derive a proper animation behaviour from the SVG recommendations alone.
>
> I know. My point is that even SMIL does not say how the interpolation
> calculation is performed on complex types, such as transform (*). 

I think, there is no need to mention this explicitly, as long as those types
are only vectors or lists of numbers. It it obvious, how to interpolate such
simple types with the exception of paced animation (for them indeed one
has to do more, but this is mentioned in SMIL).

Even for transform currently one has finally only something like:
values="1,2;-1,1;2,1" - a simple list or a vector with obvious interpolation
rules, what would apply for a list representing a matrix as well. This
is one of the advantages of SMIL, that it is very generic and there is
finally in most cases no need to define more details. Well, in some cases it
may help implementors and authors to clarify, what is already defined,
what is for example the case in SVG tiny 1.2 for paced animation of
complex types, especially because it was mentioned wrong for transform
in SVG 1.1. Most of it is directly derived from SMIL and not really
a specific rule.

For other even more complex types like path data indeed something
more is required, this will be obviously true for something like:
values="rotate(20,12,13);scale(-1,1);skewX(17)"
Currently this problem does not exist except for to-animations.

Even for the even more complex properties fill and stroke with
colors, paint-servers and the value 'none' one can already 
derive the correct interpolation from SMIL. The calcMode
is discrete, if the values-list contains something different than
simple colors.
 

> It tells 
> you how to derive the "progress" along the timing function, but does not
> tell you what algorithm to use between two values.
>
> (*) the exceptions are animateColor, which says it is on a per-component
> basis, and path animation.

I think, for animation of colors it is mainly mentioned to explain that
a paced animations uses the Euclidian distance in the 3D-color space.
It is required too, because you can note something like 
values="#abc;rgb(12,34;56);#abcdef;rgb(12%,34%;56%);blue",
what is much more complex than a list of numbers.
After reduction to values in a 3D-color space it is basically an example how 
to interpolate lists of numbers in general and there is no specific rule
anymore required.

>
> Therefore, matrix decomposition is just as valid as interpolating the
> matrix components.

For values="matrix(1,2,3,4,5,6);matrix(6,5,4,3,2,1)" not for
values="1,2,3,4,5,6;6,5,4,3,2,1", it depends basically only on what
is noted within the values attribute. This is a nice trick for the
current behaviour of animateTransform. Because only numbers
are noted into values, there is no need for a specific rule.
Unfortunately there is no type matrix to animate (I think, Opera
does it anyway in some versions ;o)

....
>
> You missed my points.
>
> 1. Without any new stylesheets applied that override the transform on
> existing SVG content, nothing will change.
>

ok, sounds good

> 2. SMIL animation of SVG transforms is restricted to animateTransform,
> which is always separated by component. This is not incompatible with CSS.
>

Just to clarify this idea:
In the future we will have both an applicable transform property and the old
transform attribute. 
The transform attribute is animated with animateTransform as already 
available and the transform property? Is it animatable in the SMIL sense
at all? If applicable for SVG, this has to be defined as for any other 
property. If yes - only with animate and set?
Then it would be compatible, but still confusing for authors due to the name
clash.
The general approach would however be close to what I already proposed -
to separate these two features strictly. A new name would avoid confusion and
the name clash.
And still there is a need to define the final effect, if both an
animateTransform and animate for the transform property apply to one element.

....
>
> No.
>
> #some-element {
>   transform: translate() scale() rotate();
>   transform: translate3d() scale3d() rotate3d();
> }
>
> The first rule is accepted in all viewers. The second rule fails if you
> don't do 3d, and you fall back to the first rule. Also, you'd probably
> separate by media queries, to make the code more readable.
>

Does this mean, that only CSS syntax is applicable as for example for
the property font? But font can be decomposed in several properties,
all available as presentations attributes...
Typically I mainly use attribute syntax and recommend to avoid
the style attribute. CSS syntax can be pretty useful in some cases
within the style element or with external stylesheets. However 
I think for several SVG-viewers, interpretation of external stylesheets
still needs to be implemented (even for some XHTML-viewers, if processing
instructions are used ;o) - therefore attribute syntax is more reliable
and not just optional decoration for SVG.

> Compare to your suggestion:
>
> <rect id="some-element" transform="translate() scale() rotate()"
> transform2d="translate() scale() rotate()" transform3d="translate3d()
> scale3d() rotate3d()">
>

Well, looks simple for authors with a low risk to get lost in different
files or different areas of the document for beginners.
Did you follow the 'HTML5' discussions about non-local effects
like namespaces, profiles, metainformation etc?
If they already think, that authors are not clever enough to 
manage this, there should be never more than only decorative
aspects in external stylesheets or within the style element within
the top defs element ;o)
I think, many authors are clever enough to manage distributed
information, however for beginners there should be at least an
option to keep most applicable and basic things locally within
the tag it applies to.

Olaf

Received on Monday, 29 March 2010 12:39:02 UTC