- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Thu, 30 Apr 2026 15:39:38 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-position-4][css-anchor-position] Top layer exit animations require tracking a lot of state for implicit anchors`, and agreed to the following:
* `RESOLVED: Accept Keith's PR adjusting the timing, modulo editorial nits.`
<details><summary>The full IRC log of that discussion</summary>
<masonf> ntim: before top layer exit animations, there are three things to store. Invoker, invoked popover, what element invoked the popover<br>
<masonf> ...with top layer exit animations, you have to store a duplicate of those three.<br>
<masonf> ...for the last thing that was opened.<br>
<jarhar> q+<br>
<astearns> ack emilio<br>
<masonf> ...it's a lot of work to track correctly, wouldn't know how to track edge cases correctly. Especially bits about whether an element is an invoker. Do you track whether an element invoked something before?<br>
<masonf> ...spec PR only covers the other two.<br>
<astearns> ack jarhar<br>
<masonf> jarhar: why do you need to know whether an element is an invoker?<br>
<masonf> ntim: I don't know, but our code wants to know it. Because of style layout interleaving?<br>
<masonf> emilio: I don't know about webkit. Our impl is different. I think there's a lot of state to track. Timing of when you track and untrack needs to be defined.<br>
<masonf> ...need to stop styling and do layout, then go again. Don't see why offhand.<br>
<astearns> ack fantasai<br>
<jarhar> q+<br>
<lwarlow> q+<br>
<masonf> fantasai: in terms of invoker relationship, it should be maintained for the same period of time as :modal, so positioning assignments persist in the same way.<br>
<astearns> ack jarhar<br>
<masonf> jarhar: the spec PR from Keith is the right place for WebKit to do its thing.<br>
<masonf> ...I don't think Chromium has the same thing.<br>
<masonf> qq+<br>
<fantasai> <ntim> https://searchfox.org/wubkat/rev/43f24006d708eb6b9e0952d3cc4c58602cd08f7d/Source/WebCore/style/AnchorPositionEvaluator.cpp#1690-1693<br>
<masonf> ntim: if we have a check like this, then I don't know what happens if the invoker changes what popover it triggers, I don't know.<br>
<masonf> ...should it affect anything?<br>
<masonf> ...let's say it triggers another popover, while it's transitioning it out, invoker triggers another one.<br>
<masonf> q-<br>
<masonf> fantasai: change in invoker should take immediate effect. Remove the invoker because we're closing the dialog.<br>
<masonf> What if the invoked popover changes.<br>
<masonf> fantasai: you have a button and popover, what happens.<br>
<masonf> ntim: button invokes a different popover.<br>
<masonf> ntim: how would you clear the extra state.<br>
<fantasai> scribe+<br>
<fantasai> masonf: Keith's PR fixes up one thing about timing of anchor relationship<br>
<fantasai> masonf: But setting/unsetting of anchor is explicitly in the spec<br>
<fantasai> masonf: What is this extra state being tracked for?<br>
<fantasai> masonf: I didn't think we needed this extra state. What are we talking about exactly?<br>
<jarhar> q+<br>
<masonf> ntim: we have a flag to... our anchor positioning code need to know whether something was an invoker. That would change with exit animations.<br>
<astearns> ack lwarlow<br>
<masonf> lwarlow: I think chromium has the same thing as webkit. WebKit keeps track of what the button invoked, because that's how it does the implicit anchoring differently.<br>
<masonf> ...webkit thing is mostly fine. Reorder hide popover internal function, and delay them to the callback that keith's PR adds.<br>
<masonf> ...maybe Webkit needs to store a list of invoked popovers. Two popovers anchored to same popover.<br>
<masonf> ntim: button would have multiple invoked popovers at the same time.<br>
<masonf> ntim: I don't know how well that would work. But this should be specified.<br>
<masonf> lwarlow: that's an implementation detail.<br>
<masonf> astearns: is there an observable difference?<br>
<masonf> ...if you can write a test case that gives you different results at different timings. Then it needs spec.<br>
<masonf> +1 a test case would be helpful here<br>
<masonf> lwarlow: I think chromium and webkit are similar here. Spec-wise that back-reference doesn't exist. From the button to the think it's invoked.<br>
<masonf> ...I also don't think it needs to.<br>
<fantasai> +1 lwarlow<br>
<astearns> ack jarhar<br>
<masonf> jarhar: I did link (in the issue) to a flag that may be in implicit anchor, never set to false.<br>
<masonf> ...used to be a counter of implicit anchors. We don't need to spec the removal of this thing that seems to work fine.<br>
<masonf> fantasai: there's a flag in the spec?<br>
<masonf> jarhar: no in chromium<br>
<astearns> ack fantasai<br>
<masonf> astearns: my understanding is the PR that is referenced improves things.<br>
<masonf> ...would be good to have a test case.<br>
<masonf> ...one caveat - needs to be author facing. But it could be that there's a dead-end in implementation. Either Chromium or WebKit's implementation is the wrong thing. Add note to spec to guide implementations away from the dead end.<br>
<masonf> ...could we resolve on accepting the PR?<br>
<masonf> ...and then continue or open a fresh issue for Tim's concerns.<br>
<masonf> lwarlow: Keith's PR?<br>
<masonf> {yes}<br>
<masonf> fantasai: can we summarize what the PR does.<br>
<masonf> lwarlow: in the top layer spec, you can remove from top layer immediately, or set "to be removed". PR adds cleanup step to the deferred removal, so you can change state when that happens.<br>
<masonf> ...on HTML side, it removes the implicit anchor removal.<br>
<masonf> s/removes/performs<br>
<masonf> fantasai: we'd put the :modal switch from the last resolution there also?<br>
<masonf> lwarlow: yes<br>
<masonf> fantasai: why is the delay mechanism spec'd in CSS? Wouldn't HTML be better?<br>
<masonf> lwarlow: part of the top layer spec, which is in CSS.<br>
<masonf> jarhar: CSS has the top layer list, and HTML can't know what's in it<br>
<masonf> fantasai: what are we doing that is not delayed?<br>
<masonf> jarhar: popover while exiting, still needs the implicit anchor.<br>
<masonf> fantasai: we've talked about removing stuff after the delay. Why isn't HTML doing that?<br>
<masonf> ...what operation has to happen from CSS? Why two hooks?<br>
<masonf> jarhar: there is one list, in CSS. There are two hooks for different timing.<br>
<masonf> ...maybe move entire list from CSS to HTML?<br>
<masonf> lwarlow: HTML will call remove immediately, or request element. Adds to pending removals list. CSS also defines maintainance of the deferred list, which is why it's there. It depends on transitions, etc.<br>
<masonf> fantasai: list needs to be in CSS, but why two lists?<br>
<masonf> astearns: are we ok with the resolution to accept PR?<br>
<lwarlow> +1<br>
<masonf> RESOLVED: Accept Keith's PR adjusting the timing, modulo editorial nits.<br>
<masonf> astearns: test cases would be really helpful here, please.<br>
</details>
--
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13595#issuecomment-4353890738 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:39:39 UTC