[SVG Tiny 1.2 CR Comment] SMIL Animation and Property Inheritance

Dear  SVG experts or non-experts,

This mail can be considered as a feedback from implementation.

I'd like to submit an example and my interpretation of it from the 
reading of the SVG, SMIL and CSS specs. This reading raises a number of 
issues which cause non-interoperability in existing SVG implementations. 
At the end of this (long) email, you will find my proposals to clarify 
the specs.

Here is the (very simple) example:
<svg viewBox="0 0 1000 1000" xmlns="http://www.w3.org/2000/svg" 
version="1.2" baseProfile="tiny" 
xmlns:xlink="http://www.w3.org/1999/xlink">
 <g id="g1" fill="red">
   <g id="g2" fill="green">
     <animateColor id="a1" attributeName="fill" from="inherit" to="blue" 
dur="5" begin="1" additive="replace" accumulate="none" fill="freeze"/>
     <rect id="r1" fill="inherit" width="100" height="100" x="200" 
y="200"/>
   </g>     </g>    </svg>

According to the CSS specification 
(http://www.w3.org/TR/REC-CSS2/cascade.html#q1):
    "Once a user agent has parsed a document and constructed a document 
tree, it must assign, for every element in the tree, a value to every 
property that applies to the target media type."
For simplicity, let's assume there is only one property 'fill', and no 
external stylesheet attached (author, user, and user agent). Let's 
compute the "specified value" for the property 'fill' on each element.

Element: root
First we do the cascade, according to Section 6.4.1 
(http://www.w3.org/TR/REC-CSS2/cascade.html#cascading-order), which does 
not return a value.
Then CSS specification says "Otherwise, if the property is inherited 
...". How do I know if it is inherited since I don't have a value 
assigned? I think it should read "Otherwise, if the property is 
inheritable and has no value or has the value 'inherit'".
Assuming I'm right. The 'fill' property is inheritable according to the 
SVG specification 
(http://www.w3.org/TR/SVGMobile12/painting.html#propdef-fill). But since 
there is no parent element, we use the note in the CSS specification:
"Since it has no parent, the root of the document tree cannot use values 
from the parent element; in this case, the initial value is used if 
necessary."
So we use the initial value which is "black" according to SVG.
Result: The specified value for the property 'fill' on the root svg 
element is 'black'. Since this value is absolute, the computed value is 
also 'black'.

Element: g1
According to the SVG 1.1 specification, in 
http://www.w3.org/TR/SVG/styling.html#StylingPropertyInheritance, "the 
presentation attributes are conceptually inserted into a new author 
style sheet which is the first in the author style sheet collection". As 
a side note, this part is missing from the SVG 1.2 Tiny Specification.
So we have one style rule which allows the cascade to return a value. 
The specified value for the 'fill' property on g1 is then 'red'. Since 
it's an absolute value, the computed value for g1 is 'red'.

Element g2:
Before the animation starts, the reasoning is the same as for g1, so the 
specified value is 'green' and the computed value is also 'green'.

Now, when the document time is greater than 1, the animation is active.

According to SMIL Animation sandwich model 
(http://www.w3.org/TR/SMIL/animation.html#animationNS-AnimationSandwichModel), 
the specified value is unaffected by the animation since "The effect of 
animations is [...] not to affect the underlying DOM or CSS OM values". 
The specified value stays 'green'.

The 'base value' for the animation is retrieved "using the (readonly) 
getComputedStyle() method on that [target] element", which returns, 
according to DOM Level 2 CSS 
(http://www.w3.org/TR/DOM-Level-2-Style/css.html), 'the computed value'. 
In this case, 'green'.
So the animation starts with the base value 'green'.

The fill property is of type '<paint>' according to the SVG 
specification 
(http://www.w3.org/TR/SVGMobile12/painting.html#SpecifyingPaint), so 
according to the table given in 
http://www.w3.org/TR/SVGMobile12/animate.html#AnimationAttributesAndProperties, 
to decide if the interpolation can be done, one must decide if the 
'from' value 'inherit' can be converted to an RGB value.

Is the inherited value retrieved to do that, or do we decide that 
'inherit' is a keyword which cannot be converted to RGB? It's not clear.

We pick the first interpretation. So the inherited value must be 
retrieved. There is no restriction for the 'fill' property, so it 
inherits the computed value of the parent element, since "most elements 
inherit computed values". Here the parent of the target element is g1, 
the inherited value is therefore 'red'.

Since 'red' and the 'to' value 'blue' can be converted to RGB, the 
interpolation can happen. Let's say it produces a value 'red-blue'. 
Since the 'additive' attribute is 'replace', the base value is not used.

So this result, according to SMIL, is the "presentation value" which is 
'written into an override stylesheet' and is 'reflected in a new 
computed value'. The new computed value for g2 is then 'red-blue', 
depending on document time.

Element r1:
The 'fill' presentation attribute is specified so the cascade result in 
the specified value being the computed value of the parent element, here 
the value is 'green' 'red-blue'.

Summary:
The display should therefore show: a 'green' rectangle between 0 and 1, 
then a interpolation from 'red' to 'blue' during 5 seconds and a blue 
rectangle indefinitely after that.

Now a question, is this reasoning correct?

I tested with the available SVG PC players and the results are the 
following:
 Adobe SVG Viewer 3.0 and 6.0 show a green, then a red and then a blue 
rectangle. No interpolation is performed.
 eSVG version 2.4 shows a green rectangle, then an interpolation between 
black and blue, then it keeps showing the blue rectangle.
 Renesis 0.1 shows some yellowish rectangle not animated.
 Opera 9 and GPAC/Osmo4 show the same behavior that I described.
 Batik and Firefox 1.5.0.6 do not implement animations. I couldn't test 
mobile implementations.

This shows that the usage of CSS Inheritance, SMIL Animations and SVG 
graphics together is not currently interoperably implemented because the 
specifications (CSS, SMIL and SVG) are not clear, in many places, and 
people have to interpret them.

Here are my proposed changes to improve the specifications.
* Proposed changes to the CSS specification:
--------------------------------------------
   - Modify "6.1.1 Specified values" as follows:
"User agents must first assign a specified value to a property based on 
the following mechanisms (in order of precedence):
  1. If the cascade results in a value, *and this value is not 
'inherit',* use it.
  2. Otherwise, if the property is *inheritable (Each property defines 
whether it is inheritable or not using 'inherited: yes' in the 
property's definition) and the element has a parent and either the 
property has no value resulting from the cascade or has a value of 
'inherit', then use the computed or specified value of the parent 
element, as indicated in the property's definition. If no indication is 
given, use the computed value.*
  3. Otherwise use the property's initial value. The initial value of 
each property is indicated in the property's definition."

   - Move the last paragraph of "6.1.2 Computed values" to the end of 
the above section.
      - Delete section "6.2 Inheritance" and change the link 'inherited' 
in section 6.1.1 to point to the definition of 'inherited' 
("http://www.w3.org/TR/REC-CSS2/about.html#q9") because this section 6.2 
has no normative statement and contains wrong or confusing statements 
(see below).
   - Or, at least make section 6.2 informative since it gives only 
examples and remove the sentences:
   "Specified percentage values are not inherited; computed values are." 
because computed values are not always inherited.
   "Each property may also have a specified value of 'inherit', which 
means that, for a given element, the property takes the same computed 
value as the property for the element's parent." because a) it implies 
that all properties are inheritable and b) it implies again that the 
computed value is always inherited.
   * Proposed changes to the SMIL Animation specification:
-------------------------------------------------------
A) Typo:
"The animation effect function  of an element is the function which 
includes the affect of the underlying value and accounts for repeating 
and freezing of the element."
should read:
"The animation effect function  of an element is the function which 
includes the _effect_ of the underlying value and accounts for repeating 
and freezing of the element. "

B) The following sentences from the animation sandwich model are at best 
confusing, if not contradictory. They should be clarified.

"The remainder of this discussion uses the generic term OM for both the 
XML DOM [DOM2] as well as the CSS-OM."
and
"Note that animations manipulate the presentation value coming out of 
the OM in which the attribute is defined, and pass the resulting value 
on to the next layer of document processing. This does not replace or 
override any of the normal document OM processing cascade. "
and
"The values produced by the animation are written into an override 
stylesheet for that element, which may be obtained using the 
getOverrideStyle() method. These new values then affect the cascade and 
are reflected in a new computed value (and thus, modified presentation)."

Saying in one sentence that the presentation value does not override the 
OM value and, in the other sentence, saying that it is obtained using a 
function named 'override' is confusing. Then saying that the 
presentation value affects the cascade while the first sentence says 
that it does not override the normal document cascade is also confusing. 
Then, I could not find a definition of CSS OM value, is it the CSS 
specified value ? Please use defined terminology and link terms to their 
definition.

C) For properties, the specification seems to say that the base value is 
the computed value ("is read using the (readonly) getComputedStyle() 
method"), but it also says that the result of the animation, the 
presentation value, becomes the new computed value ("reflected in a new 
computed value"). This looks like the result of the animation is 
modifying the input of the animation. If true, for additive animations, 
depending on the number of evaluations of the animation, one could get 
different result. I don't think this is what is wanted here. These 
sentences are confusing. I think it should say that "the new computed 
value" is only used for display, or by other animations, or for 
inheritance, but it should say that for the next computation of this 
animation the getComputeStyle function will not return that "new 
computed value" but will reevaluate the computed value as if that 
animation had not happen.

E) The main problem with the way animation and inheritance is described 
is that the text is spread over several specifications (DOM Core, DOM 
CSS, DOM View, CSS, SMIL). It is really is a big challenge to understand 
it. I'm not sure I understand it even after having read all of them and 
implemented (most of it). It would help if algorithms in pseudo-code 
were given for attributes and for properties.

* Proposed changes to the SVG specification:
--------------------------------------------
If the CSS and the SMIL specifications are clarified, there should not 
be much to fix in the SVG specification.
The missing parts about "presentation attributes" from the SVG 1.1 spec 
should be added to the SVG 1.2 Tiny spec though.

Then, it should be made clearer :
- that CSS defines a two-steps algorithm to get the final property value 
used for display divided into:
   - the retrieval of the 'specified value', which cannot be 'inherit', 
and is retrieved by a three step process composed of:
       - the cascade step, i.e. the algorithm to get a value from one of 
the stylesheets (author, user, user agent),
       - followed if no value is returned or if the keyword 'inherit' is 
returned, and if the property is inheritable and the current element has 
a parent, by the inheritance mechanism (i.e. the replacement of 
'inherit' by one of the parent value (specified or computed))
       - followed if no value is assigned by the defaulting behavior 
(usage of initial value)
   - followed by the creation of the computed value
 - that when presentation attributes are specified in the SVG document,
     - either they are, in user-agents supporting the use of 
stylesheets, taken into account in the cascade step as a particular 
stylesheet with some level of precedence;
     - or they are taken as the result of the cascade step in 
user-agents not supporting the use of stylesheets.
 - and that the rest of the CSS algorithm applies in both types of 
user-agents.

It should be also clarified if or not 'inherit' keywords are converted 
into inherited values (parent computed value or parent specified value) 
to determine if the animation can be additive or not. And if they are 
converted, that the parent is determined based on the location of the 
target (as implemented in many viewers) and not on the location of the 
animation element.

Best regards,

Cyril

Received on Sunday, 3 September 2006 08:11:34 UTC