[selectors][css-position-4] `:modal` pseudo-class needs to account for top layer exit animations

[nt1m]

Right now, if you don't account for exit animations, the dialog ends up shifting in position before the exit animation, due to the pseudo-class not applying. This makes me concerned about what other kinds of state we might need to persist through out exit animations too...

cc @emilio @keithamus @annevk

[emilio]

@josepharhar curious, does Blink effectively keep matching :modal until the end of the animation? That seems kinda... interesting? Definitely doesn't match the spec.

[emilio]

Should this issue be against HTML? The issue afaict is here: https://html.spec.whatwg.org/#close-the-dialog

6. If is modal of subject is true, then request an element to be removed from the top layer given subject.

7. Let wasModal be the value of subject's is modal flag.

8. Set is modal of subject to false.

At no point there's any waiting for the animation to end between 6 and 8.

[josepharhar]

Isnt this the same issue as whatwg/html#9387 which was then moved to #9912

[nt1m]

#9912 might be related. I think it doesn't solve the problem of author styles on :modal changing the position though

[emilio]

Right, I think the issue is more general that UA styles

[annevk]

cc @tabatkins

[josepharhar]

So there's two pseudo-classes you could use for top layer animations on a dialog element, :open and :modal. Right now, they both match and stop matching at the same time, right? So today (in chromium) you can make a top layer exit animation using either of those:

dialog {
  opacity: 0;
  transition: opacity 1s, display 1s allow-discrete, overlay 1s allow-discrete;
}

/* dialog:open and dialog:modal are interchangeable */
dialog:open,
dialog:modal {
  opacity: 1;
}

If we made :modal continue to match while the dialog is in the top layer, then opacity would not animate during the exit animation because it would continue to have opacity:1 match, right? Authors would have to know to use :open instead of :modal, which they might already be doing, but I'm not sure if this would break sites or not.

I think it doesn't solve the problem of author styles on :modal changing the position though

What is the use case for authors? Couldn't they put their positioning styles on dialog even when it is closed? The reason that I added the :-internal-dialog-in-top-layer pseudo-class in chromium is because we have to differentiate between modal and non-modal dialogs, which is something that I don't imagine authors will be doing.

[css-meeting-bot]

The CSS Working Group just discussed [selectors][css-position-4] `:modal` pseudo-class needs to account for top layer exit animations, and agreed to the following:

• RESOLVED: continue to match :modal until the dialog is removed from the top layer

The full IRC log of that discussion

<masonf> ntim: we have :modal pseudo class. UA stylesheet has rules that change the positioning of the dialog for modal dialogs.
<masonf> ...when you exit top layer with an animation, there's a shift because :modal stops applying.
<masonf> ...since we put positioning rules on it, the position changes.
<jarhar> q+
<masonf> ...Joey had a PR to address that by persisting the positioning UA styles through the transition, but I'm not sure about that.
<masonf> ...you could put negative margin, or use anchor positioning, etc.
<masonf> ...using the :modal pseudo class.
<masonf> ...we need to persist the position somehow when you exit.
<emilio> q+
<lwarlow> q+
<astearns> ack jarhar
<masonf> jarhar: alternatives are: make :modal continue to match, do the secret thing where UA styles magically keep applying,
<masonf> ...authors aren't using :modal for those styles. There's a chance of breakage. But likely not a big deal.
<masonf> ...if you think we should make :modal keep matching until it is out of the top layer, it's probably ok, but there's a risk.
<masonf> ...I'm happy to go that way, if you do the spec PRs and stuff plus MDN documentation that explains the difference between :modal and :open, because now they'll be different.
<RobAtADP> is there a similar issue with popovers in the top-layer?
<masonf> ntim: it's more general. If you use :open and set position, you'll have the same problem.
<masonf> ...if you use :open to shift the positioning, you'll get the same issue.
<masonf> ...don't know how to solve it.
<astearns> ack emilio
<masonf> emilio: the idea is that you still want :open to get removed eagerly, because that triggers the transition.
<masonf> ...it feels awkward. You could use :open to style it, but why. I think keeping matching :modal makes sense. Map :modal to "is in the top layer". That makes sense.
<masonf> ...is there any drawback to that? Other than behavior change.
<astearns> ack lwarlow
<masonf> lwarlow: there's a PR for the CSS spec for top layer, which adds a cleanup steps callback when removing from top layer. Also PR to HTML spec for popovers to remove implicit anchors in the same callback.
<masonf> ...we could also use that for :modal changes here.
<masonf> ...that's the right spec solution for this.
<masonf> ...I don't think that'll cause compat problems in practice.
<jarhar> q+
<masonf> ...except moving from static to and from top layer. But likely not doing that with dialogs.
<masonf> ...making :open false and :modal true during the animation seems ok.
<astearns> ack jarhar
<emilio> q+
<masonf> jarhar: reason this is a problem for UA styles is that we're differentiating the positioning.
<masonf> ...less of an issue for authors. Wouldn't use the same dialog for modal and non-modal. Wouldn't run into this issue where we want different positioning based on modality.
<masonf> ...wouldn't put positioning code in open or modal, then wouldn't run into this problem.
<astearns> ack emilio
<astearns> q+
<masonf> emilio: I'd prefer to solve it without magic. Applying modal until end of animation seems straightforward.
<masonf> ...if authors aren't using :modal then why did we expose it? But we have it, and we need it for the UA sheet. Doesn't seem unreasonable that developers use it also.
<masonf> ...framework like Bootstrap might be doing that.
<masonf> ...modal dialog then center it, otherwise don't. You could add a class, but ideally you use pseudo classes.
<masonf> astearns: UA styling that has an issue with this: it's ok to have :modal have different timing than :open because :modal might be used for positioning, and :open isn't likely to. Somewhere in UA stylesheet we have positioning in :modal. Should it be there?
<masonf> lwarlow: we can't because of compat. Non-modal dialogs are positioned differently than modals.
<masonf> jarhar: need :is-open-but-not-modal
<emilio> q+
<emilio> ack astearns
<masonf> astearns: Some folks are saying that changing the timing of :modal is a good fix. Tim, concerned that this applies to :open. Ok with just this fix?
<astearns> ack astearns
<masonf> ntim: yeah
<masonf> ...hoping someone can implement and report back.
<masonf> emilio: should treat fullscreen pseudo class the same way. That also does similar things.
<masonf> ...position fixed, inset 0, yada yada
<masonf> ...to me :modal and :fullscreen are parallel. Ok with resolution for :modal. I think :fullscreen should get attention.
<masonf> ...also not as important, screen flashes anyway.
<masonf> astearns: anyone want to change :fullscreen right now?
<masonf> Proposed resolution: change :modal timing to wait until exit animation is done
<jarhar> proposed resolution: continue to match :modal until the dialog is removed from the top layer
<masonf> emilio: details of the timing have nuance, e.g. no animation.
<masonf> RESOLVED: continue to match :modal until the dialog is removed from the top layer
<lwarlow> Here's keiths PR that adds the relevant hooks: https://github.com/whatwg/html/pull/11695