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: adopt this proposal, and work out the details`

<details><summary>The full IRC log of that discussion</summary>
&lt;fremy> flackr: Display is currently not animatable<br>
&lt;fremy> flackr: mostly because none would cancel the animation<br>
&lt;fremy> flackr: but there are valid use cases<br>
&lt;fremy> flackr: my proposal is to allow animation<br>
&lt;fremy> flackr: but flip "none" when the animation reaches 100% only<br>
&lt;fremy> flackr: we would need this restriction, because web animations would allow the animation to continue even if the element goes away<br>
&lt;fremy> flackr: so, the idea is that if we interpolate between two values<br>
&lt;fremy> flackr: the non-"none" value would win<br>
&lt;fremy> astearns: what is smfr's take on this?<br>
&lt;fremy> astearns: he isn't on the call<br>
&lt;fremy> astearns: anybody can take this over for him?<br>
&lt;fremy> heycam: at first glance, this seems reasonable<br>
&lt;fremy> heycam: I can't see any reason why this would cause issues<br>
&lt;PaulG> q+<br>
&lt;fremy> TabAtkins: the fundamental problem is going from "none" to something<br>
&lt;fremy> TabAtkins: but there are also values that change box types<br>
&lt;fremy> TabAtkins: and that makes it difficult to preserve an animation across box-generation changes<br>
&lt;fremy> TabAtkins: but we could define that<br>
&lt;fremy> emilio: writing mode an direction can affect animations as well<br>
&lt;fremy> fantasai: and text-orientation<br>
&lt;fremy> fantasai: but leaving those as non-animatable seems fine<br>
&lt;fremy> TabAtkins: that categorization makes sense to me<br>
&lt;astearns> ack PaulG<br>
&lt;emilio> q+<br>
&lt;fremy> paulg: this can be usedf to keep a distracting and harmful element visible using an animation that never lets "none" apply, troll the user with an animation<br>
&lt;ydaniv> q+<br>
&lt;fremy> fantasai: a user stylesheet can disable the animation<br>
&lt;fremy> fantasai: so this wouldn't make a difference, I think<br>
&lt;fremy> fantasai: there might be bugs in user agents right now, but this is what I expect<br>
&lt;fantasai> s/I expect/is specced/<br>
&lt;fremy> PaulG: but !important would not override the animation<br>
&lt;fremy> fantasai: no, animations are in the cascade<br>
&lt;fremy> fantasai: so !important static would override the animation<br>
&lt;fremy> PaulG: so you don't have to override the animation property?<br>
&lt;astearns> ack emilio<br>
&lt;fremy> fantasai: no, the property is enough<br>
&lt;fantasai> -> https://www.w3.org/TR/css-cascade-5/#cascade-sort<br>
&lt;fremy> emilio: one question about the behavior: what happens if you put display:none on a keyframe? is that allowed?<br>
&lt;fantasai> -> https://drafts.csswg.org/css-cascade-3/implementation-report<br>
&lt;fremy> emilio: at parse time that is not allowed<br>
&lt;fremy> emilio: but you can sneak this using a custom property<br>
&lt;fremy> flackr: yes, we want to make sure some properties should stay within acceptable values<br>
&lt;heycam> q+<br>
&lt;fantasai> (Safari currently doesn't handle animations cascade correctly, but Gecko and Blink do)<br>
&lt;fremy> emilio: and if doesn't ? what would happen?<br>
&lt;fremy> flackr: I guess not having a display value<br>
&lt;fremy> emilio: so, make display:none in the animation behave as display:revert (use the value outside of the animation)<br>
&lt;fremy> emilio: we can work out the details later though<br>
&lt;fremy> flackr: there is no circularity with web animations, so display:none doesn't stop the animation<br>
&lt;astearns> ack ydaniv<br>
&lt;fremy> emilio: right<br>
&lt;fremy> ydaniv: "discrete" animation flip half-way<br>
&lt;fremy> ydaniv: can we instead flip where the author wants it?<br>
&lt;fremy> flackr: this is the second part of my proposal<br>
&lt;fremy> flackr: the value would not change, until you reach the keyframe that sets the value<br>
&lt;fremy> ydaniv: and what about other values?<br>
&lt;fremy> ydaniv: isn't it more predictible if it always behave as a flip?<br>
&lt;fremy> flackr: I think this gives less flexibility to the developers<br>
&lt;fremy> flackr: they can still choose to have the keyframes have any duration<br>
&lt;fremy> flackr: if you flip immediately, this duration is no longer something the author controls<br>
&lt;fremy> astearns: are we not concerned by using a different timing for display than other values?<br>
&lt;fremy> ydaniv: I would suppose that other wanting to go from grid to flex don't want to wait<br>
&lt;fremy> flackr: all discrete proposals behave like that<br>
&lt;fremy> TabAtkins: and you can control where that 50% happens by having another keyframe<br>
&lt;astearns> ack heycam<br>
&lt;fremy> astearns: but for none, we need something special<br>
&lt;fremy> heycam: what about transition:all?<br>
&lt;fremy> flackr: no, because all only affects non-discrete properties<br>
&lt;fremy> flackr: we could enable transitions for more, but we would probably make a new keyword<br>
&lt;fremy> astearns: any other comment on this proposal?<br>
&lt;fremy> astearns: any concern about going further?<br>
&lt;fremy> astearns: proposed resolution is to adopt and start writing the spec text<br>
&lt;fremy> astearns: any objection?<br>
&lt;fremy> RESOLVED: adopt this proposal, and work out the details<br>
&lt;fantasai> Note: this should go into display-4<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-1332439874 using your GitHub account


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

Received on Wednesday, 30 November 2022 16:37:07 UTC