-
Notifications
You must be signed in to change notification settings - Fork 2.1k
[MenuSurface] mdc-menu-surface open animation transition #4411
Comments
Thanks for bringing this up. I wonder if this explains the cause of what #4371 fixes? (In which case this will be fixed in 0.44.1.) |
Ah sorry for missing that PR. It does look similar, but I actually just tried applying the PR changes to my local copy, and it doesn't seem to fix this issue alone... Moving the |
I just tested with above PR, it does seem to fix the issue. |
@abhiomkar I just tested this again to be sure, and I am in fact still seeing an issue with the transition (see last paragraph at bottom for why it appears the PR is fixing the issue)... Correct me if I'm wrong, but the PR just moves the The issue I am seeing is that no matter which class the transition is specified on, it never gets the Keep in mind I'm not using the MDC menu JavaScript implementation, only the CSS classes. I am managing the adding/removing of the classes myself in my own JavaScript implementation (web component). I wait for the I set up an example of this on StackBlitz. Both of the following links have exactly the same code, the only difference is the version of the Here is the example of the issue (not working properly) with version 0.44.0: (note: The PR is simulated in the Here is the exact same example (working properly) with version 0.43.1: The reason it is giving you the effect that it's working properly (after applying the changes in the PR) in the MDC menu component is because if you look in this file https://github.com/material-components/material-components-web/blob/master/packages/mdc-menu-surface/foundation.js at the Please let me know if I'm missing something here that you are doing differently. |
Re-ordered menu surface open classes to render `--open` after `--animating-open` to have more specificity for `--open`. Also moved setting position properties before adding `--open` classes so the reflow does not interrupt CSS animation. For reference here is the order of style changes. ``` idle: (#on render) opacity: 0; transform: scale(1); --animating-open: (#on click) opacity: 0; transform: scale(.8); --open: (#requestAnimationFrame) opacity: 1; transform: scale(1); ``` Closes #5682 and Closes #4411 PiperOrigin-RevId: 301177073
It seems that with the refactor to use feature-targeting (in this commit 56b8467) has caused the
mdc-menu-surface--open
class to be defined before themdc-menu-surface--animating-open
class in the resulting CSS. This causes a specificity issue and the transition is not occurring properly.It's worth noting that I am using these classes manually to add them to an element, and wait for the
transitionend
event to fire. Because of the specificity caused by the order in the CSS, the transition does not run properly and the animation does not take place.You can see that in the 0.43.0 version, the
&--open
class is defined after the&--animating-open
class in themdc-menu-surface.scss
file. Now that this has been pushed down into_mixins.scss
you can see that the&--open
definition has been moved before the&--animating-open
definition. This can clearly be seen when you put both classes on an element. Due to themdc-menu-surface--animating-open
coming later in the CSS file, the browser will use those styles even though themdc-menu-surface--open
class is applied after the other class due to them having the same specificity.The text was updated successfully, but these errors were encountered: