[css-transitions-2] Start transitions on discrete animation types

[flackr]

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

When comparing the before-change style and after-change style for a given property, the property > values are transitionable if they have an animation type that is neither not animatable nor discrete.

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: all is a very common pattern), any solution would likely have to preserve the existing visual behavior

Option 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?

[birtles]

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]

Flackr,
I think your on to something. I am running into a problem with using the 'background-image' in an SVG transition [i.e. css: background-image: url (xyz)]

Once I have 'encode' in-line and apply it to the css as a background-image: url ... I loose the transition ability.
This is because 'background-image' is "Animation type - DISCRETE".

If you have a work-around for this that would be great!

Here is where I'm stuck, I have an Accordion which uses the [+/-] svg as a toggle button.

I've got it working the way I want, but want to remove the HTML's in-line ,
and place it into the CSS, Or at least have it as a <style> in the Header.
[see working: 1.0 default [current ver - no mod].html]

Placing it in the Header <style> works BUT I loose the animation.
[not working: 2.0 default [in header].html]

Ultimately I really want it in the CSS file, to get it completely out of the HTML.
[not working: 3.0 default [in css main2].html]

It could be that the 'encoding' will not allow the 'evenodd' method to work,
or I have it placed wrong, The animation/transitioning does not work.

The Button's CSS starts at line: 1495

Example DL here: http://msgr.info/In-Line_SVG_to_CSS.zip - 152 KB (155,648 bytes)

[Note this 'example' is stripped down from the Original Site to lessen the load, it's a bit dirty-code - the best I could do to make an example]

Thank you for your help!

[flackr]

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?

@birtles I like the idea of having transition: all match everything that is animatable and not discrete, and allowing developers to explicitly specify discrete properties if they want them to participate in transitions.

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.

I think that having discrete as something that could be specified in addition to all would be nice.

Thinking about this I'm realizing developers could also use transition events as a way to detect style changes. Not sure if this is an explicit use case we should support but it's interesting to think about what people might do with that.

[flackr]

So to be specific, the proposal here is:

1. Properties explicitly listed in transition will transition even if discrete.
2. (Optionally) add a keyword similar to all which includes discrete properties too, or optionally is just for discrete properties.

[birtles]

Yes, I agree with that summary, assuming we want to go ahead with this (personally I'm not familiar with the use cases).

[andruud]

@flackr I think I would phrase (1) as follows:

1a. Properties with discrete animation types do transition (generally), however:
1b. The all keyword does not represent such properties.

That way there is nothing particularly special about certain properties being "explicitly specified". They transition because they are specified, end of story. Then (2) also becomes non-special, since it's just a keyword which represents a certain set of properties.

[graouts]

Yes, I agree with that summary, assuming we want to go ahead with this (personally I'm not familiar with the use cases).

I also follow the general thrust of this issue but am uncertain what the use cases are. Being able to transition properties with a discrete animation type would mean that they would no longer switch value immediately but rather halfway through the transition duration. What is foreseen as benefits from transitioning a discrete property in that way?

Or would we envision a different mode where the value change is performed at the end of the transition?

[mfreed7]

I also follow the general thrust of this issue but am uncertain what the use cases are. Being able to transition properties with a discrete animation type would mean that they would no longer switch value immediately but rather halfway through the transition duration. What is foreseen as benefits from transitioning a discrete property in that way?

One important use case is transitioning the display property (see #6429 (comment)). Since interpolation for display is done like visibility, it prefers the non-none state. So transition: display 200ms is immediate for the "showing" transition, and delayed until the end for the "hiding" transition.

[flackr]

What is foreseen as benefits from transitioning a discrete property in that way?

There two main benefits to transitioning discrete properties:

• Developers can use the transitionstart event to implement custom behavior. E.g. developers could prototype cross-fading of images or another effect when the background changes.
• This is very useful for holding particular discrete values for the purposes of an animation - e.g. primarily see the exit transition example at [css-display] Why is display listed as not animatable instead of animation type: discrete? #6429 (comment)

I get that you're calling out the 50% flip and I agree in general most people will want the transition of these at the end if declared as a transition-property because switching immediately doesn't require any transition, however this isn't true if the developer is customizing the transition and perhaps there are cases where they want the composite order of the transition animation?

Or would we envision a different mode where the value change is performed at the end of the transition?

So, developers could use transition-timing-function setting step-start or step-end to choose whether to hold the beginning or ending keyframe. We do define for particular properties where certain values may not be useful interpolations - e.g. display: none is useful to avoid in the same way that visibility interpolation avoids hidden: https://drafts.csswg.org/web-animations-1/#animating-visibility. I could see defaulting the timing function to step-end for discrete properties but it would be weird if you couldn't choose a different timing function, and if the developer is customizing the transition it would be nice for them to be able to use the regular animateable timing function.

[css-meeting-bot]

The CSS Working Group just discussed [css-transitions-2] Start transitions on discrete animation types, and agreed to the following:

• RESOLVED: if a discretely animatable property is listed in a transition it will. by default the all keyword will not transition

The full IRC log of that discussion

<bramus> astearns: thanks oriol
<bramus> flackr: in current spec we explicitly dont transition discrete aniamtions types. we skip
<bramus> flackr: with resoltuion to animate display it would be useful for devs to transition discrete properties
<bramus> flackr: example in linked issue
<bramus> flackr: proposal is that we allow transitioniong discrete props but to preserve compat the all keyword would only match animatable types
<smfr> q+
<bramus> flackr: only if dev lists explicitly lists a discrete property it would transition
<astearns> ack smfr
<bramus> smfr: … timing function? steps timing to contorl when the value flips?
<bramus> flackr: sure you can
<bramus> flackr: step and step-start
<bramus> smfr: is there [missed] … the animation? wondering if timing function> .5 that is where discrete things flip
<bramus> flackr: my proposal is not to do something special here
<bramus> flackr: means that you can use any fn that crosses .5 treshold
<dbaron> You can also use a different transition-delay for the discrete property if you want to.
<bramus> smfr: trying to underrstand implications
<bramus> flackr: all would only include animatable props
<bramus> smfr: mech for keyframes?
<bramus> flackr: already the case. not building any new anim behavior here
<bramus> smfr: havent quite got in my head yet. is there a dif between props that animate discretely and those not at all?
<bramus> flackr: yes. you cant animate aninaton-name for example
<bramus> smfr: what about display?
<fantasai> well, we resolved to draft such a proposal into the css-display-4 draft
<bramus> flackr: we resolved on display last week
<bramus> smfr: doesnt this already work by virtue of .5 behavior?
<bramus> flackr: there is line in spec that limits to only animatable and not discrete
<bramus> tabatkins: you can animate a discrete prop but not transition one
<bramus> flackr: with waapi, devs can listen to transitionstart
<bramus> flackr: they could use this to enable transitions we do not support yet
<bramus> astearns: easier acces
<bramus> flackr: possible to acces. before no transitionstart ( = custonization point)
<masonf> q?
<bramus> plinss: some props are discrete because they are difficult to animate
<bramus> plinss: if an engine figures out how to make a discrete prop animate: is that allowed and would it then be treated as normal animated property?
<bramus> flackr: yes and yes
<fantasai> plinss++
<bramus> flackr: and would then be picked by up by `transition: all`
<bramus> plinss: can we detect this?
<astearns> ack fantasai
<bramus> fantasai: example: animate between 2 background imgs.
<bramus> fantasai: tarnsitionable with easing curbe
<bramus> fantasai: what would happen if it became animatable? compat problems? might be fine
<bramus> flackr: cases for waapi and css anims. they dont have a mechanism to know when the become animatable
<bramus> flackr: you could use this to feature detect if property is discrete or not
<fantasai> s/tarnsitionable with easing curbe/if author transitions with a particular easing curve assuming discrete/
<bramus> plinss: we may want to consider an `@supports` for this
<bramus> astearns: yes
<masonf> q?
<bramus> astearns: do we add ability to tell sth is discrete or animatable?
<masonf> q+
<astearns> ack masonf
<bramus> masonf: point out that there is an optional part 2 to add a new keyword
<bramus> astearns: lets discuss after
<astearns> ack fantasai
<bramus> fantasai: proposal is that you explicitly list a property that is discrete it will transition. whe you provide an easing curve it will flip at 50%?
<bramus> flackr: yes. latter part already implied by how animations work
<bramus> fantasai: seems reasonable
<bramus> astearns: proposed resolution: if a discretely animateable property is listed in a trantion it will. by default the all keyword will not transition
<bramus> flackr: anders said it better there, but effect is the same
<bramus> RESOLVED: if a discretely animatable property is listed in a transition it will. by default the all keyword will not transition
<bramus> astearns: 2nd part: can we have all opt in to this behavior?
<bramus> flackr: 2 options: other type of all keyword that is actually all, or a keyword to target discrete
<astearns> ack fantasai
<masonf> q+
<bramus> fantasai: i think if there is no demand we should not add it. idea to add discrete makes more sense.
<bramus> fantasai: you can then use it to apply a certain curve to only the discrete ones
<flackr> E.g. transition: all 1s ease, discrete step-end 1s;
<astearns> ack masonf
<bramus> flackr: example in irc is sth devs might do
<dholbert> q+
<bramus> masonf: +1 on discrete keyword
<bramus> astearns: i can see value in this
<astearns> ack dholbert
<bramus> astearns: but I might want to see actual real tarnsitions with particular groups of discrete props taht would be solved by this keyword before we resolve to add it
<astearns> s/see value/see theoretical value/
<bramus> dholbert: concern where prop changes from discrete to not discrete
<bramus> dholbert: could be problem for minor content
<bramus> dholbert: also curious for use cases
<bramus> flackr: first part already problem bc all matches [missed]
<bramus> flackr: second part less defined right now
<bramus> astearns: you can do custiomzation now by having discrete property explicitly listed, separetely from all
<bramus> flackr: yes
<bramus> flackr: do see value in discrete keyword
<bramus> flackr: but also fine with exploring use cases first
<bramus> astearns: what about a note in the spec that we consider this keyword and ask authors for use cases (or if we come up with some)?
<masonf> +1
<bramus> flackr: sure
<bramus> astearns: thats it we are at time
<argyle> 👋🏻

[hober]

Seems like this resolution doesn't match the interoperable behavior of all three engines? web-platform-tests/wpt#38904

[flackr]

Yes, there are many wpt tests which explicitly define transitions on discrete properties and test that they don't transition which will be changed by this, but in practice there is no reason for developers to explicitly have discrete properties in their transition list. This is similar to new properties which previously had no effect but could have been used by developers now having an effect when they are defined.

[fantasai]

This landed in 69f4ac7 via #8520 ; I don't know why GitHub isn't recording it.