- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 08 Mar 2023 17:29:28 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed ``[css-display] Interaction gotchas when delaying the effect of `display: none` ``, and agreed to the following: * `RESOLVED: inertness is determined by the base computed style for 'display', resulting in animations to 'none' being considered inert` <details><summary>The full IRC log of that discussion</summary> <fantasai> flackr: Using display to animate from block to none<br> <fantasai> flackr: this has effect that during animation, the element can still be interacted with and is in the a11y tree<br> <fantasai> flackr: it has problems with e.g. form submission, coudl accidentally submit twice because animating out<br> <fantasai> flackr: proposed resolution is that we look at the base value of the display property, i.e. the value before animation is apply<br> <fantasai> flackr: when animating to none, base value woudl be none<br> <fantasai> flackr: use that to determine whether the element should be in the a11y tree<br> <fantasai> flackr: and also effectively make it inert while it's none<br> <fantasai> flackr: longer-term, we might want to have inert be a CSS property, and this would be part of auto behavior for inert<br> <PaulG> +1 (from APA_<br> <TabAtkins> +1 frome me<br> <fantasai> flackr: but this would be for doing the right thing in the simple cases<br> <masonf> +1<br> <fantasai> +1 to "make it work like expected without author fussing"<br> <bramus> +1<br> <emilio> +1 as long as there are tests for this<br> <fantasai> flackr: [re-explains proposal]<br> <fantasai> Rossen: There was some work that was already happening around inert, curious if your proposal has any tracking with that work<br> <emilio> q+<br> <fantasai> Rossen: I'm sure inert as CSS property was considered and debated at some point in the past, I'm not sure where we ended up, but would be good to have a tracking issue or at least track that discussion<br> <chrishtr> Link to prior discussion: https://github.com/w3c/csswg-drafts/issues/8389#issuecomment-1419970151<br> <fantasai> chrishtr: Link to pros and cons<br> <fantasai> chrishtr: my understanding from previous discussion was that no one had strong opinions, and the door was open to adding it in the future<br> <fantasai> Rossen: that answers my question<br> <fantasai> chrishtr: We can do this thing for now, so by default it does the right thing<br> <fantasai> chrishtr: and if there's significant developer need, we can add 'inert' in the future without too much trouble<br> <astearns> ack emilio<br> <fantasai> flackr: yes, this is designed to be forwards-compatible with that<br> <fantasai> emilio: I was thinking about this, inert has this feature where some elements that escape inert-ness<br> <fantasai> emilio: e.g. modal dialog that's now 'display: none', that will not be inert<br> <fantasai> emilio: but 'display: none' would prevent modal dialog from showing<br> <flackr> qq+<br> <fantasai> emilio: this looks almost like inert, but with that thing where we may not want subtrees to escape inertness?<br> <fantasai> chrishtr: if you have [scenario]<br> <astearns> ack flackr<br> <Zakim> flackr, you wanted to react to emilio<br> <fantasai> flackr: the auto behavior is based on the computed base style of 'display', which even for the descendant would be 'none'<br> <fantasai> emilio: not really, display is not inherited<br> <fantasai> flackr: but it's within an element with a computed base display style of 'none'<br> <TabAtkins> display may not be inherited, but display-none-ness *basically* is<br> <masonf> modal dialog inside a display:none subtree is already display:none.<br> <fantasai> emilio: the way inert is implemented, at least in WebKit and Gecko, basically it's an internal inherited bit in the computed style representation<br> <fantasai> emilio: there are things that can flip that for a subtree<br> <fantasai> emilio: when you have fullscreen element, everything is inert except fullscreen element subtree<br> <oriol> Blink also uses that approach<br> <fantasai> emilio: this inert, we don't want it to be overridden by anything inside the subtree<br> <fantasai> flackr: even if overridden, this proposal would fix the common cases<br> <fantasai> flackr: but if we did allow overriding, you would have these edge cases where the things animating to 'display: none' would not include modal dialog<br> <fantasai> emilio: this proposal helps a lot for ?? cases<br> <fantasai> emilio: just an edge case that might be better to explicitly point out?<br> <fantasai> emilio: "inert, but actually force inertness for the entire subtree"<br> <fantasai> flackr: sounds like something we could consider if we add a CSS property for inertness<br> <fantasai> flackr: I think there are use cases for opting subtree<br> <fantasai> emilio: if we add inert, it would be similar to visibility, can set it differently inside a subtree<br> <fantasai> emilio: might have use cases for inert unable to flip within the subtree<br> <fantasai> emilio: probably the spec should call out this edge case, and define the behavior explicitly<br> <astearns> ack fantasai<br> <fantasai> emilio: if you have fullscreen element inside, define that behavior<br> <emilio> fantasai: for visibility: hidden you can flip back to visible, but visibility: collapse into a flex item doesn't allow you to do that<br> <fantasai> astearns: ready to resolve?<br> <emilio> ... so visibility has that behavior as well<br> <fantasai> s/.../fantasai:/<br> <fantasai> flackr: inertness is determined by the base computed style for 'display', resulting in animations to 'none' being considered inert<br> <fantasai> astearns: can make that claim generally, not just during animations?<br> <fantasai> flackr: base computed style is all styles before animations<br> <fantasai> astearns: any other comments or concerns?<br> <fantasai> RESOLVED: inertness is determined by the base computed style for 'display', resulting in animations to 'none' being considered inert<br> <fantasai> astearns: +1 to having tests for this<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8389#issuecomment-1460542364 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 8 March 2023 17:29:30 UTC