- From: Cameron McCormack <cam@mcc.id.au>
- Date: Fri, 13 Jul 2007 16:00:51 +1000
- To: Sjoerd Mullender <sjoerd@acm.org>
- Cc: www-smil@w3.org, Cyril Concolato <cyril.concolato@enst.fr>, Bjoern Hoehrmann <derhoermi@gmx.net>, Patrick Schmitz <cogit@ludicrum.org>
Hi Sjoerd. Sjoerd Mullender: > Several people have reported in the past that there is a contradiction > in SMIL 2.0 (and 2.1) Animation with respect to the CSS OM. I am now > trying to address this issue, but I would like to get some feedback. > > But first my apologies that this took so long. Until recently there was > nobody within the Working Group really responsible for Animation. I am > now trying to resolve these old issues in preparation for the next > version of SMIL. > > The problem, as I understand it, is that in the Sandwich Model we say: > - the value on which the animation is to operate is read from the CSS OM > using getComputedStyle(); > - the new, computed value is written to the override style sheet in the > CSS OM. > > The problem with this is that getComputedStyle() (apparently -- I am not > a CSS expert) takes the override style sheet into account, and thus > there is at the very least confusion, and quite possibly a > contradiction, with the possible result that animations are applied more > than once. Yes that’s correct. > This is of course not the intention. SMIL Animations should be applied > once, so we should fix the text to make that clear(er). Of course, we > should keep in mind that the relevant text is all only informative. > > The current text says: > > "When animation is applied to CSS properties of a particular element, > the base value to be animated is read using the (readonly) > getComputedStyle() method on that element. The values produced by the > animation are written into an override stylesheet for that element, > which may be obtained using the getOverrideStyle() method." > > My proposal is to tack a sentence on to this: > > "Note that it is assumed that before reading the value, the override > stylesheet is cleared so that the animation works on the original > document value." > > My question to the various reporters (and others): would this be > sufficient to resolve the issue? It would resolve the issue, but isn’t ideal since you wouldn’t want to remove the styles for other properties that the author’s script has inserted into the override style sheet. How about, for the whole paragraph: In CSS 2 and the DOM 2 CSS OM, the terms “specified”, “computed” and “actual” are used to describe the result of performing the cascade, resolving relative values and applying any user agent specific approximations for a given property, respectively. When an animation targets a CSS property of a particular element, the base value is given by the computed value of the property, ignoring the effect of any override style sheets. The values produced by the animation are written into an override style sheet for that element. Thus, one way an implementation may effect CSS property animations is by first removing any rule corresponding to the property in the element’s override style sheet (obtained via the DocumentCSS.getOverrideStyle() method), reading the current base value from the style sheet returned from ViewCSS.getComputedStyle(), then writing a new rule into the element’s override style sheet assigning the property the animated value. Why is this text informative, though? Is there any normative text that states how CSS properties are meant to be animated? Would it be acceptable for a user agent to instead, say, have a new “animation” origin that the CSS engine must implement, and give it a higher precedence in the cascade than author style sheets? Thanks, Cameron -- Cameron McCormack, http://mcc.id.au/ xmpp:heycam@jabber.org ▪ ICQ 26955922 ▪ MSN cam@mcc.id.au
Received on Friday, 13 July 2007 13:58:33 UTC