W3C home > Mailing lists > Public > www-style@w3.org > January 2012

RE: [css3-animations] Override of animation rule by !important

From: Sylvain Galineau <sylvaing@microsoft.com>
Date: Tue, 24 Jan 2012 03:48:53 +0000
To: Øyvind Stenhaug <oyvinds@opera.com>, "www-style@w3.org" <www-style@w3.org>
Message-ID: <3C4041FF83E1E04A986B6DC50F0178290341B0C4@TK5EX14MBXC295.redmond.corp.microsoft.com>

[Øyvind Stenhaug:] 
> On Fri, 20 Jan 2012 17:14:18 +0100, Sylvain Galineau
> <sylvaing@microsoft.com> wrote:
> 
> >
> > [Øyvind Stenhaug:]
> >>
> >> On Fri, 20 Jan 2012 01:01:51 +0100, Sylvain Galineau
> >> <sylvaing@microsoft.com> wrote:
> 
> >> > - Does the :hover transition starts from whatever intermediate value
> >> > was last applied by colorChange?
> >>
> >> I'm not sure, but presumably it should act the same as if the animation
> >> were removed while in progress. If there is a transition, it should
> >> probably start from the intermediate value. But maybe there shouldn't
> >> be a
> >> transition at all.
> >>
> >> > - What happens when the user hovers away? Transitioning back to a
> >> > moving target is not easy nor is it clearly desirable. Nor would a
> >> > reversal look appropriate.
> >>
> >> The current Transitions draft says that "[i]mplementations must not
> >> start
> >> a transition when the computed value of a property changes as a result
> >> of
> >> declarative animation". This seems like such a case, though I think
> that
> >> sentence could use some clarification. (If the property's "computed
> >> value"
> >> changes due to an animation finishing or being aborted, like in the
> >> previous question, does that count as a "result of declarative
> >> animation"?)
> >
> > Well in this case the transition is started by a property update through
> > :hover, not the animation. But the latter has been updating the computed
> > value of color so, presumably, the state of the property at :hover time
> > is our transition start?
> 
> This is about the first question, quoted further up, right? I.e. the case
> where :hover starts applying? If so, then yes, some value between red and
> green would be the start value. *If* there should be a transition at all.

Any reason why it shouldn't ?

> 
> If you try changing the style of an element from "animation: colorChange
> 4s; transition: color 1s;" to "animation: none; transition: color 1s;"
> while the animation is ongoing, Gecko will transition, but WebKit will
> not. When allowing the animation to run to completion, neither will
> transition.
> 
> > Once :hover no longer matches, we can't really reverse to the start
> value
> > if the latter should resume its animation. I can't think of a good
> > solution
> > that does not involve stopping the animation as soon as the transition
> > starts.
> 
> Once :hover no longer matches the animation applies, and to me this seems
> like a case where "the computed value of a property changes as a result of
> declarative animation". So if you want a transition to start then, I think
> the Transitions spec will have to be changed.

Also, since the property is not going back to its start value then it doesn't
qualify as a reversal.

> 
> If you try changing the style of an element from "animation: none;
> transition: color 1s;" to "animation: colorChange 4s; transition: color
> 1s;", neither Gecko nor WebKit will transition.

I wouldn't expect them to. " Implementations must not start a transition 
when the computed value of a property changes as a result of declarative 
animation (as opposed to scripted animation)."

The issue in the testcase above is that a :hover is making an update on
top of a running animation. (Not something implementations support today
afaik)
> 
> --
> Øyvind Stenhaug
> Core Norway, Opera Software ASA

Received on Tuesday, 24 January 2012 03:49:30 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:48 GMT