Bug 111718 - Transition CSS added to DOM element uses previously removed class
: Transition CSS added to DOM element uses previously removed class
: WebKit
New Bugs
: 528+ (Nightly build)
: Unspecified Unspecified
: P2 Normal
Assigned To:
  Show dependency treegraph
Reported: 2013-03-07 05:58 PST by
Modified: 2013-03-07 16:06 PST (History)



You need to log in before you can comment on or make changes to this bug.

Description From 2013-03-07 05:58:51 PST
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">


.all-transition {
    -webkit-transition: all 1s ease;
    -moz-transition: all 1s ease;
    -o-transition: all 1s ease;
    transition: all 1s ease;

.container {
    width: 200px;
    height: 15px;
    background-color: #ffd112;

.container.active {
    height: 200px;

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.
------- Comment #1 From 2013-03-07 16:06:09 PST -------
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).