Re: SVG Presentational Attributes, attributeType="CSS" vs "XML": same or different?

Daniel Holbert:
> Thanks for the feedback! I think I think I agree that Opera's behavior
> is the most sane and is what was probably intended.  At this point,
> that's the behavior I'll be shooting for with my patch for Mozilla.
> However, I still think that both SVG 1.1 & SVG 1.2Tiny are misleading on
> this point and need additional clarification.  Details below...

I think, concerning this issue, what is mentioned is not sufficient to
overwrite the SMIL sandwich model or specifity rules from CSS, 
for this SVG would need to rewrite the complete models (SMIL and
CSS, not a useful approach).
Therefore I think instead of adding even more misleading 
an arbitrarily paragraphs, SVG should point only to SMIL.

As far as I understand this and what Chris Lilley mentioned
several times about this drama, is that originally it was intended
to do it simpler in SMIL, but finally obviously this simpler idea did 
not survive the review process for the original SMIL animation
recommendation, but some misleading residuals from the simpler 
idea remained in SVG (or in the SVG group) - this seems to be
the origin of some confusion.

Additional complications appear due to some delicate passages
in different versions.

SVG mobile 1.1 notes:
'' 5. Styling 

SVGB and SVGT support subsets of SVG 1.1's presentation attributes. 

SVGB allows optional support of CSS Mobile Profile 1.0. SVGT does not support 
styling with CSS.
Well - if we keep it simple, this means ignore all CSS, if the document 
identifies itself as SVGT 1.1, including animations with attributeType CSS -
obviously it cannot have a visible effect to animate a CSS property, if
there is not CSS support allowed. Authors should never use attributeType CSS
within SVG tiny 1.1 documents (however implementors of more than the tiny
profile try to implement this).

For SVG basic 1.1 support is optional - what basically means, you can
implement what you want and authors should never use attributeType CSS 
to get something predictable.

SVG tiny 1.2 notes, that support for external style sheets is optional or not 
required. Animation with attributeType CSS is not external style, else 
internal styling is not available in SVG tiny 1.2. My interpretation is, that
authors can use attributeType CSS with the expectation of a predictable
effect as defined in the SMIL sandwich model. This is still much simpler
than the behaviour for SVG 1.1, as long as the viewer does not start to
interprete optional external stylesheets.

Because your example does not indicate any version, one 
cannot say, which behaviour is correct. It depends on what the viewer
believes, that the 'current version' is and what is maybe interpreted
optionally or not.
I know, that typically there is no implementation of different versions
of SVG or another format in one viewer. However, for the disscussion,
what is a correct or incorrect implementation/interpretation, such a 
version indication for a test is essential.

Assuming SVG 1.1 applies, this is my interpretation:
a) from rgb(200,0,0) to rgb(200,200,0) (frozen) 
b) from 8px to 18px (frozen)
c) initially rgb(200,0,0), finally "rgb(0,200,0)" (frozen)
    (did no calculations what happens between, I think,
     there should be something visible from the XML animation.
     Such more complex to-animations have the tendency to be
     wrong in Opera and other viewers. The result from the
     combination of the static value and the XML animation is
     the time dependent current value 'vcur' for the CSS to-animation 
     for the formula:  f(t) = vcur + ((vto - vcur) * (t/d)), see SMIL)
d) same as c)
e) only rgb(200,0,0), no visible effect from animation, because
CSS notes, that presentation attributes have a low specifity compared
to properties noted in style attributes.
f) from rgb(200,0,0) to rgb(0,200,0) (frozen)
g) from rgb(200,0,0) to rgb(0,0,200) (frozen)
h) from rgb(200,0,0) to rgb(0,200,0) (frozen)

About e) and f) - the animation function itself is calculated in the
same way, some affine interpolation between the current value and
the to-value.
Because there is no attribute value available in e), this is an interpolation
between the current implicated value black and the to-value rgb(0,0,200).
Because there is a property specified, this has no visible effect, however.
This is similar to the situation with having a higher priority set animation
on top. The animation takes place anyway, but has no visible effect.
For f) the current value is rgb(200,0,0) (not time dependent) 
and the to-value rgb(0,200,0), therefore the result is in this case a
visible effect of an affine interpolation. You did not note 'the same'
animation, therefore the result is different.
Note, that the visible results from c) and d) are no affine interpolations,
because the current value is time dependent, the visible result in these 
cases is effectively a quadratic interpolation.

However, for the case of SVG 1.1 for my interpretations there are
two core rules, which are needed to get a predictable result, the
SMIL sandwich model and the applicable rule from CSS, that
presentation attributes have a lower specifity than CSS properties.

Because attributeType XML animates a (presentation) attribute,
both the static value and the result of such an XML attribute have
low specifity compared to applicable CSS properties. Therefore
a CSS property in a style element or attribute or within an
external stylesheet has to overwrite this (animated) presentation 
attribute due to the CSS rule (stupid for people using still the
style attribute, but this is bad practice anyway and is worth to be
punished ;o)
If there is no (static) value somehow derived from some CSS
source to overwrite the (animated) presentation attribute, this
can be the underlying value for animations of the attributeType

To get this issue even more delicate, there is a draft for 
CSS animations (and transitions) now. How does this fit
into these rules? It does not mention itself, how this fits into the
SMIL sandwich model, therefore we have to derive it from
what is already written.

Such an animated or transitioned property is derived from an 
external stylesheet or from something noted within the style 
element. Therefore it overwrites the (animated) presentation 
attribute and can be the underlying value for animations of the 
attributeType CSS.
Because currently CSS animations cannot be additive, 
this simplifies the situation a little bit. However transitions
depend on the 'underlying' value somehow, therefore
for transitions authors can indeed note some funny
'brainfuck' with three different types of animations having
an effect on the final presentation at a specific time:
Starting with an explicitly set presentation attribute, 
having an additive SMIL animation of this presentation attribute,
doing a transition on this and adding an additive SMIL animation
of the attributeType CSS on top of is.  I think, nobody 
with sanity and reason will do this intentionally without
wanting to test proper implementation - however it seems to
apply ;o)

> I disagree -- in some situations, Opera (which you say is most correct)
> yields an unquestionably different effect, regardless of what you define
> "effect" to mean.

I did not claim, that I understand everything, what happens
in current Opera versions (for several issues the opposite applies ;o)
My statement was just about a statistical observation.
For example derived from my test suite one gets a probability
of correct display of an random choice animation for SVG 1.1
for Opera 10.0 of 0.53 +- 0.027 or for Opera10.0 alpha it is 
0.54 +- 0.027
Therefore still about 50 percent will be surprising, a larger amount
of surprises for other versions or other viewers, I tested ;o) 

For more complex animation situations (typically the wrong 50 percent)
there is no relyable viewer available to me - or it depends on the
tested issue of course.
However, for your tests the final results fit to my interpretation.

Received on Saturday, 23 January 2010 14:31:18 UTC