-
Notifications
You must be signed in to change notification settings - Fork 186
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Popup] Supporting transitions and animations on open and dismiss #335
Comments
I'm new here and I may be completely out of line, but this made me think of something that might work for multiple use cases. Following the lead of the Paint, Layout, and Animation worklets; we could have an "Event Worklet" that could be applied to something like onChanging would be triggered just before the property changed and if a promise is returned from the worklet then the actual value change waits for it to return. If there is no promise returned then we get an immediate change. This behaviour would keep backwards compatibility but also give developers/designers the chance to intervene if they need to. There could also be an onChanged event for after the value changes enabling easier transitions for after a display: block is triggered. Animation events can also be used to do this kind of thing, but it requires a bit of setup to do properly. Generally I will apply an intermediate class that starts the animation and then I would use the |
There was an "apply hooks" proposal as the style part of houdini. I'm not sure where it's at today but it supported running code in response to style changes. The catch was that the only output of an apply hook is changing other styles. You have to be very careful not to allow cycles, where arbitrary modification before an update takes place could easily trigger cycles. The houdini apply hooks proposal detected and prevented cycles at registration time. |
This was discussed in today's telecon with the following resolution:
|
There hasn't been any discussion on this issue for a while, so we're marking it as stale. If you choose to kick off the discussion again, we'll remove the 'stale' label. |
With the new Popup proposal (#455), the UA does not force-hide the popup when it is not "showing". The UA has a
[popup]:popup-open {
animation: {whatever you like};
}
<script>
popup.addEventListener('hide',(e) => {
e.target.classList.add('animating-out');
e.target.addEventListener('animationend',() => {
e.target.classList.remove('animating-out');
}, {once: true});
});
</script>
<style>
[popup]:not(:popup-open).animating-out {
display: block; /* Override display:none while animating */
animation: {whatever you like};
}
</style> Do folks think this is "enough" to resolve this issue? Side note: this issue relates to #342. |
I've been giving this some thought. Increasingly, I'm thinking the solution in my comment just above is not enough. It has three main limitations:
I think the solution presented in the OP could work, with potentially one modification. The case I'm concerned about is the "popup forced out of the top layer" case. For example when a modal
@flackr did I get the above right? Anything missing? |
I think your latest proposed solution sounds good. I was worried about the same points you raised. This animate / transition to / from I'd be happy to go with the proposal above, but we should consider if there's some way to support entry / exit animations for other elements that come into existence / go away. w3c/csswg-drafts#6429 is somewhat related. An example terrible idea, there could be a pseudoclass that when it first starts matching forces an additional style update after the first style update in which it then applies? |
Thanks!
Hmm, I would love it if this could be solved more generally, to avoid the specific complexity within Popup. Do you think w3c/csswg-drafts#6429 might be resolved any time soon? I want to avoid blocking on that, since I think this behavioral change would be fairly significant and would be a breaking change if made later. |
The Open UI Community Group just discussed The full IRC log of that discussion<gregwhitworth> Topic: How are we going to support animations for popups<gregwhitworth> masonf: there is a proposal <gregwhitworth> masonf: there is a change in behavior in popup to make it trivial to add animations/transitions to open and close with no JS <gregwhitworth> masonf: there are open questions <gregwhitworth> masonf: I opened an issue in top-layer and they raised discussion about animations and when would it match vs not <masonf> github: https://github.com//issues/335 <gregwhitworth> masonf: so please see the issue 335 <gregwhitworth> flackr: I was going to add that the idea of waiting for animations to finish is not novel it's being used for sharedElementTransitions <tantek> for the minutes: https://github.com/w3c/csswg-drafts/issues/7319 <gregwhitworth> masonf: I've also started implementing it and it looks better than I thought it would <JonathanNeal> For future prototype purposes, is there general guidance on how to implement animation waiting? <gregwhitworth> Zakim, end meeting <Zakim> As of this point the attendees have been flackr, gregwhitworth, dandclark, scotto_, una, masonf, miriam, tantek, emilio, JonathanNeal <Zakim> RRSAgent, please draft minutes <RRSAgent> I have made the request to generate https://www.w3.org/2022/06/02-openui-minutes.html Zakim <Zakim> I am happy to have been of service, gregwhitworth; please remember to excuse RRSAgent. Goodbye <gregwhitworth> RRSAgent, please leave <RRSAgent> I see no action items |
Now, popups will follow this process when showing/hiding: showPopup(): 1. Move the popup to the top layer, and remove the UA display:none style. 2. Update style. (Transitions can start from this state.) 3. Set the :top-layer or (whatever) pseudo class. 4. Update style. (Animations/transitions happen here.) hidePopup(): 1. Remove the :top-layer pseudo class. 2. Update style. (Animations/transitions start here.) 3. If the hidePopup() call is not due to a "force out" situation, wait at this step until all finished promises on popup.getAnimations() resolve. 4. Remove the popup from the top layer, and add the UA display:none style. 5. Update style. See this issue for more details: openui/open-ui#335 Bug: 1307772 Change-Id: Ia20eb6e9533c1a0b1029ca1279d42fe2648300af
Now, popups will follow this process when showing/hiding: showPopup(): 1. Move the popup to the top layer, and remove the UA display:none style. 2. Update style. (Transitions can start from this state.) 3. Set the :top-layer or (whatever) pseudo class. 4. Update style. (Animations/transitions happen here.) hidePopup(): 1. Remove the :top-layer pseudo class. 2. Update style. (Animations/transitions start here.) 3. If the hidePopup() call is not due to a "force out" situation, wait at this step until all finished promises on popup.getAnimations() resolve. 4. Remove the popup from the top layer, and add the UA display:none style. 5. Update style. See this issue for more details: openui/open-ui#335 Bug: 1307772 Change-Id: Ia20eb6e9533c1a0b1029ca1279d42fe2648300af
Now, popups will follow this process when showing/hiding: showPopup(): 1. Move the popup to the top layer, and remove the UA display:none style. 2. Update style. (Transitions can start from this state.) 3. Set the :top-layer or (whatever) pseudo class. 4. Update style. (Animations/transitions happen here.) hidePopup(): 1. Remove the :top-layer pseudo class. 2. Update style. (Animations/transitions start here.) 3. If the hidePopup() call is not due to a "force out" situation, wait at this step until all finished promises on popup.getAnimations() resolve. 4. Remove the popup from the top layer, and add the UA display:none style. 5. Update style. See this issue for more details: openui/open-ui#335 Bug: 1307772 Change-Id: Ia20eb6e9533c1a0b1029ca1279d42fe2648300af
Now, popups will follow this process when showing/hiding: showPopup(): 1. Move the popup to the top layer, and remove the UA display:none style. 2. Update style. (Transition initial style can be specified in this state.) 3. Set the :top-layer pseudo class. 4. Update style. (Animations/transitions happen here.) hidePopup(): 1. Capture any already-running animations via getAnimations(). 2. Remove the :top-layer pseudo class. 3. Update style. (Animations/transitions start here.) 4. If the hidePopup() call is not due to a "force out" situation, getAnimations() again, remove any from step #1, and then wait here until all of them finish or are cancelled. 4. Remove the popup from the top layer, and add the UA display:none style. 5. Update style. See this issue for more details: openui/open-ui#335 Bug: 1307772 Change-Id: Ia20eb6e9533c1a0b1029ca1279d42fe2648300af
Now, popups will follow this process when showing/hiding: showPopup(): 1. Move the popup to the top layer, and remove the UA display:none style. 2. Update style. (Transition initial style can be specified in this state.) 3. Set the :top-layer pseudo class. 4. Update style. (Animations/transitions happen here.) hidePopup(): 1. Capture any already-running animations via getAnimations(). 2. Remove the :top-layer pseudo class. 3. Update style. (Animations/transitions start here.) 4. If the hidePopup() call is not due to a "force out" situation, getAnimations() again, remove any from step #1, and then wait here until all of them finish or are cancelled. 4. Remove the popup from the top layer, and add the UA display:none style. 5. Update style. See this issue for more details: openui/open-ui#335 Bug: 1307772 Change-Id: Ia20eb6e9533c1a0b1029ca1279d42fe2648300af
Now, popups will follow this process when showing/hiding: showPopup(): 1. Move the popup to the top layer, and remove the UA display:none style. 2. Update style. (Transition initial style can be specified in this state.) 3. Set the :top-layer pseudo class. 4. Update style. (Animations/transitions happen here.) hidePopup(): 1. Capture any already-running animations via getAnimations(). 2. Remove the :top-layer pseudo class. 3. Update style. (Animations/transitions start here.) 4. If the hidePopup() call is not due to a "force out" situation, getAnimations() again, remove any from step #1, and then wait here until all of them finish or are cancelled. 4. Remove the popup from the top layer, and add the UA display:none style. 5. Update style. See this issue for more details: openui/open-ui#335 Bug: 1307772 Change-Id: Ia20eb6e9533c1a0b1029ca1279d42fe2648300af
Now, popups will follow this process when showing/hiding: showPopup(): 1. Move the popup to the top layer, and remove the UA display:none style. 2. Update style. (Transition initial style can be specified in this state.) 3. Set the :top-layer pseudo class. 4. Update style. (Animations/transitions happen here.) hidePopup(): 1. Capture any already-running animations via getAnimations(). 2. Remove the :top-layer pseudo class. 3. Update style. (Animations/transitions start here.) 4. If the hidePopup() call is not due to a "force out" situation, getAnimations() again, remove any from step #1, and then wait here until all of them finish or are cancelled. 4. Remove the popup from the top layer, and add the UA display:none style. 5. Update style. See this issue for more details: openui/open-ui#335 Bug: 1307772 Change-Id: Ia20eb6e9533c1a0b1029ca1279d42fe2648300af
Now, popups will follow this process when showing/hiding: showPopup(): 1. Move the popup to the top layer, and remove the UA display:none style. 2. Update style. (Transition initial style can be specified in this state.) 3. Set the :top-layer pseudo class. 4. Update style. (Animations/transitions happen here.) hidePopup(): 1. Capture any already-running animations via getAnimations(). 2. Remove the :top-layer pseudo class. 3. Update style. (Animations/transitions start here.) 4. If the hidePopup() call is not due to a "force out" situation, getAnimations() again, remove any from step #1, and then wait here until all of them finish or are cancelled. 4. Remove the popup from the top layer, and add the UA display:none style. 5. Update style. See this issue for more details: openui/open-ui#335 Bug: 1307772 Change-Id: Ia20eb6e9533c1a0b1029ca1279d42fe2648300af Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3688871 Reviewed-by: Robert Flack <[email protected]> Commit-Queue: Mason Freed <[email protected]> Cr-Commit-Position: refs/heads/main@{#1014235}
Now, popups will follow this process when showing/hiding: showPopup(): 1. Move the popup to the top layer, and remove the UA display:none style. 2. Update style. (Transition initial style can be specified in this state.) 3. Set the :top-layer pseudo class. 4. Update style. (Animations/transitions happen here.) hidePopup(): 1. Capture any already-running animations via getAnimations(). 2. Remove the :top-layer pseudo class. 3. Update style. (Animations/transitions start here.) 4. If the hidePopup() call is not due to a "force out" situation, getAnimations() again, remove any from step #1, and then wait here until all of them finish or are cancelled. 4. Remove the popup from the top layer, and add the UA display:none style. 5. Update style. See this issue for more details: openui/open-ui#335 Bug: 1307772 Change-Id: Ia20eb6e9533c1a0b1029ca1279d42fe2648300af Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3688871 Reviewed-by: Robert Flack <[email protected]> Commit-Queue: Mason Freed <[email protected]> Cr-Commit-Position: refs/heads/main@{#1014235}
Now, popups will follow this process when showing/hiding: showPopup(): 1. Move the popup to the top layer, and remove the UA display:none style. 2. Update style. (Transition initial style can be specified in this state.) 3. Set the :top-layer pseudo class. 4. Update style. (Animations/transitions happen here.) hidePopup(): 1. Capture any already-running animations via getAnimations(). 2. Remove the :top-layer pseudo class. 3. Update style. (Animations/transitions start here.) 4. If the hidePopup() call is not due to a "force out" situation, getAnimations() again, remove any from step #1, and then wait here until all of them finish or are cancelled. 4. Remove the popup from the top layer, and add the UA display:none style. 5. Update style. See this issue for more details: openui/open-ui#335 Bug: 1307772 Change-Id: Ia20eb6e9533c1a0b1029ca1279d42fe2648300af Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3688871 Reviewed-by: Robert Flack <[email protected]> Commit-Queue: Mason Freed <[email protected]> Cr-Commit-Position: refs/heads/main@{#1014235}
Automatic update from web-platform-tests Make popups animation-friendly Now, popups will follow this process when showing/hiding: showPopup(): 1. Move the popup to the top layer, and remove the UA display:none style. 2. Update style. (Transition initial style can be specified in this state.) 3. Set the :top-layer pseudo class. 4. Update style. (Animations/transitions happen here.) hidePopup(): 1. Capture any already-running animations via getAnimations(). 2. Remove the :top-layer pseudo class. 3. Update style. (Animations/transitions start here.) 4. If the hidePopup() call is not due to a "force out" situation, getAnimations() again, remove any from step #1, and then wait here until all of them finish or are cancelled. 4. Remove the popup from the top layer, and add the UA display:none style. 5. Update style. See this issue for more details: openui/open-ui#335 Bug: 1307772 Change-Id: Ia20eb6e9533c1a0b1029ca1279d42fe2648300af Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3688871 Reviewed-by: Robert Flack <[email protected]> Commit-Queue: Mason Freed <[email protected]> Cr-Commit-Position: refs/heads/main@{#1014235} -- wpt-commits: 297b9403e0ab65348de01169d1a4e3cf078af7b9 wpt-pr: 34304
Automatic update from web-platform-tests Make popups animation-friendly Now, popups will follow this process when showing/hiding: showPopup(): 1. Move the popup to the top layer, and remove the UA display:none style. 2. Update style. (Transition initial style can be specified in this state.) 3. Set the :top-layer pseudo class. 4. Update style. (Animations/transitions happen here.) hidePopup(): 1. Capture any already-running animations via getAnimations(). 2. Remove the :top-layer pseudo class. 3. Update style. (Animations/transitions start here.) 4. If the hidePopup() call is not due to a "force out" situation, getAnimations() again, remove any from step #1, and then wait here until all of them finish or are cancelled. 4. Remove the popup from the top layer, and add the UA display:none style. 5. Update style. See this issue for more details: openui/open-ui#335 Bug: 1307772 Change-Id: Ia20eb6e9533c1a0b1029ca1279d42fe2648300af Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3688871 Reviewed-by: Robert Flack <[email protected]> Commit-Queue: Mason Freed <[email protected]> Cr-Commit-Position: refs/heads/main@{#1014235} -- wpt-commits: 297b9403e0ab65348de01169d1a4e3cf078af7b9 wpt-pr: 34304
Ok, I've now finished prototyping something in Chromium (thanks for help, @flackr!), and I think it looks pretty good. You can do this now: [popup] {
opacity: 0;
transition: opacity 0.5s;
}
[popup]:top-layer {
opacity: 1;
} ...and all pop-ups on the page will fade in and out. No Javascript needed. To accomplish this, here is what
There are also provisions for force-hiding any in-progress Note that as part of the above, I changed both popUp.addEventListener('hide', () => {
popUp.animate({transform: 'translateY(-50px)'}, 200);
}); One potentially "different" thing is that with the above logic, the pop-up will have periods (during animations) where it a) is in the top layer, but b) doesn't match the Thoughts appreciated. This should be testable in a Chromium browser with Experimental Web Platform Features enabled, and a very recent Canary build (like the one that comes out tomorrow). @jh3y |
Without the extra pseudo for say [popup] {
position: fixed;
top: 50%;
left: 50%;
transform: translate(-50%, -50%) translateX(calc(var(--x, -1) * 100vh));
transition: transform 0.25s ease-out;
}
[popup]:top-layer {
transform: translate(-50%, -50%) translateX(0);
} I'm doing this with a little bit of JavaScript in this demo: https://codepen.io/jh3y/pen/qBoOMVv/ffb50c595e43febebdf78555a88ead60 But, using |
You should be able to set different animations using CSS animations, e.g. [popup] {
animation: exit-animation 250ms;
}
[popup]:top-layer {
animation: entry-animation 250ms;
} I agree that I think it can't be done with CSS transitions without either Javascript or adding additional pseudoclasses. |
The Open UI Community Group just discussed
The full IRC log of that discussion<gregwhitworth> Topic: [Popup] Supporting transitions and animations on open and dismiss<gregwhitworth> github: https://github.com//issues/335 <JonathanNeal> masonf: This has to do with animations; how you can animate a popup in and out. We’ve been discussing behavior, and how you would handle or wait for animations. It’s described in much more detail in the issue. It’s currently implemented in the Chromium prototype. <jhey> Only issue I had as mentioned in the issue was if you want to transition in from one side and out the other. <JonathanNeal> masonf: It has to wait to check for any animations, but implementation-wise, it’s not too bad. I’m looking for general comments, but mainly if the proposal outlined would be agreed upon. <flackr> q+ <JonathanNeal> jhey: say you wanted to do a scope transition, in from the left, then out to the right. You can’t do without some kind of JS intervention. You can’t tell if you are coming in or going out. <gregwhitworth> ack flackr <dbaron> q+ to ask about CSS transitions more generally <JonathanNeal> flackr: I left a comment on the issue. This is possible with CSS Animations. You can set an animation on top layer that matches the opening popup, and another that matches the closing popup. It’s true that there’s nothing for transitions, but the animation strategy would work without JS. <gregwhitworth> flackr comment is here: https://github.com//issues/335#issuecomment-1175367327 <JonathanNeal> flackr: We don’t have another good way to make animations only on opening/closing state. <JonathanNeal> masonf: are there other cases in the platform where you can’t transition in different ways? <gregwhitworth> q? <JonathanNeal> flackr: it would be the case with anything that has two states that you would go between. <JonathanNeal> masonf: like `:hover` coming in or going out. <JonathanNeal> dbaron: Can you transition differently in and out of hover? You sort of can. It depends on what you mean. Maybe for the exact thing you can’t. You can certainly have a different value of the transition properties so that you get different transitions going in or out of hover, but it doesn’t help you if you want different values at the end of the transition. <gregwhitworth> ack dbaron <Zakim> dbaron, you wanted to ask about CSS transitions more generally <JonathanNeal> dbaron: It feels a little bit like you are adding a mechanism that is useful that is adequate for one specific case. However, I’m not certain it extends very well into the other cases where people would want it. <flackr> q+ to respond to dbaron <JonathanNeal> masonf: here this is more nuanced because there is also the top layer. Generally, I try to avoid solving all the world’s problems in order to solve one. Maybe I’m imagining too much, but whatever solution would be general would be compatible with this. <gregwhitworth> ack flackr <Zakim> flackr, you wanted to respond to dbaron <JonathanNeal> jhey: I understand there would be a lot of extra work to get directional transitions baked in. <JonathanNeal> flackr: I think there might be a generic mechanism here. Possibly one that would even simplify what we’re doing with popup. I think there are two things. 1. If you have some sort of way to match against things that had just become visible, or no longer display none, then you could use that to set an initial state before transition. 2. On the outboard direction, if you had the ability to animate display to maintain the display not-none <JonathanNeal> until the animation was finished, that would give you a way to do outbound animations. They are far more complicated in practice. <JonathanNeal> flackr: currently, display is explicitly not animated. There is a good reason for this. There’s no reason animations couldn’t support other display values, but not in (CSS?) animations <gregwhitworth> q? <JonathanNeal> masonf: do yo think the current proposal is incompatible with this? <JonathanNeal> flackr: it could be more simple. if we had a way to match, developers could use this other mechanism to start a transition. <JonathanNeal> flackr: it could immediately match the top layer pseudo. <JonathanNeal> flackr: the outbound direction would still need a carve-out, because it would need to remain in the top layer for targeting. <JonathanNeal> masonf: not only does it need to be in the top layer, but it needs other things. <JonathanNeal> flackr: think of it being like whether you’re allowed to have a non-display-none frame. <JonathanNeal> masonf: the open question is: do we need to solve that difficult-sounding problem? <JonathanNeal> dbaron: one thing that seems problematic about waiting for animations; if somebody has an animation on their popup that is continuous, like a spinner or something; then the popup would never go away. <JonathanNeal> dbaron: I would never get display none. <jhey> I think it's an interesting problem. It feels like the "transition" way kinda half solves it. Should it not solve it and people implement with JavaScript using "transitionend" listener? Or is there the inbound/outbound state added to :top-layer. <JonathanNeal> masonf: correct <flackr> https://github.com/w3c/csswg-drafts/issues/6429 is the issue about supporting animating display <JonathanNeal> dbaron: it might be very confusing if somebody runs into it and they don’t know why their popup is still visible. <JonathanNeal> masonf: that’s an excellent point. Developer Tools for this would be an excellent addition. <jhey> Otherwise, this question might pop up often for how to inbound/outbound the easiest way. And before the transition piece, we could kinda get the current behavior. <JonathanNeal> dbaron: I think the other option that might make it less problematic would be some combination of A. only consider animations that started after the transition started, or B. only consider animations with a finite duration. <JonathanNeal> flackr: the former (A) is how it works <JonathanNeal> dbaron: I was more worried about animations people put in their popup. That A is handled resolves that. <gregwhitworth> q? <flackr> or 1000 day transition <Zakim> dbaron, you wanted to discuss one other bug <JonathanNeal> dbaron: I might lean against doing B, knowing that A is handled. <masonf> Proposed resolution: The pop-up animation behavior will be the one described in this comment: https://github.com//issues/335#issuecomment-1168951980 <JonathanNeal> +1 <AlexanderFutekov> +1 <flackr> +1 <dbaron> +1 <masonf> RESOLVED: The pop-up animation behavior will be the one described in this comment: https://github.com//issues/335#issuecomment-1168951980 |
Based on the resolution, I'll close this one. Thanks everyone! |
Oh that’s nice! Tested in Canary (demo) and works like a charm! On a sidenote: will a similar behavior be backported to |
Glad you like it! Side note: with today's Canary, you'll need to add As for |
+1 to considering backporting this to dialog, if someone is up for it! |
Can someone confirm that this comment above matches the current spec (with I'm digging into this while evaluating if moving to I will take this opportunity to point out that although the entry animation seems to be doable using any means, the exit animation concept being built on top of |
No, that bit changed to move the The explainer and the spec PR should be up to date with the above comment. If not, please do comment back here. Does that behavior (firing
Thanks for the comment. I do agree that the API using |
Absolutely, you can add an empty animation with the expected duration. Also, in the future you could build your animation using something like the custom effect proposal from w3c/csswg-drafts#6861 (though we would need to ensure the custom effect is correctly targeted at an element within the popup). |
Yes, it does: it means that when
Currently, platform-based animations are lacking and are not always a substitute for JS-based solutions. The effect proposal mentioned by @flackr looks like a good start to fill the gap. I am concerned by its current reliance on a fixed duration, though. Other use-cases for such a primitive can be found, for example if you want to orchestrate multiple animations inside the popup before closing the popup itself. Given that an animation can be paused and completed from JS, I suppose creating a dummy empty animation is currently a work-around to animate a closing popup from JS. When reading this new spec, I couldn't help but think that the platform should have a more general way to animate things that leave the DOM. This feels like a one-shot spec for |
A fixed duration isn't strictly required. You could for example create an infinite length animation and just remove the animation when you're done.
This proposal does consider descendant animations, so as long as they are all initiated at the same time it will wait for the last one to finish. The shared element transitions API has a slightly more generous approach in that they will wait for any new animations even after previous ones finish.
I wondered this myself too, see #335 (comment) above for some thoughts there. The challenge is that with most elements the UA is not driving the process by which they become visible / go away - instead a style update or element removal triggers it. |
Now, popups will follow this process when showing/hiding: showPopup(): 1. Move the popup to the top layer, and remove the UA display:none style. 2. Update style. (Transition initial style can be specified in this state.) 3. Set the :top-layer pseudo class. 4. Update style. (Animations/transitions happen here.) hidePopup(): 1. Capture any already-running animations via getAnimations(). 2. Remove the :top-layer pseudo class. 3. Update style. (Animations/transitions start here.) 4. If the hidePopup() call is not due to a "force out" situation, getAnimations() again, remove any from step #1, and then wait here until all of them finish or are cancelled. 4. Remove the popup from the top layer, and add the UA display:none style. 5. Update style. See this issue for more details: openui/open-ui#335 Bug: 1307772 Change-Id: Ia20eb6e9533c1a0b1029ca1279d42fe2648300af Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3688871 Reviewed-by: Robert Flack <[email protected]> Commit-Queue: Mason Freed <[email protected]> Cr-Commit-Position: refs/heads/main@{#1014235} NOKEYCHECK=True GitOrigin-RevId: f659aa9aee9f710b49e821fff05896eba5aa0a5c
There has been some discussion about whether there should be a pseudoclass for the open state, and whether we can support animations on popup. Naively, if popup's show immediately applies display: block and a :visible (name TBD) pseudoclass and popup hide immediately removes both it is only possible to show an animation on open, and a transition would not work.
If we shift the timing of the display: block / none update from the pseudoclass state change we could allow transitions and animations to run. Specifically, on opening we could have a style update before :visible is applied which would trigger any transition properties. On closing, we would wait for the finished promise of any running animations before setting display: none.
This is a demo of the proposed behavior implemented in Javascript showing how this works with both css animations and css transitions: https://jsbin.com/piqebiw/edit?css,js,output
The text was updated successfully, but these errors were encountered: