How to stop Transition bounce?

I know I am getting ahead of myself, being that CSS3’s transitions are only supported by select browsers, but I got curious and decided to experiment, in ding so I ran into what’s either or a demonstration of my poor understanding of the subject. I thought some of the wiser forum members could clear this up.

I could group my observations into 3 points:
#1 Units of measure
The ENTIRE TRANSITION RULE will be ignored if any the properties being transitioned have values with different units of measurement ,excluding auto, like hex to rgba or % to px. For example: in the code bellow… change:width:auto; to width:150px in a.foo{}, test and see: no transition occurs at all. However change that to width:10% and the transition is honored again. This horribly limits the usefulness of transitions, especially in fluid layouts; I cant believe or find any evidence that this is part of the spec.

2 I did find a work-around, but it’s kinda hackish. I found that if I set the min-width to any value the transition is honored again. I suppose it will do in a pinch but then again I have to make an assumption of a min-width. Plus this complicates some things later on as I will elaborate.

  1. there is a bounce effect that occurs (seemingly at the start of the effect…) when the width is transitioned from a width auto ( or a min-width) to an non px width. I set the delay in the transition code below so it would be easier to see what i mean , please be patient when hovering over the links or you can remove the 2s from the -webkit-transition:

It seems that if there is no explicit width set, the transition sets the width of the element to 0, if its auto; or to whatever min-width is set… even if the element was wider naturally before the trans was triggered. it then runs the transition. which of course means that for a while the content of the leaks out of the element itself and that there is the aforementioned bounce effect.

again it seems kinda clumsy to have an element that by any other standards but explicit width, have been sized at 125px, to shrink back to 15px so that it can resume it’s transition to 500px or even 100% ( as this happens even if the target new size is given in the same unit measure). It’s also odd, considering how much detail is given in the spec as to how a transition behaves when interrupted.

Maybe these are bugs, maybe these are “features” maybe I made some bugger typos in my code?? What is your experience.

The code I used is as follows:


a.foo { display:block;
  background: #9c3; float:left; clear:left; /*min-width:15px;*/
  -webkit-transition: all 2s ease; -webkit-border-radius:8px;
  -moz-transition: all 2s ease; -moz-border-radius:8px;
  -o-transition: all 2s ease;
  transition: all 2s ease;
  }
a.foo:hover {
  background: #690; /*width:255px;*/ width:100%; -webkit-box-shadow:5px 5px 2px rgba(0,0,0,.25);
  }
a.foo span{padding: 15px 20px; display:inline-block;}

  p span{padding:25px; background:orange; display:inline-block}



<div ><a class="foo" href="#" ><span>hello</span></a></div>
<div ><a class="foo" href="#" ><span>hello</span></a></div>
<div ><a class="foo" href="#" ><span>this is a longer hello</span></a></div>
<div ><a class="foo" href="#" ><span>hello</span></a></div>
<p> transitions do not work between diffrent value  types,. ie between a start of 50px and and end of 100%  also , if no width is set to start or end , or if it's set to auto ... it will be equvalent to width:0, then snap!???</p>

Hi Ray,

Yes I came across those issues when I created this demo. I wanted the content to slide down from the heading but it would only work if I specified a final height which was no good for fluid text so I just went with a fade effect instead. It just seems you can’t transition to or from an auto value properly.

Webkit won’t let you mix units but gecko will. The specs say that only length, or percentage values are animated for height/width so it looks auto is not catered for (the specs don’t mention mixed values but as gecko will animated mixed values I think it’s probably allowed) .

It does make it hard to animate real content because you seldom want it constrained by dimensions and most often you would want to animate from zero to auto. Auto almost seems to mean animate to zero and then as you mention the element bounces back to size.

I agree that it seems rather clumsy and perhaps these things will change in time as they are obviously going through a transition :slight_smile:

Lol.

Cool demo, Paul! but did you know if you use the same units, it doesn’t ignore the transition (0em - 10em). you can also use min-width ( uncommment in my code, and you will see what I mean)

What really bothers me is that you cant go from auto to 100% ( or any other unit for that matter) So it becomes next to impossible to have a tab extend to the width of it’s container. Unless the tab is fluid width, and thats just ugly for menus.

incidentally, I think it always goes to zero and that’s my question.

if you look at the animated code again, you’ll see that, when you hover out, the element retracts to a width of 0, then SNAPS back its stated width, as opposed to going from 100% width to its stated width directly.

 		 		Lol.

Did you see the ugly animated fish in the footer tab:)

Yes that’s the main problem I had and I don’t really know why they built it that way as it does really stop all the useful applications of this dead in their tracks. (Perhaps you should file a bug or feature request ;))

incidentally, I think it always goes to zero and that’s my question.

It doesn’t go to zero if you start with a fixed width and finish with a fixed width.

e.g.


a.foo {
    display:block;
    background: #9c3;
    float:left;
    clear:left; /*min-width:15px;*/
    -webkit-transition: all 2s ease;
    -webkit-border-radius:8px;
    -moz-transition: all 2s ease;
    -moz-border-radius:8px;
    -o-transition: all 2s ease;
    transition: all 2s ease;
 [B]   width:200px;[/B]
}
a.foo:hover {
    background: #690; /*width:255px;*/
   [B] width:500px;[/B]
    -webkit-box-shadow:5px 5px 2px rgba(0, 0, 0, .25);
}

if you look at the animated code again, you’ll see that, when you hover out, the element retracts to a width of 0, then SNAPS back its stated width, as opposed to going from 100% width to its stated width directly.

It only does that when you don’t have a width to start width, or use width auto or you have no width defined.

There are variations in Firefox and webkit though also as Firefox behaves a little differently a lot of the time.

Hopefully things will improve but a lot of these implementations are still experimental.

Oh ok, those are the same conclusions i had drawn. That’s a bit of a bummer, but at least I am not insane. :slight_smile:

I never doubted you :slight_smile: