Re: specificity, user style sheets and SVG

Chris, Olaf and others,

Having started this thread, I'm having the greatest difficulty and in  
fact failing to understand the minutiae under discussion presently...

would it be possible to set up a test-suite or similar to disseminate  
this graphically?

This might help developers and others understand the issues, and  
produce better UAs

thanks

Jonathan Chetwynd



On 12 Feb 2007, at 19:34, Chris Lilley wrote:


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 Tuesday, 13 February 2007 07:53:15 UTC