W3C home > Mailing lists > Public > www-style@w3.org > April 2011

Re: Advanced Transitions, Targeting Individual Transition Edges

From: Andrew Fedoniouk <andrew.fedoniouk@live.com>
Date: Fri, 1 Apr 2011 20:32:16 -0700
Message-ID: <BLU159-ds11BAA7A13A04284A925AFDF8A10@phx.gbl>
To: "Tab Atkins Jr." <jackalmage@gmail.com>, "www-style list" <www-style@w3.org>

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

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

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.

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.

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

-- 
Andrew Fedoniouk

http://terrainformatica.com 
Received on Saturday, 2 April 2011 03:33:06 GMT

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