- From: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>
- Date: Mon, 29 Mar 2010 13:36:41 +0100
- To: public-fx@w3.org, www-svg@w3.org
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