- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 11 Jan 2023 17:41:11 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `Entry and Exit Animations for top-layer elements`. <details><summary>The full IRC log of that discussion</summary> <fantasai> Topic: Entry and Exit Animations for top-layer elements<br> <fantasai> github: https://github.com/w3c/csswg-drafts/issues/8189<br> <fantasai> flackr: When certain elements go in/out of top layer<br> <fantasai> flackr: if devs want to have an naimation on the, they need the element to remain in the top layer for duration of the animation<br> <fantasai> flackr: so proposal is that we allow specifying top layer in the transition properties<br> <fantasai> flackr: but that it's otherwise not a developer-stylable property<br> <fantasai> flackr: essentially, you can specify transition: top-layer<br> <fantasai> flackr: and give it a duratoin<br> <fantasai> flackr: and this is the duration during which the element stays in the top layer<br> <Rossen_> q?<br> <ntim> q+<br> <Rossen_> ack ntim<br> <fantasai> ntim: I've always been against the top-layer CSS property concept<br> <fantasai> ntim: The concept should really stay abstracted away from the developer<br> <fantasai> ntim: even just introducing this property is a bad first step, I think<br> <lea> q?<br> <lea> q+<br> <emilio> q+<br> <fantasai> lea: I wanted to as ntim why he thinks this concept should be abstracted away from the developer<br> <fantasai> lea: there's a lot of reasons it should controllable in CSS<br> <Rossen_> ack lea<br> <fantasai> lea: we keep seeing use cases that could be solved if could be controlled in CSS<br> <fantasai> ntim: If you allow controlling top layer with CSS, you end up with same issues as z-index<br> <fantasai> ntim: the appeal of top layer right now is that it's controlled by order of JS API calls<br> <lea> q?<br> <flackr> q+<br> <fantasai> ntim: but once you start allowing random elements to put top-layer, then what order is actually used in the end?<br> <fantasai> lea: I think that depends on how we design the feature<br> <fantasai> lea: maybe it's a property that just the UA controls<br> <fantasai> lea: though I hope to avoid that<br> <fantasai> ntim: I think it needs a real design<br> <fantasai> ntim: just exposing this concept...<br> <chrishtr> Note that the proposal is not incompatible with ntim's concern. I agree with his concern.<br> <fantasai> lea: yes, absolutely, does need design work to do it properly to not have problems of z-index<br> <fantasai> lea: total +1 to that<br> <lea> q?<br> <Rossen_> ack emilio<br> <fantasai> emilio: I don't think I have a strong feeling wrt top layer property<br> <fantasai> emilio: but basically the use case seems to be transitioning modal dialogs and so on when opening and closing<br> <fantasai> emilio: and I assume other elements in the top layer<br> <fantasai> emilio: to me that seems like a use case that non-modal dialogs also need<br> <fantasai> emilio: there are dialogs that may not be in the top layer<br> <fantasai> emilio: so feels to me that this is a clever hack to avoid having closing/closed state on the dialog and fullscreen things<br> <fantasai> emilio: not sure if that's been considered<br> <fantasai> emilio: so why is this property better<br> <fantasai> emilio: why not say that it goes from open to non-open, have an intermediate state, and define that intermediat state transition as when all its transitions have finished<br> <Rossen_> ack flackr<br> <fantasai> flackr: Wrt tim's concern about exposing top-layer to the user, we have these stackign questions<br> <fantasai> flackr: this proposal nicely avoids, because things remain in their current stacking position<br> <fantasai> flackr: so we don't have to change any of that or figure out those definitions yet<br> <fantasai> flackr: I don't understand what non-modal dialogs have a problem, they can continue to apply their desired z-index<br> <fantasai> emilio: but you still have the issue of if you want a close animation on a dialog, you need to do it manuall<br> <Rossen_> q?<br> <fantasai> flackr: dialog element, which is top-layer?<br> <fantasai> emilio: dialog may or may not be top layer depending on show vs showModal<br> <masonf> If the dialog isn't modal, it isn't in the top layer, and you don't need this.<br> <fantasai> flackr: It would maintain its top layer state during transition, but still have to define the animation<br> <chrishtr> q+<br> <fantasai> emilio: idea is you can do opacity or transform or whatever to hide the dialog, right?<br> <fantasai> emilio: right now that's not easy to do with non-modal dialogs either<br> <fantasai> emilio: why not have ...<br> <fantasai> emilio: Firefox has all its panels as well, we have animations when you use menus<br> <fantasai> emilio: and those are just web elements<br> <fantasai> emilio: internally we have 5 states<br> <fantasai> emilio: open, opening, closing, closed<br> <fantasai> emilio: we ahve intermediate states so that the front end can actually use transitions for this stuff<br> <fantasai> emilio: my question is, why is this specific to top-layer and not to elements that pop in and out<br> <fantasai> flackr: you can't reasonably establish entry animations is resolved by setting inital styles<br> <fantasai> flackr: with that, should be possible to do on non-modal dialogs<br> <fantasai> flackr: top-layer is the only thing they don't have access to<br> <fantasai> flackr: the model is consistent with other things taht have a state change trigger an animation<br> <fantasai> flackr: state changes immediately, even though animation continues to run<br> <masonf> non-modal dialogs need the ability to animate to/from display:none, but that's a separate issue.<br> <fantasai> emilio: when non-modal dialog closes, you want to ?? animation to displaY:none<br> <fantasai> emilio: you transitoin display, which we resolved to do but don't yet do<br> <fantasai> emilio: so your proposeal would be to animation display directly and also transition opacity<br> <fantasai> flackr: I have proof of concept for Chrome<br> <lea> q?<br> <fantasai> emilio: so this proposal is to explicitly allow z-order to remain while transitioning<br> <lea> q+<br> <fantasai> emilio: like transitioning display<br> <fantasai> emilio: on one hand, I thin it would be less weird to have these intermediate states<br> <fantasai> emilio: when you open dialog, you transition to opening state<br> <fantasai> emilio: when you update style and don't have transitions running you're open<br> <fantasai> emilio: etc.<br> <fantasai> emilio: when no pending ransitions transition to closed<br> <fantasai> emilio: only targetted to dialogs/popovers/etc. but I think that's the main use case<br> <fantasai> emilio: I think that would be slightly less weird for authors<br> <fantasai> emilio: rather than transitioning display ...<br> <fantasai> emilio: having magic property seems weird<br> <fantasai> emilio: I guess this proposal weird, but I think maybe having intermediate pseudo-classes could be more elegant and usable for authors<br> <fantasai> flackr: I think this is more consistent with other state changes for the Web<br> <Rossen_> ack fantasai<br> <fantasai> fantasai: why not have things just stay in the top layer until their transitions are done automatically?<br> <fantasai> ntim: That seems to make sense<br> <fantasai> chrishtr: Having a transitioning state and this automatically detect what they're happening and preserve top layer during UA was thoroughly explored during popover design<br> <fantasai> chrishtr: and prototyped in Chromium<br> <fantasai> chrishtr: was specific to popover and dialog, and why not have a generic mechanism in animations<br> <fantasai> chrishtr: this is what lead to these proposals for display:none animations and specifying top-layer duration<br> <fantasai> chrishtr: without specifying UA magic to detect length of animations<br> <Rossen_> ack chrishtr<br> <ntim> q+<br> <fantasai> chrishtr: discussed at length in popover API proposal<br> <Rossen_> ack lea<br> <fantasai> lea: firstly, it seems weird to have a property that only works in transitions<br> <fantasai> lea: if devs want to put things in the top layer, what prevents them from adding an animation that puts them in the top layer?<br> <fantasai> emilio: ....<br> <fantasai> lea: so only available in transitions?<br> <fantasai> lea: what prevents having a transition that lasts 999999s?<br> <fantasai> emilio: you'd need to call modal<br> <fantasai> lea: trying to prevent devs by adding only to transitions, it's a hack and can be worked around<br> <fantasai> emilio: I agree<br> <Rossen_> q?<br> <fantasai> emilio: internally, how we implement top layer<br> <fantasai> emilio: I'm not sure how I feel about this<br> <flackr> q+<br> <fantasai> [missed]<br> <fantasai> Rossen_: let's end this topic right here<br> <fantasai> Rossen_: we coered quite a bit, but this doesn't seem ready for resolution<br> <fantasai> Rossen_: was well articulated and proposed, and good path forward for addressing some of the TAG review comments<br> <fantasai> Rossen_: shoudl take conversation back to GH, and should bring it back when it's more developed<br> <flackr> q-<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8189#issuecomment-1379252857 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 11 January 2023 17:41:13 UTC