W3C home > Mailing lists > Public > www-svg@w3.org > September 2006

Re: [SVG Tiny 1.2 CR Comment] SMIL Animation and Property Inheritance

From: Bjoern Hoehrmann <derhoermi@gmx.net>
Date: Tue, 05 Sep 2006 06:14:15 +0200
To: Cyril Concolato <cyril.concolato@enst.fr>
Cc: www-svg@w3.org
Message-ID: <borpf2hf43ng51k56e1b1lh7e5tcho619f@hive.bjoern.hoehrmann.de>

* Cyril Concolato wrote:
>Here is the (very simple) example:
><svg viewBox="0 0 1000 1000" xmlns="http://www.w3.org/2000/svg" 
>version="1.2" baseProfile="tiny" 
>xmlns:xlink="http://www.w3.org/1999/xlink">
> <g id="g1" fill="red">
>   <g id="g2" fill="green">
>     <animateColor id="a1" attributeName="fill" from="inherit" to="blue" 
>dur="5" begin="1" additive="replace" accumulate="none" fill="freeze"/>
>     <rect id="r1" fill="inherit" width="100" height="100" x="200" 
>y="200"/>
>   </g>     </g>    </svg>

As far as your animateColor element goes, this issue is a duplicate of
http://lists.w3.org/Archives/Public/www-svg/2006Aug/0112 which is just
a duplicate of SVGT12-282. The Working Group resolved that issue and
The Director agreed with the resolution. You are correct in that the
specification does not define processing of your example, but the group
is incapable of understanding that.

As for the rest of your analysis, you should look at CSS 2.1, not CSS
2.0; it seems to me that this would help to understand some of the
issues you raise. If you remove the animateColor element from your ex-
ample, processing of the document is well-defined as far as CSS goes,
and as far as I can see.

There are only two ways to process the animateColor element above with-
out adding considerable complexity to both the specifications and the
implementation, you either consider the case to be in error, or you im-
ply calcMode='discrete'.

>* Proposed changes to the CSS specification:

I would appreciate if you could review the relevant parts of the CSS
2.1 specification and, if you still think changes are required, post
the change requests to the www-style mailing list, as explained in the
SotD section of the draft.

>   * Proposed changes to the SMIL Animation specification:

To www-smil, please.

>Saying in one sentence that the presentation value does not override the 
>OM value and, in the other sentence, saying that it is obtained using a 
>function named 'override' is confusing. Then saying that the 
>presentation value affects the cascade while the first sentence says 
>that it does not override the normal document cascade is also confusing. 
>Then, I could not find a definition of CSS OM value, is it the CSS 
>specified value ? Please use defined terminology and link terms to their 
>definition.

There is an actual contradiction here, I reported this in

  http://lists.w3.org/Archives/Public/www-smil/2005OctDec/0027

which was later repeated by Cameron McCormack

  http://lists.w3.org/Archives/Public/www-smil/2006JanMar/0017

>It should be also clarified if or not 'inherit' keywords are converted 
>into inherited values (parent computed value or parent specified value) 
>to determine if the animation can be additive or not. And if they are 
>converted, that the parent is determined based on the location of the 
>target (as implemented in many viewers) and not on the location of the 
>animation element.

You would also have to define when you obtain the values, what happens
if they change (consider in your example above what happens if you <set>
the fill to some other value, how is that reflected? Or what if the 
inherit keyword is in the to='' attribute and you have a <set> as be-
fore, or what if you have from='inherit' to='inherit' and change the
fill attribute on an ancestor), what if the animations repeat or pause
and the values change, and so on. currentColor is a worse case here, as
you then have to look at multiple properties!

Could you say whether and if how much your implementation could be
simplified if calcMode='discrete' would be implied in the case above?
You would then simply write 'inherit' into the override style sheet
and not try to retrieve any RGB value to interpolate from.
-- 
Björn Höhrmann · mailto:bjoern@hoehrmann.de · http://bjoern.hoehrmann.de
Weinh. Str. 22 · Telefon: +49(0)621/4309674 · http://www.bjoernsworld.de
68309 Mannheim · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/ 
Received on Tuesday, 5 September 2006 04:40:57 GMT

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