Re: Transitions Side Discussion

>
>-----Original Message----- 
>From: Tab Atkins Jr.
>Sent: Sunday, April 03, 2011 9:44 PM
>To: Andrew Fedoniouk
>Cc: Andrew Fedoniouk ; www-style list
>Subject: Re: Transitions Side Discussion
>
>On Sun, Apr 3, 2011 at 8:55 PM, Andrew Fedoniouk
><andrew.fedoniouk@live.com> wrote:
>>>> 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.
>
>...which is exactly what you want when you're transitioning a discrete
>property, like background-repeat.  What's th problem?
>

Strange, I think I've expressed clear enough what is needed.

repeat <-> no-repeat transition is just an example.

I would like here to have gradual transition from one image to
9 of them tiled.

You say that your model supports only sudden changes (bashfully named
as "step functions"). That is quite limited model then.

Consider these cases:
  flow: horizontal-wrap <-> vertical-wrap
  background: url(1) <-> url(2)
  and so on ...

>
>> 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.
>
>This is something completely new and different, defining a "rendering"
>as an object that CSS can manipulate.

Nothing new here. CSS already does this.
"opacity:0.5" is such manipulation.

>
>There are indeed use-cases for this sort of thing; another one is to
>animate the layout position of an element when it changes, so that,
>for example, elements animate around if the page size changes and
>causes them to reflow.  However, neither of these are easy to define;
>they're definitely not a simple extension to existing
>Transitions/Animations.

It is *very* easy to define if to use proper mental model :)

Something like that:

div
{
  flow: horizontal;
}
div.state2
{
  flow: vertical;
  transition: move-children(400ms, with-whistle-blowing) /
                   move-children(200ms, silent);
}

Easy, isn't it?

Implementation can be tricky, but not that much. But that is another story.


>
>
>>>> 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.
>
>CSS doesn't care about network behavior in general; as far as it's
>concerned, referenced images are always available.  The animation will
>play when the div gains :hover (or rather, it would do so if you had
>the 'transition' property on the "div" rule).

I do have :busy and :incomplete states that allow me to define
things like:

img:busy:incomplete { background:url(stock:that-spinning-thing.gif) 
no-repeat; }
img:not(:busy):incomplete { background:url(stock:image-not-available.gif) 
no-repeat; }

It falls nicely into CSS as far as I can tell. I've got real
requests for customization of such things. Never say never.

That is about styling of standard <img>, <object>, <frame>, etc.
I believe it makes sense for <video>/<audio> too.

>
>
>>>>>> 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.
>
>Ah, okay.  So your model is no longer anything like Transitions at
>all; it's merely a somewhat extended Animations model, where the
>animation is played when an element gains or loses a particular value
>in its 'transition' property, and the animation itself is
>auto-generated (no need to create an explicit set of keyframes).

It is a transition. Current spec defines implicit "rollback" transition.
(Restoring state after transition that was not complete).

I've extended this - added explicit declaration of exit manner.
No drastic changes.

>
>
>> :hover:checked -> :checked
>> will run transition defined for :hover state / exit part.
>> So from 'blue' to 'green' using 100ms/quad-out.
>
>Well, from 'green' to 'green', since :checked is later in the
>stylesheet and thus more specific, so no transition actually fires.

Switch their order. I think you understand what I meant.

>
>
>>>> 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.
>
>They are indeed needed for some cases.  Look back at my earlier button
>example, where there are four states with seven possible transition
>paths between them.  It is impossible to use your model to set a
>different animation for each transition path.
>

In some rare cases - yes. But you always can write something like this:

:hover { transition: in1/out1;  }
:hover:not(:checked) { transition: in2/out2;  }
:hover:checked { transition: in3/out3;  }

Maintenance of such complex transition tables is not a fun. But
it is not more complex than your over/from/to things.

Again, current transition module establishes pretty good foundation.
We just need to add optional state exit parts.
This small feature solves many problems as our practice shows.

-- 
Andrew Fedoniouk

http://terrainformatica.com

Received on Tuesday, 5 April 2011 03:27:09 UTC