Re: [csswg-drafts] [css-display] Why is display listed as not animatable instead of animation type: discrete? (#6429)

The CSS Working Group just discussed `[css-display] Why is display listed as not animatable instead of animation type: discrete?`, and agreed to the following:

* `RESOLVED: When an animations produces display none it continues to run but it still cancels animations within that subtree.`

<details><summary>The full IRC log of that discussion</summary>
&lt;bramus> flackr: Ill take this<br>
&lt;bramus> flackr: we resolved to make display animatable but tried to prevent two values of none being animated, but there were lot of edge cases like variables<br>
&lt;bramus> flackr: also problem with animate content on pseudos<br>
&lt;fantasai> TabAtkins, your proposed &lt;position> syntax has multiple errors so, no. ^_^<br>
&lt;bramus> flackr: if you animate ocntent, it destroys the pseudo<br>
&lt;bramus> flackr: added something to css-animations-2 that we only cancel animations if the computed value of display and the value of display before the animoatins cascade is none<br>
&lt;bramus> flackr: if an animt produces display none so it continues to run instead of restarting<br>
&lt;emilio> q+<br>
&lt;bramus> flackr: beahves like develoeprs expect it to work<br>
&lt;bramus> flackr: also consistent with content animations in firebox<br>
&lt;bramus> emilio: not sure is content behavior in firefox is intentiional<br>
&lt;bramus> emilio: how does this interact with nested elems?<br>
&lt;bramus> emilio: presumably we want to cancel animations deep in display none subtrees<br>
&lt;bramus> flackr: good q<br>
&lt;bramus> flackr: I think there is no lifetime issue if we want to cancel anims in nested elements<br>
&lt;bramus> flackr: i would be fine with saying that behaviour should only look at the style without local animaotins and the ancestor style can include all animated styles<br>
&lt;bramus> emilio: not sure if i follow<br>
&lt;bramus> emilio: when the display value becomes ?? – I think blink also has a mechanism to clear stuff down the tree?<br>
&lt;bramus> emilio: presumably we cancel animations then?<br>
&lt;bramus> flackr: in blink the anims are associated with the element so we can still remove all of the layout structured associated with it<br>
&lt;bramus> flackr: q is if animations keep on living<br>
&lt;bramus> flackr: and if their time restarts or not<br>
&lt;bramus> flackr: we still need to keep computed style for to plevel display none elem to know it is display none<br>
&lt;bramus> flackr: so i thikn that nested elements should just be cancelled to reduce overhead<br>
&lt;bramus> emilio: i think we should cancel them, eys<br>
&lt;bramus> s/eys/yes/<br>
&lt;bramus> emilio: need to specify when that happens?<br>
&lt;bramus> flackr: spec needs a slight change to reflect that it doesnt apply to nested elements<br>
&lt;bramus> flackr: can do an update<br>
&lt;bramus> emilio: OK<br>
&lt;bramus> flackr: Proposed resolution; when an animations produces display none it continues to run but it still cancels animations within that subtree<br>
&lt;bramus> Rossen_: Objections? Qs?<br>
&lt;bramus> RESOLVED: When an animations produces display none it continues to run but it still cancels animations within that subtree.<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6429#issuecomment-1561562367 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 24 May 2023 16:40:17 UTC