- From: Cyril Concolato <cyril.concolato@enst.fr>
- Date: Sun, 03 Sep 2006 10:11:14 +0200
- To: www-svg@w3.org
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