Created by: pvdlg
The JS modules using transitions (modal, alert, popover, collapse, carousel) currently emulate the transitionEnd event with a duration defined as a static value in each module.
If the transitions duration set in css are different than the statics values in each modules (TRANSITION_DURATION
) it creates a visual glitch.
The .show
class is set after the duration set in each module, disregarding the value set in the css transition
property.
For example the collapsing module define a static duration of 600ms. If we set in scss $transition-collapse: height 1s ease
:
- The 1s transition will be initiated and the collapsible area start expanding
- After 600ms the function
transitionEndEmulator
trigger the transitionEnd event (even though the transition is not complete yet - The
collapsing
class will be removed from the collapsible area and it will suddenly appear expanded fully without the transition having completed
Also if we set in scss $transition-collapse: none
, a 600ms transition will still be emulated and the .show
class will be set after 600ms while it should be set right away.
This PR add the function transitionEmulator
to emulate emulate the transition with the duration set in css and to handle the case of no transition or a 0 duration.
As a result:
- we can change the transition duration of modal, alert, popover, collapse and carousel components with sass variables
- we can define specific custom classes with different transition duration, i.e. we can have a collapsible area that expand in 350ms and another one in 700ms
- we can set the transition to none with sass variable (#18156 can be solve by setting
$transition-collapse: none
) - we don't have a risk to have discrepancy between the js module static duration value and the sass variable that would cause a visual glitch and the static duration in each module are now useless
In addition the function transitionEmulator
handle more common code that were previously repeated in each module:
- determine if there is a transition to apply (previously the presence of a class was checked in each module which was failing to determine a transition set by a custom class)
- Order properly the transition start and the completion callback depending on the presence of a transition or not (i.e. if transition: setTimeout to call complete callback then start the transition / if no transition: start the class change and then call the complete callback without timeout)
- As a result it simply the code related to transition in each module and would make it easier to avoid mistakes in future modifications in each modules
Finally the PR updates the unit to test each module behavior with and without transitions