Re: Transitions Side Discussion

>-----Original Message----- 
>From: Tab Atkins Jr.
>Sent: Sunday, April 03, 2011 6:57 PM
>To: Andrew Fedoniouk
>Cc: Andrew Fedoniouk ; www-style list
>Subject: Re: Transitions Side Discussion
>
>> 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.
>
>I agree that many transition effects can't be properly described as a
>change in an existing CSS property.  That's why I dedicated an entire
>section of my proposal to pointing out that problem, and how to solve
>it.
>

Please see below.

>
>>>> 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.
>
>I have a section of my proposal dedicated to explaining what is wrong
>with defining "states" (that is, the things that trigger transitions
>when they change) via Selectors.
>

My schema is more practical yet simple than yours - now new
entities and properties required. See below.

>
>> 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.
>
>I don't understand what you're trying to say here.  All discrete
>properties can be easily animated by a step function.
>

"Step function" is just another way of saying "switch it instantly".
It is not a [gradual] transition in common sense.

This:

div
{
  background-image: url(some.jpg);
  background-repeat: no-repeat;
}
div:hover
{
  background-repeat: repeat;
  transition: blend(400ms); // dissolve, morph, etc.
}

allows to do gradual transition from rendering "A" to rendering "B".
No matter how different they are.

There many effects that fall into transition category,
page-flip effect for example. You and current spec. excluded them
as a class for reasons unknown to me.

>
>> 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.
>
>I don't understand your objection.

If you have two bitmaps: A and B then you can transition (gradual morph)
them in many ways.

But you have to have them both in order to do so.

Consider this:

div {
  background:url(1.png);
}
div:hover
{
  background:url(2.png);
  transition: background 200ms;
}

When the transition will start? When :hover state changes (and so the rule 
applied)
or when image will be delivered from the server? That will be different
moment of time.

>>>> 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.
>
>Your above example is ambiguous.  What happens when you go from :hover
>to :hover:checked?  Does it change color instantly to green?  What if
>you then hover out (going from :hover:checked to just :checked)?  What
>happens if you set a transition on :checked, and then go from :hover
>to :hover:checked?  Which wins, the outgoing transition on :hover or
>the incoming transition on :checked?

I do not see any ambiguity to be honest.

button:hover -> button:hover:checked as it is defined will change
target transition color or the color itself instantly as :checked state
does not define any new transition.

:hover:checked -> :checked
will run transition defined for :hover state / exit part.
So from 'blue' to 'green' using 100ms/quad-out.

>
>> 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.
>
>button { state-hover: false; }
>button:hover { state-hover: true; }
>@transition button {
>  over: state-hover;
>  from: false;
>  to: true;
>  animation: transition(color) ease-in .2s;
>}
>@transition button {
>  over: state-hover;
>  from: true;
>  to: false;
>  animation: transition(color) ease-out .2s;
>}
>

It should not be that complex. You've introduced new
entities when they are not needed.

All this is actually *very* simple:

1) For each property the transition defines function/time
   how to "enter new value" *and* how to "leave from that value".
   So transition definition has enter/exit parts.

2) When element gets new style it has two values of transition property
   - old and new.

a) "old" is null and "new" is null - nothing transitioned.
b) "old" is null and "new" defined - use enter part of "new".
c) "old" defined and "new" is null - use exit part of "old".
d) "old" defined  and "new" defined - use enter part of "new".

Practice shows that this is very intuitive, flexible and sufficient
for almost all UI effects used in modern OSes.

In any case current Transition spec has to be changed/extended.
It is enough to add there enter/exit parts for transitions and to say
that beside of properties definitions the transition may have
functions that define transitions that cannot be expressed
by change of single property.

-- 
Andrew Fedoniouk.

http://terrainformatica.com

Received on Monday, 4 April 2011 03:55:59 UTC