[css-color-adjust] Animation type of forced-color-adjust

[andruud]

Since forced-color-adjust is quite special in that its computed value determines cascade-time behavior, does it make sense to "dampen" some of this complexity by making the property 'not animatable'?

I noticed that direction and writing-mode are 'not animatable', and they are involved in a similar computed-value-time/cascade-time interaction.

I'm just wondering if we should err on the side of less complexity for weirdo-properties like forced-color-adjust :-). Just a thought. cc @fantasai

[fantasai]

Makes sense to me. Agenda+ to ask the WG what they think; this is primarily a question for implementers. :)

[css-meeting-bot]

The CSS Working Group just discussed [css-color-adjust] Animation type of forced-color-adjust, and agreed to the following:

• RESOLVED: make forced-color-adjust not animatable

The full IRC log of that discussion

<dael> Topic: [css-color-adjust] Animation type of forced-color-adjust
<dael> github: https://github.com//issues/5342
<dael> Rossen_: Raised by anders, not sure if he's on
<dael> iank_: Middle of the night for them
<dael> AmeliaBR: I think it's straight forward
<dael> Rossen_: Curious if we needed to ask their input
<dael> fantasai: Summary: In general we allow pretty much any prop to be animated. A couple we don't b/c have particular inpacts on cascade or animations. Direction and writing mode are not b/c cascade-time interactions.
<dael> fantasai: forced-color-adjust also has cascade implications so proposal is mark as not animatable. I don't know of a use case for animatable so should be fine
<dael> AmeliaBR: Agree, not worth complexity
<florian> +1
<dael> Rossen_: Yeah. We've never seen use case for it
<dael> Rossen_: Any reasons why we should make it animatable? If not objections?
<dael> myles: Suprised at reasoning for it being more complicated to not animate. THis is fit for switch halfway through
<dael> AmeliaBR: Getting special rules for lots of other properties like bg color is doing thing based on if you have f-c-a on. Not a simple dependency like currentColor, lots of rules for other properties
<dael> fantasai: If there's an impl that thinks this should be not animatable we should make it animatable. If all impl think it should animate than leave it.
<fantasai> s/animatable/not animatable/
<fantasai> s/than/then/
<dael> Rossen_: Dependency change is pretty complex here. Since we have had this feature previously in high contrast adjust name this has never been requested for animation. no signals historically and complexity high. That is the reason not to add additional complexity intot he system.
<dael> Rossen_: Does that satisfy myles or do you have other things to consider?
<dael> myles: Nothing more to say
<dael> Rossen_: Objections?
<dael> RESOLVED: make forced-color-adjust not animatable
<dael> AmeliaBR: Follow up. not sure how it works for animating other properties like color and having a transition on it based on if f-c-a turns on it changes computed value of other properties. DOn't know what to expect but need to define
<dael> florian: Some other properties that might not want to animate when f-c-a on?
<dael> AmeliaBR: If f-c-a turns on it changes computed value of many other properties. If those other properties have transitions should they trigger?
<dael> florian: Understood.
<dael> fantasai: I don't know who impl. I don't think matters for authors it's what easiest for impl
<dael> Rossen_: Transitions between forced and not forced colors requires system reset of user shell. If we run or trigger animations after shell reset is questionable
<dael> AmeliaBR: I wasn't thinking about changing if forced-color mode is on but if f-c-a mode applied within css. lots of complex interactions so I'm happy to define as simple as possible but it needs to be defined
<dael> Rossen_: If we have a conditional color rule that applies under a f-c-a none and that rule is evaluated wither or not color change triggers animation. Is that fair?
<dael> AmeliaBR: Yeah
<myles> I don't understand the complexity argument because because script can change the value of this property at any time
<dael> Rossen_: I think we should open a new issue on if that will trigger transitions
<dael> AmeliaBR: I'll file an issue