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

Re: Transitions Side Discussion

From: Andrew Fedoniouk <andrew.fedoniouk@live.com>
Date: Mon, 4 Apr 2011 20:26:37 -0700
Message-ID: <BLU159-ds7BC01DE1BBBCD58B46488F8A20@phx.gbl>
To: "Tab Atkins Jr." <jackalmage@gmail.com>
Cc: "www-style list" <www-style@w3.org>
>-----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

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

Something like that:

  flow: horizontal;
  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

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

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:38:45 UTC