Re: Advanced Transitions, Targeting Individual Transition Edges

>-----Original Message----- 
>From: Tab Atkins Jr.
>Sent: Saturday, April 02, 2011 10:18 AM
>To: Andrew Fedoniouk
>Cc: Andrew Fedoniouk ; www-style list
>Subject: 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
>>> ===========
>>> ...
>>
>> 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.
>

I would insist on "Yes".

When UA detects that something has happened on the DOM element it
triggers recalculation of styles on that element.

In my model "change of state" is a cause of transition.
In your model "change of state that caused change of css property"
produces transitions.

So these two are pretty much about the same event but yours is
more narrowed/limited. The blend() "function" case below is an example
of things that are not quite possible in your model.

There are a lot more transition effects that cannot be defined
in terms of single CSS property changes. You cut them off by design.

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

For the purpose of CSS "state of DOM element" can be defined as
a set of DOM element features changes in which cannot be detected by
CSS selectors means.

Consider <input type=text> element for example.

It can be in :empty and :not(:empty) states as you can write
this selector:

  input[type=text]:empty

But you cannot distinguish in CSS input state when it has 2 chars from
the state when it has 3 chars. So it is said that the input is
still in non-empty state for the CSS purposes.

I do not see anything wrong with this.

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

That is my turn to say "Oh" [that mental model of yours].

As of this case:

  1) background:repeat <-> background:no-repeat

that step function of yours is not a solution at all for
such drastic changes. Consider other cases like transition from
"no-border-images" to "border-images" case, etc.

As of 2) background:url(1) <-> background:url(2)

Reasonable transition here is available only when elements
gets some :complete state - when image really arrives.
Change of the property is not enough and really makes no sense.

As of 3) replacing content inside the <frame>, etc.

That one is close to #2 - changes of :complete, :incomplete and :busy
state flags.

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

Suddenly it will be in scope if some other module will add, say, :busy state 
flag.

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

I've provided simple and practical problem definition above.
Let me repeat it again then.

Here are three style rules:

button { color: red; }
button:hover { color:blue; }
button:checked { color:green; }

:hover on and off has to produce 200ms transitions:
for :hover 'on' - 'ease-in' function and
for :hover 'off' - 'ease-out' function.

Changes of :checked alone shall not produce any animations - instant change.

I would like to see how you would do this using "sufficiently powerful 
model" of current
spec.

This is by the way typical UI behavior of check and radio boxes
in modern OSes so is a real problem.

-- 
Andrew Fedoniouk

http://terrainformatica.com

Received on Saturday, 2 April 2011 19:39:09 UTC