CODEWITHSUNDEEP
htmlcssinternet-explorercss-transitions
Tiborg
Tiborg

Reputation: 2305

IE10 / IE11 bug in 'ease back' transitions

I set up a jsFiddle with the issue: https://jsfiddle.net/kLqv86t2/7/

The ease-back effect is defined by:

transition-timing-function: cubic-bezier(0.15, 0.85, 0.30, 2.00);

Summary: click anywhere on the document, anytime you want, and the red square should switch it's position between A and B, with an ease-back transition effect

Instructions:

The expected behavior (Chrome, Firefox) is that from it's current position ('bounce B' zone), the red square should bounce back into the 'bounce A' zone and then return to 'A'. Basically, it would be the same effect as if the red square would start from the 'B' zone.

But in your beloved standards-compliant bug-free Internet Explorer browser, this is not the case. When the transition is in progress (the red square is in the 'bounce B' zone), and I click, the red square linearly moves to the 'A' zone, without the ease-back effect.

I looked up the CSS Transitions specification, and it seems that this is not the expected behavior, and clearly it doesn't feel like it is.

I tested in IE 11 (build 11.0.9600.17633) and IE 10 (build 10.0.9200.17228).

Does anybody know why this is happening and how can it be solved?

Upvotes: 4

Views: 796

Answers (1)

vals
vals

Reputation: 64244

Well, the standard specification says that

3.1. Automatically reversing interrupted transitions

Many common transitions effects involve transitions between two states, such as the transition that occurs when the mouse pointer moves over a user interface element, and then later moves out of that element. With these effects, it is common for a running transition to be interrupted before it completes, and the property reset to the starting value of that transition. An example is a hover effect on an element, where a transition starts when the pointer enters the element, and then the pointer exits the element before the effect has completed. If the outgoing and incoming transitions are executed using their specified durations and timing functions, the resulting effect can be distractingly asymmetric because the second transition takes the full specified time to move a shortened distance. Instead, the expected behavior is that the second transition is shorter.

To meet this expectation, when a transition is started for a property on an element (henceforth, the new transition) that has a currently-running transition whose reversing-adjusted start value is the same as the end value of the new transition (henceforth, the old transition), implementations must cancel the old transition link to definition above and adjust the new transition as follows (prior to following the rules for computing the combined duration, start time, and end time):

The reversing-adjusted start value of the new transition is instead the the end value of the old transition. Note: This represents the logical start state of the transition, and allows some calculations to ignore that the transition started before that state was reached, which in turn allows repeated reversals of the same transition to work correctly. The reversing shortening factor of the new transition is the absolute value, clamped to the range [0, 1], of the sum of: the output of the timing function of the old transition at the time of the style change event, times the reversing shortening factor of the old transition 1 minus the reversing shortening factor of the old transition. Note: This represents the portion of the space between the reversing-adjusted start value and the end value that the old transition has traversed (in amounts of the value, not time), except with the absolute value and clamping to handle timing functions that have y1 or y2 outside the range [0, 1]. The matching transition-duration for the new transition is multiplied by the reversing shortening factor. If the matching transition-delay for the new transition is negative, it is also multiplied by the reversing shortening factor. Note that these rules do not fully address the problem for transition patterns that involve more than two states.

Note that these rules lead to the entire timing function of the new transition being used, rather than jumping into the middle of a timing function, which can create a jarring effect.

This was one of several possibilities that was considered by the working group. See the reversing demo demonstrating a number of them, leading to a working group resolution made on 2013-06-07 and edits made on 2013-11-11.

It would be a lie on my side if I said that I understand this fully

But, I think that what the standard says fits more with the IE results than with the Chrome or Firefox results.

Easier to check: go to the w3c demo and choose 2013-06-07 spec text on reversing (Apple proposal) and your bezier values.

The result matches much more the IE result than others. Chrome and Firefox results match No Reversing Adjustment

disclaimer I am not an IE fan !!! :-)

Upvotes: 2

Related Questions