Re: specificity, user style sheets and SVG

On Monday, February 12, 2007, 7:09:37 PM, Dr. wrote:

>>The presentation attributes *are* used as CSS properties.

DOH> SVG 1.1, 6.4:
DOH> "For user agents that support CSS, the presentation attributes must be
DOH> translated to corresponding CSS style rules according to rules described in
DOH> section 6.4.4 of the CSS2 specification, Precedence of non-CSS presentational
DOH> hints, with the additional clarification that the presentation attributes are
DOH> conceptually inserted into a new author style sheet which is the first in the
DOH> author style sheet collection. The presentation attributes thus will 
DOH> participate in the CSS2 cascade as if they were replaced by corresponding CSS
DOH> style rules placed at the start of the author style sheet with a specificity
DOH> of zero. In general, this means that the presentation attributes have lower
DOH> priority than other CSS style rules specified in author style sheets or style
DOH> attributes."

DOH> If they are already CSS properties, there is no need to translate them
DOH> to CSS.

I fact there is, as the text that you quote makes clear. They have to
be given a specificity of zero and the position of the virtual style
sheet in which they are considered to occur also needs to be stated.


DOH>  Anyway they are noted as XML and are therefore part of the content
DOH> of the document.

Yes, clearly they are part of the document. They can also be
overridden.

DOH>  CSS is decoration and styling and as external stylesheet
DOH> not part of the content of a document

Clearly that can be contained in the document  too - as style
attributes or as content of the style element - as well as being
outside the document (although, still pointed to by a style PI).

DOH> - for me this is a big difference just
DOH> in the meaning, but not for the technical application. XML content should be
DOH> accessible without styling as in XHTML.

A statement that is partly applicable to HTML (though I understand the
context in which the statement was first proposed, it has been widely
quoted out of that context), but not applicable to SVG.

DOH>  If author or user styling is 
DOH> needed to understand the content of a document, this is a low or 
DOH> zero quality document.

I think a document in which every shape was opaque black would be a
pretty poor one as well. This is why the presentation attributes have
specificity zero - they provide a usable view of the document, but one
which can be easily restyled. (As opposed to style attributes, still
unfortunately generated by many authoring tools, which have a
specificity of 100 in CSS2 and 1000 in CSS 2.1).

DOH> Anyway styling is surely pretty useful in many
DOH> 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.

DOH> Additive animations depend on the underlying (static or animated) values.

Yes. Which can come from the external style sheet.

DOH> SMIL Animation 2001-09-04; 3.5. The animation sandwich model:

DOH> "... When animation is applied to CSS properties of a particular
DOH> element, the base value to be animated is read using the
DOH> (readonly) getComputedStyle() method on that element.

Which will compute the style, based on all the style rules which apply
to that element. Not just the presentation attributes.

DOH>  The values
DOH> produced by the animation are written into an override stylesheet
DOH> for that element, which may be obtained using the
DOH> getOverrideStyle() method. These new values then affect the
DOH> cascade and are reflected in a new computed value (and thus,
DOH> modified presentation). This means that the effect of animation
DOH> overrides all style sheet rules, except for user rules with the
DOH> !important property. "

Yes.

DOH> As far as I understand this, we have a first 'animation sandwich part' for the
DOH> XML animation. Then we have to look what happens with the 
DOH> CSS 'animation sandwich part' - finally it is one sandwich, but this view is
DOH> simpler to see the priorities.
DOH> If there is a static CSS property this will overwrite the XML 'animation
DOH> sandwich part' .

The SMIL spec presents these as either/or choice, not as a sequence.


DOH> If in an user stylesheet !important is used for a property, this will
DOH> overwrite again everything else, including animation.

DOH> This means, user stylesheets used with !important have
DOH> no influence on animation, because they will overwrite them.

(Those two statements seem to me to be contradictory).

DOH> Author style sheets or user stylesheets (without !important)
DOH> may have influence on the underlying value of an CSS animation,

Yes

DOH> especially for additive animations.
DOH> As an example: The author notes no static attribute or property for
DOH> stroke-width, but the user provides one different than zero in his 
DOH> stylesheet (without !important).

OK, so the cascade gives that property a value. This is independent of
whether animation is taking place.

DOH> If in the document is an XML animation, this will be simply overwritten
DOH> by the user value.

No. You are using the attributeType to give two different processing
models on the same property. it doesn't do that. It just allows
disambiguation in case of a property/attribute clash. Which is why the
default value is "auto" because most of the time ther eris no
ambiguity.

DOH>  With an additive animation of type CSS or auto,
DOH> the animation has to take the user stylesheet value as the underlying
DOH> value, resulting in a completely different animation

Yes.


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

DOH> If you think, this is a misunderstanding, then there seems to be
DOH> the same misunderstanding in SMIL, I believe.

No, I don't believe so.

DOH>  If something is
DOH> noted in XML syntax, it is in the related namespace.

No. (Namespaces have nothing to do with this).

DOH> To build a cascade or sandwich, we can do this in the following way:

DOH> - static XML value
DOH> - XML animation sandwich
DOH> - CSS property with specifity rules (except !important in user stylesheet)
DOH> - CSS animation sandwich
DOH> - !important in user stylesheet

That is incorrect. Its an either/or choice, not a sequence.

DOH> Therefore it is much easier to create a user stylesheet, if
DOH> everything in the document is low specifity XML and authors CSS
DOH> is moved in an external CSS file to be switched off somehow. If
DOH> the document contains animation of the CSS type, this may cause
DOH> some additional specifity, cascade or sandwich problems - however
DOH> you like to call the SMIL surprises you may get.

Its not really a surprise. Its that the user has chosen to modify some
of the styling.



-- 
 Chris Lilley                    mailto:chris@w3.org
 Interaction Domain Leader
 Co-Chair, W3C SVG Working Group
 W3C Graphics Activity Lead
 Co-Chair, W3C Hypertext CG

Received on Monday, 12 February 2007 19:34:59 UTC