birtles
commented
5 years ago Yes, it would be nice to support this.
Apart from perf considerations, I'm a bit concerned about compatibility with option 1. If scripts are, for example, waiting for transitionend events and then asserting their propertyName is such-and-such, then firing transitions for other events could lead to breakage.
Option 2 would still result in extra transitionrun and transitioncancel events but I expect far less content is actually listening to them so they are less likely to produce breakage.
What about not allowing all or any shorthand to ever match discrete properties but still creating transitions for them (using the behavior from option 1) if they are explicitly listed? e.g. transition-property: all, overflow-x?
I suppose that runs the risk that if a longhand is promoted to a shorthand we might need to special case it so it keeps working (depending on how we define a discrete property). Then again, any content listening for transitionrun events on the (now) shorthand name, would already break since the UA would start firing events on the corresponding longhand names instead.
The other option that comes to mind is simply to add extra syntax for this, be it an extra property (transition-property-set: discrete-too) or extra syntax attached to property names.
TheBigApple
One of the goals of web-animations is to allow developers to define custom transitions. In theory, this would let a developer define a transition for property types which are animation type Discrete, however css-transitions-1 defines discrete animations as not transitionable:
https://drafts.csswg.org/css-transitions-1/#starting
This issue is to explore the possibility of allowing developers to create custom transitions for such properties. Since a lot of content today likely relies on the current behavior (
transition-property: allis a very common pattern), any solution would likely have to preserve the existing visual behaviorOption 1 - Use custom easing on discrete transitions
We could define transitions on discrete properties to create a transition using an easing type which immediately assumes the end value. This would preserve the existing visual behavior while allowing developers to listen for and modify the transition.
However, if we assume that a lot of existing comment has transition: all >0 duration, doing all of the work to create and run these transitions may be prohibitively expensive.
Option 2 - Start and cancel discrete transitions
Start the transition animation, and immediately cancel it, such that a developer could access it and play it / modify it from a transitionstart event?