Re: specificity, user style sheets and SVG

>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 

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. 
"... 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 

Received on Monday, 12 February 2007 18:25:43 UTC