W3C home > Mailing lists > Public > www-svg@w3.org > February 2007

Re: specificity, user style sheets and SVG

From: Jonathan Chetwynd <j.chetwynd@btinternet.com>
Date: Tue, 13 Feb 2007 07:53:05 +0000
Message-Id: <13A5520D-B924-4BC4-9E16-63B39F780293@btinternet.com>
Cc: "Dr. Olaf Hoffmann" <Dr.O.Hoffmann@gmx.de>, www-svg@w3.org
To: Chris Lilley <chris@w3.org>

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 GMT

This archive was generated by hypermail 2.3.1 : Friday, 8 March 2013 15:54:36 GMT