- From: Dr. Olaf Hoffmann <Dr.O.Hoffmann@gmx.de>
- Date: Mon, 12 Feb 2007 19:09:37 +0100
- To: www-svg@w3.org
>The presentation attributes *are* used as CSS properties. SVG 1.1, 6.4: "For user agents that support CSS, the presentation attributes must be translated to corresponding CSS style rules according to rules described in section 6.4.4 of the CSS2 specification, Precedence of non-CSS presentational hints, with the additional clarification that the presentation attributes are conceptually inserted into a new author style sheet which is the first in the author style sheet collection. The presentation attributes thus will participate in the CSS2 cascade as if they were replaced by corresponding CSS style rules placed at the start of the author style sheet with a specificity of zero. In general, this means that the presentation attributes have lower priority than other CSS style rules specified in author style sheets or style attributes." If they are already CSS properties, there is no need to translate them to CSS. Anyway they are noted as XML and are therefore part of the content of the document. CSS is decoration and styling and as external stylesheet not part of the content of a document - for me this is a big difference just in the meaning, but not for the technical application. XML content should be accessible without styling as in XHTML. If author or user styling is needed to understand the content of a document, this is a low or zero quality document. Anyway styling is surely pretty useful in many situations anyway, but this is another question. >No, the animation is not affected by whatever rules in the cascade >were used to produce the static value. Additive animations depend on the underlying (static or animated) values. SMIL Animation 2001-09-04; 3.5. The animation sandwich model: "Specifically, animating an attribute defined in XML will modify the presentation value before it is passed through the style sheet cascade, using the XML DOM value as its base. Animating an attribute defined in a style sheet language will modify the presentation value passed through the remainder of the cascade. " and "... When animation is applied to CSS properties of a particular element, the base value to be animated is read using the (readonly) getComputedStyle() method on that element. 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). This means that the effect of animation overrides all style sheet rules, except for user rules with the !important property. " As far as I understand this, we have a first 'animation sandwich part' for the XML animation. Then we have to look what happens with the CSS 'animation sandwich part' - finally it is one sandwich, but this view is simpler to see the priorities. If there is a static CSS property this will overwrite the XML 'animation sandwich part' . If we have an additive CSS animation, this has the static CSS property as underlying value, if there is one, or the result from the XML 'animation sandwich part', if not. If in an user stylesheet !important is used for a property, this will overwrite again everything else, including animation. This means, user stylesheets used with !important have no influence on animation, because they will overwrite them. Author style sheets or user stylesheets (without !important) may have influence on the underlying value of an CSS animation, especially for additive animations. As an example: The author notes no static attribute or property for stroke-width, but the user provides one different than zero in his stylesheet (without !important). If in the document is an XML animation, this will be simply overwritten by the user value. With an additive animation of type CSS or auto, the animation has to take the user stylesheet value as the underlying value, resulting in a completely different animation as without a user stylesheet, then it would have been started with the default zero. If the animation is cumulative too, this will create a jump at any repetition. DOH> And because the default is auto, this means CSS if possible, we DOH> get in complicated situations with animation and CSS, too. Again DOH> authors have in most cases the choice to specify the DOH> attributeType XML >This leads me to suspect that you misunderstand the use of >attributeType. It only is of use where there is both a CSS property >(not expressed as a presentation attribute) and an SVG attribute >(which is not a presentation attribute) on the same element. If you think, this is a misunderstanding, then there seems to be the same misunderstanding in SMIL, I believe. If something is noted in XML syntax, it is in the related namespace. To build a cascade or sandwich, we can do this in the following way: - static XML value - XML animation sandwich - CSS property with specifity rules (except !important in user stylesheet) - CSS animation sandwich - !important in user stylesheet Therefore it is much easier to create a user stylesheet, if everything in the document is low specifity XML and authors CSS is moved in an external CSS file to be switched off somehow. If the document contains animation of the CSS type, this may cause some additional specifity, cascade or sandwich problems - however you like to call the SMIL surprises you may get.
Received on Monday, 12 February 2007 18:25:43 UTC