- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Tue, 11 Jun 2024 08:31:30 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-anchor-1] position-visibility show/hide animations`, and agreed to the following: * `RESOLVED: when position visibility hides something, it does so by causing the visibility property to compute to a new force-hidden value` <details><summary>The full IRC log of that discussion</summary> <emeyer> TabAtkins: While doing implementation work, Philip noted authors probably want to animate elements disappearing and reappearing<br> <emeyer> …How do we do it? Philip proposed properties for that<br> <emeyer> …My proposal is to have position visibility change the computed value, and key off of that to do transitions<br> <kizu> q+<br> <emeyer> …Either of these are potentially doable, but Roma has a comment just posted<br> <astearns> ack kizu<br> <emeyer> kizu: The only thing I think we don't have is an entry animation<br> <emeyer> …There's no way to hook on to when that fires<br> <emeyer> TabAtkins: That's reasonable, and it points to a larger use case which is the ability to trigger an animation on a transition starting<br> <emeyer> …That seems generically useful for several cases and would avoid needing new properties<br> <emeyer> fantasai: Making that happen would let you control the flip point, but it won't give you the ability to animate things like color without JS<br> <astearns> ack fantasai<br> <emeyer> TabAtkins: Correct; doing more would require other things, but this seems like a big enough request for us to do<br> <futhark> q+<br> <emeyer> …I've thought about ways to trigger state properties and would be willing to defer animation in order to consider that, but I could see us doing this for properties now and considering the generic solution later<br> <astearns> ack futhark<br> <emeyer> futhark: Isn't this quite simlar to the overlay property for popovers?<br> <emeyer> TabAtkins: The reason we mess with the overlay state is so it stays consistent across things that can't be described in the CSS<br> <emeyer> TabAtkins: Did we just trigger off a DOM state?<br> <emeyer> futhark: Yeah, but we don't have that possibility here<br> <kizu> q+<br> <emeyer> TabAtkins: I could go dig up my old notes, but do we want to defer this for a little while to make a more informed decision?<br> <astearns> ack kizu<br> <emeyer> kizu: I think we can defer<br> <bramus> q+<br> <astearns> ack bramus<br> <emeyer> bramus: Want to mention that a lot of authors have been aasking to trigger view transitions on a state change, such as clicking on an input<br> <khush> q+<br> <emeyer> TabAtkins: Good point - we might be able to rely on subscribing to a transition, but that might be a frame delay<br> <astearns> ack khush<br> <emeyer> khush: Since you said it's a state transition, I was thinking of exposing it as a pseudo-class<br> <emeyer> …The only thing is, you dn't want anyone to put in a position change<br> <emeyer> TabAtkins: We can't generally do an allow/block list due to circular references, but you can certainly already cause those with :hover<br> <emeyer> …We consider that acceptable, so it would probably be okay to not restrict and assume authors won't do things that make the experience awful for their users<br> <emeyer> astearns: Sounds like we're going to defer for now, evaluate a more general solution, and decide if the general solution can be implemented in time<br> <emeyer> TabAtkins: Should we resolve to do this and leave them open as hooks for later?<br> <emeyer> fantasai: I think that's a good idea, but I'd want to ensure that will work with inheritance<br> <astearns> s/this/visibility/<br> <TabAtkins> s/do this/do the visibility:strongly-hidden thing/<br> <emeyer> …Probably want a better word than strongly hidden<br> <emeyer> TabAtkins: That sounds reasonable<br> <emeyer> TabAtkins: Proposing that when position visibility hides something, it does so by causing the visibility property to compute to a new forced-hidden value<br> <ydaniv> q+<br> <fantasai> "Making an element strongly hidden makes it act as if it and all of its descendants were visibility: hidden, regardless of what their actual visibility value is."<br> <astearns> ack ydaniv<br> <emeyer> astearns: My question is: can authors use this forced-hidden value?<br> <fantasai> s/forced-hidden/force-hidden/<br> <fantasai> s/forced-hidden/force-hidden/<br> <kbabbitt> q+<br> <emeyer> ydaniv: If we have a value, we could do it with container style queries, right?<br> <astearns> ack kbabbitt<br> <emeyer> TabAtkins: Yes. I'm not super familiar with the limitations on style queries but it should still be available<br> <emeyer> kbabbitt: What's the interaction between this and !important on a descendant<br> <fantasai> container style queries query the parent of the element you're styling, so it's not quite ideal, but could do some stuff with it<br> <emeyer> TabAtkins: If your ancestor is force-hidden, you're force-hidden<br> <emeyer> …It's a display: none without blowing away the boxes<br> <emeyer> …So they still take up the space<br> <emeyer> fantasai: We might want a value that keeps the boxes but doesn't display them<br> <emeyer> TabAtkins: Maybe<br> <fantasai> s/might/might also/<br> <emeyer> astearns: Anyone who would prefer to wait and digest before resolving?<br> <fantasai> s/doesn't display them/takes them out of flow/<br> <fantasai> s/of flow/of flow while not displaying them (more similar effect to display:none)/<br> <astearns> Proposing that when position visibility hides something, it does so by causing the visibility property to compute to a new forced-hidden value<br> <fantasai> "force-hidden"<br> <emeyer> astearns: RESOLVED: when position visibility hides something, it does so by causing the visibility property to compute to a new force-hidden value<br> <emeyer> RESOLVED: when position visibility hides something, it does so by causing the visibility property to compute to a new force-hidden value<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/10182#issuecomment-2160114879 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 11 June 2024 08:31:31 UTC