You need to
before you can comment on or make changes to this bug.
Adding a transition to an element immediately after removing a class you can see the element transition from the previously removed value to the current value.
I'd expect the removed class to be removed instantly, and the transition only apply to the values that are meant to be on the element when the transition starts.
There is a JSFiddle at: http://jsfiddle.net/Danack/u9X4m/4/
But the test case is reasonably simple.
<div class="container active">
-webkit-transition: all 1s ease;
-moz-transition: all 1s ease;
-o-transition: all 1s ease;
transition: all 1s ease;
Tested in Webkit nightly on Mac - Version 6.0.2 (8536.26.17, 537+)
Chrome on Mac - Version 25.0.1364.155
Safari on Mac - Version 5.1.7 (6534.57.2)
Similar to bug https://bugs.webkit.org/show_bug.cgi?id=58781 where there is no transition performed when there should be.
This is expected behavior, and allowed by the transitions spec. CSS doesn't actually describe how and when styles are resolved, and most browsers batch style changes. That means that the removeClass('active') and addClass('all-transition') basically happen at the same time.
If you don't want this, you can force a layout between them (e.g. via body.offsetWidth), or put the second line inside a setTimeout(, 0).