- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Thu, 30 Apr 2026 15:19:38 +0000
- To: public-css-archive@w3.org
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` <details><summary>The full IRC log of that discussion</summary> <masonf> ntim: we have :modal pseudo class. UA stylesheet has rules that change the positioning of the dialog for modal dialogs.<br> <masonf> ...when you exit top layer with an animation, there's a shift because :modal stops applying.<br> <masonf> ...since we put positioning rules on it, the position changes.<br> <jarhar> q+<br> <masonf> ...Joey had a PR to address that by persisting the positioning UA styles through the transition, but I'm not sure about that.<br> <masonf> ...you could put negative margin, or use anchor positioning, etc.<br> <masonf> ...using the :modal pseudo class.<br> <masonf> ...we need to persist the position somehow when you exit.<br> <emilio> q+<br> <lwarlow> q+<br> <astearns> ack jarhar<br> <masonf> jarhar: alternatives are: make :modal continue to match, do the secret thing where UA styles magically keep applying,<br> <masonf> ...authors aren't using :modal for those styles. There's a chance of breakage. But likely not a big deal.<br> <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.<br> <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.<br> <RobAtADP> is there a similar issue with popovers in the top-layer?<br> <masonf> ntim: it's more general. If you use :open and set position, you'll have the same problem.<br> <masonf> ...if you use :open to shift the positioning, you'll get the same issue.<br> <masonf> ...don't know how to solve it.<br> <astearns> ack emilio<br> <masonf> emilio: the idea is that you still want :open to get removed eagerly, because that triggers the transition.<br> <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.<br> <masonf> ...is there any drawback to that? Other than behavior change.<br> <astearns> ack lwarlow<br> <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.<br> <masonf> ...we could also use that for :modal changes here.<br> <masonf> ...that's the right spec solution for this.<br> <masonf> ...I don't think that'll cause compat problems in practice.<br> <jarhar> q+<br> <masonf> ...except moving from static to and from top layer. But likely not doing that with dialogs.<br> <masonf> ...making :open false and :modal true during the animation seems ok.<br> <astearns> ack jarhar<br> <emilio> q+<br> <masonf> jarhar: reason this is a problem for UA styles is that we're differentiating the positioning.<br> <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.<br> <masonf> ...wouldn't put positioning code in open or modal, then wouldn't run into this problem.<br> <astearns> ack emilio<br> <astearns> q+<br> <masonf> emilio: I'd prefer to solve it without magic. Applying modal until end of animation seems straightforward.<br> <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.<br> <masonf> ...framework like Bootstrap might be doing that.<br> <masonf> ...modal dialog then center it, otherwise don't. You could add a class, but ideally you use pseudo classes.<br> <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?<br> <masonf> lwarlow: we can't because of compat. Non-modal dialogs are positioned differently than modals.<br> <masonf> jarhar: need :is-open-but-not-modal<br> <emilio> q+<br> <emilio> ack astearns<br> <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?<br> <astearns> ack astearns<br> <masonf> ntim: yeah<br> <masonf> ...hoping someone can implement and report back.<br> <masonf> emilio: should treat fullscreen pseudo class the same way. That also does similar things.<br> <masonf> ...position fixed, inset 0, yada yada<br> <masonf> ...to me :modal and :fullscreen are parallel. Ok with resolution for :modal. I think :fullscreen should get attention.<br> <masonf> ...also not as important, screen flashes anyway.<br> <masonf> astearns: anyone want to change :fullscreen right now?<br> <masonf> Proposed resolution: change :modal timing to wait until exit animation is done<br> <jarhar> proposed resolution: continue to match :modal until the dialog is removed from the top layer<br> <masonf> emilio: details of the timing have nuance, e.g. no animation.<br> <masonf> RESOLVED: continue to match :modal until the dialog is removed from the top layer<br> <lwarlow> Here's keiths PR that adds the relevant hooks: https://github.com/whatwg/html/pull/11695<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13594#issuecomment-4353739561 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 30 April 2026 15:19:39 UTC