Bug 111718

Summary: Transition CSS added to DOM element uses previously removed class
Product: WebKit Reporter: Dan Ackroyd <Danack>
Component: New BugsAssignee: Nobody <webkit-unassigned>
Severity: Normal CC: dino, simon.fraser
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   

Description Dan Ackroyd 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 Simon Fraser (smfr) 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).