- From: Tim Nguyen via GitHub <sysbot+gh@w3.org>
- Date: Fri, 28 Apr 2023 18:36:14 +0000
- To: public-css-archive@w3.org
> Yes, actually removing an element from the top layer bypasses anything that overlay might do. That's why access to the top layer is now gated behind several algorithms that "do the right thing" - you can modify the top layer directly still, but if you "request removal" it will just remove the overlay rule (reverting it to the default none, but possibly triggering a transition that keeps it as auto for a bit) and put it in the pending removals list. Then in "process top layer removals" we check if the element is both (a) pending removal, and (b) overlay:none before actually removing it from the top layer. This makes sense, thanks. > The 'overlay' property exists to allow authors to signal they want to delay removal from the top layer for some amount of time, by adding a transition. That's all it does. OK that clears up a lot of things, thanks. I assumed there was also a way to delay the entry based on the name of the other issue (entry/exit transitions for top layer), but thinking about it, I guess that use case isn't terribly useful. Thanks for the clarifications! Makes it easier to review the proposal. -- GitHub Notification of comment by nt1m Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8730#issuecomment-1527945980 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 28 April 2023 18:36:16 UTC