[Popup] Supporting transitions and animations on open and dismiss

[flackr]

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

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: 'Display' eventWorklet; or onDisplayChanging: eventWorklet;.

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 animationend event to either remove or add display: none on the element.

[flackr]

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: 'Display' eventWorklet; or onDisplayChanging: eventWorklet;.

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.

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.

[gregwhitworth]

This was discussed in today's telecon with the following resolution:

RESOLUTION: popups have an intermediate state where they are display: block but not yet :open which they transition to when showing / hiding. On hiding, the UA will wait for ongoing animations before setting display: none.

Minutes are here

[github-actions]

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.

[mfreed7]

With the new Popup proposal (#455), the UA does not force-hide the popup when it is not "showing". The UA has a display: none rule without !important, meaning it can be overridden. Given that behavior, popups can be animated in both directions:

• Animating the "show" is easy - just add an animation in a :popup-open pseudo selector:

[popup]:popup-open {
  animation: {whatever you like};
}

• Animating the "hide" requires Javascript, but not too much:

<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.