Re: Advanced Transitions, Targeting Individual Transition Edges

On Fri, Apr 1, 2011 at 8:32 PM, Andrew Fedoniouk
<andrew.fedoniouk@live.com> wrote:
>
>> -----Original Message----- From: Tab Atkins Jr.
>> Sent: Friday, April 01, 2011 3:46 PM
>> To: www-style list
>> Subject: Advanced Transitions, Targeting Individual Transition Edges
>>
>>
>> The Problem
>> ===========
>>
>> All of us at Chrome, when we first started using T/A, thought of
>> Transitions as something simple which applies when an element *leaves*
>> a state, and Animations as something complex which applies when an
>> element *enters* a state.  This confused us terribly, but luckily it
>> was just a result of our mental model being very wrong.
>> Unfortunately, it's easy to construct this incorrect mental model,
>> especially when you try to actually *use* Animations for doing complex
>> state transitions.
>>
>> The correct mental model is that the 'transition' property sets up a
>> very simple animation (just a fade from the start value to the end
>> value of a single property) that fires when an element moves between
>> two states, where a "state" is a particular value of a given property.
>> As long as 'transition' is specified for an element, any state-change
>> in the specified properties will fire the simple animation.  It's the
>> state change which is important for the triggering; 'transition'
>> itself should be specified on the element at all times if you want
>> easily-predictable behavior.
>>
>
> My pardon but I believe that your mental model is still wrong.
>
> State of DOM element is a snapshot/set of its attributes and
> runtime state flags (:hover, :active) etc. Nothing else, dot.
>
> Set of CSS properties is a function of DOM element state +
> CSS rules.
>
> Change of state of a DOM element triggers transition.
>
> But not change of CSS property itself. Otherwise the transitioning
> CSS property shall trigger secondary transitions, etc. Quite ill logic
> to be honest.

Uh, no.  Transitions are triggered by a property's value changing.
This is very clear in the spec and implementations.  We get around the
"secondary transitions" problem by saying that the animated value of
the property doesn't trigger transitions.


> So change of state of a DOM element shall trigger transition
> (e.g. change of :hover, :active, some DOM attribute, etc. )

Define "state".  You can't use Selectors to do so, at least not if you
want to wind up with a consistent and usable definition.


> If you will try to think this way then you would find that you can
> do for example this:
>
> button {
>  ...
>  background-repeat: no-repeat;
> }
>
> button:hover {
>  ...
>  background-repeat: repeat;
>  transition: blend(400ms, quad-in, quad-out);
> }
>
> where blend() makes two state snapshots/bitmaps (start, final)
> of element and gradually blends them. This way you can transition
> properties otherwise not transitional, for example:
>  1) background:repeat <-> background:no-repeat
>  2) background:url(1) <-> background:url(2)
>  3) replacing content inside the <frame>, etc.
>
> In your mental modal (and model of CSS Transitions module)
> such transitions are not possible at all.

I am highly confused.  Examples 1 and 2 are completely possible in the
spec's model.  At this precise moment, background-repeat and
background-image aren't defined by the spec to be transitionable, but
we expect to change that - arbitrary values should be transitionable
as a step function, and the animation of image values is defined in
the Image Values spec.

Example 3 can be done with 'content'; otherwise, it's beyond the scope of CSS.


> Transition shall define what exactly happens when the element
> gets the state *and* what happens when element loses that state.
>
> Consider these rules:
>
> button { color: red; }
> button:hover { color:blue; transition: color 200ms/100ms quad-in/quad-out; }
> button:checked { color:green; }
>
> On :hover you will get animated transition from whatever
> state it was before (:checked or normal) using quad-in function.
> On :hover lost you will also get animated transition (100ms)
> using quad-out transition.
>
> Changes between normal and :checked state are instant - not
> animating at all.

This is not, in general, a sufficiently powerful model.  It can only
be used to define transitions to and from a central state, but not
*between* arbitrary states.

> All above is not possible to define in current mental
> model of CSS Transition module so we'd better change it ASAP.

Luckily, this is incorrect.  None of this requires a change in the
Transitions model, just in some details.

~TJ

Received on Saturday, 2 April 2011 17:19:31 UTC