- From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
- Date: Tue, 16 May 2023 23:08:31 +0000
- To: public-css-archive@w3.org
I've made a minor change - "rendered in the top layer" now checks both that it's in the top layer list *and* has overlay:auto. The only effect of this is that entry animations are now possible, as you can delay the none->auto transition to keep the element displaying in the page normally for a little bit. I've adjusted the language in the `overlay` section to make the effects clearer. This brings up a new possibility, tho. If authors can delay the element both leaving *and* entering the top layer, I'm not sure the "only set by the UA" is important any longer. At this point, the spec's model is essentially "the UA and the author can both signal whether they want the element in the top layer or not, and it only changes state when both agree". (The UA signals by putting something in the top layer list or the pending top layer removals list; the author signals by controlling 'overlay'.) As currently written, tho, the "`overlay` is only set by the UA; author can control by using a transition" is a little awkward. The entire purpose of setting a transition in the first place is to align it with an animation, but that means you have to, well, align a transition and an animation. I don't think this restriction ends up buying us anything, tho. If we just let the author set `overlay` normally, then they can set it *in the animation* and have it change at the desired time, alongside the rest of the animation, so they only have to maintain the entry/exit animation in one place. The model is robust enough now that I don't think we're not protecting the author from anything important by not letting them set `overlay`. At *worst* an author could set `overlay: none` unconditionally to prevent anything from rendering in the top layer, or set `overlay: auto` unconditionally to prevent anything from leaving the top layer. (And they can do either of these already, by using an extremely long transition-duration.) I think the first isn't worth protecting against (it just means that they're preventing some features from working at all for themself, which isn't a security issue), and the second can be addressed in the same way as is currently allowed - give UAs the ability to just remove something from the top layer list, for example if it stays in the pending-removals list for too long. So do we want to remove that restriction, and make the UA-set `overlay` value normal, rather than `!important`? -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8730#issuecomment-1550470875 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 16 May 2023 23:08:33 UTC