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?


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

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.


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


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


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


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

~TJ

Received on Monday, 4 April 2011 04:45:17 UTC