W3C home > Mailing lists > Public > www-smil@w3.org > July to September 2007

Re: SMIL Animation and CSS OM

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>
Message-ID: <20070713060051.GA17152@arc.mcc.id.au>

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
> 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?



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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:34:27 UTC