[css3-transitions] Automatically reversing transitions and multiple transition-delays

Hi.


I find it pretty disturbing that simple thing in CSS like

<html>
<head></head>
<body>
<div id="index"></div>
</body>
</html>

#index {
    position:fixed;
    background-color:black;
    width:100px;
    height:100px;

    transition-property: width, height;
    transition-duration: 1s, 1s;
    transition-delay: 0s, 1s;
}

#index:hover {
    width: 200px;
    height: 200px;
}

Full example here http://jsfiddle.net/CTtxV/

doesn't behave in consistent, symmetric or intuitive
manner with respect to reversal.

In fact it even works differently in Opera than in Firefox and Chrome.


Just play few minutes with mouse, and you will see what I mean. After
starting transition everything is ok, and if we pull off mouse before
second phase of transition triggers, then transition is nicly reversed.
However if second phase of transition started, or transition ended
complete, then pullng mouse off starts transitions which is not reversal
of transition which lead us to this point.

This is in oposition to the "This should just work." rule.


Trying to achive perfect reversal, I then started doing some hacks, like
defining differnt transition in hover and non hover selector.

#index {
    position:fixed;
    background-color:black;
    width:100px;
    height:100px;

    transition-property: width, height;
    transition-duration: 1s, 1s;
    transition-delay: 0s, 1s;
}

#index:hover {
    width: 200px;
    height: 200px;

    transition-property: width, height;
    transition-duration: 1s, 1s;
    transition-delay: 1s, 0s;
}

(basically just swaped delays)

Full example: http://jsfiddle.net/C6EwU/

This just should be unaccassary, but pretend this hack.

Now in Chrome and Firefox, if second phase triggered, and we move mouse
out, then we have "expected" behaviour. However, if we remove mouse
before second phase, then there is significant delay before actuall reversal
takes place.

In Opera, reversal starts without delay ("correctly"), but if second phase
was triggered, then both width and height, are transitioned at once!

Working draft, http://www.w3.org/TR/css3-transitions/, doesnt
actually say exactly what should happen. Also draft mentions term
"considered simultaneous", but doesn't define what this means,
makeing it extreamlly unrealiable tool.

In fact, I think "Automatically reversing transitions" section is not precise
enough. It should introdue concept of absolute timeline and time direction,
then it will be easier to formalize reversing and interuption.

Also point 4: "Ignore any transition delay." is unacteptable, and
completly redundant. Just saying what is in point 3: "...This will make
the transition appear as if it is playing backwards." is sufficient.

also point 2, says "...T, but starting as if the transition had already
begun, without any transition delay,". Why without transition delay?
Point 3 says everything, we need to know (at least informally), and to
have "as .. playing backward" was cannot ignore transition delay. Or
maybe a all implementations are incorrect, and we all just misinterprete
what is written? Or this points, means that we should essentially
change time flow direction without any Additionall delay?


My reasoning is that simple things should be simple, and common
binary state (like hover/unhovered, with some class/without some class)
should behave in sane reason.

For example say I have a fieldset, with legend, and would like
to hide fieldset content by clicking legend. In perfect world I should:
  - create HTML
  - define class ".collapsed" for
  - create event handler in JS, which will toggle .collapsed class,
    for siblings of legend.
  - define transition for collapsing:
       1s transition of opacity going to 0
       after 1s, a 1s transition of say max-height: going from 100 to 0.


And this should be all. It should behave sensible and correctly
after toggling "collapsed" class at any time.

Then unhiding fieldset content, a reverse should take place, first
max-height goes say from 0 to 100, then after 1s a opacity changes from 0 to 1.

Current spec doesn't allow, or doesn't specify correctly how this effect
should be done. (imho it should be single transition property - for
forward, and reverse should be calculated automatically).

I see small problems with my approach however, this is what if we have
for example 3 states / classes, and each have multi stage transitions.
And we are transitioning just from 1st to 2nd, and in the middle of it,
JS changes class or some other selector triggers, and we need to
interupt this and go to 3rd class. Or some property is just changed from
JavaScript.


Maybe "Automatically reversing transitions" is just a special case? But
then it is somehow aritical, because if we do not swap properties, but
changes something back but with 1 pixel difference, it will not use
automatical reversing transition, and will trigger very different
transition (especially when using non-linear timing functions, or
multiple transitions with various delays/durations).

I cannot find anything in draft which will clarify behavious in such
case. I think most developers will rather not specify a duration of
transition, but how fast (in pixels/s for example) it should transit,
with optional acceleration behaviour. However, evaluating ordinary
differential equations are rather out-of-question in browser in CSS.

Also from my expirience, I found Opera behaviour in restarting
transitions, rather strange. If a transition is getting place (due some
property change from JS), and we set this JS property again, to same
value, or just slightly different, then whole transitions is restarted,
from old value. There is many other strange behaviours in browsers,
regarding this restarting, and interupting.

I was hoping that CSS Transitions spec should define quite precisly what
should happen.

I browser last 6 months of archive, searching for some answers about
this problems in draft. But font essentially nothing.

This if serious problem in my opinion.


My $0.02.


Thanks.


-- 
Witold Baryluk

Received on Tuesday, 27 December 2011 13:21:49 UTC