[css-transitions-2] Put discrete transitions behind new syntax for compatibility

[flackr]

Problem

@josepharhar implemented #4441 and discovered some compat issues. While it seems to be true that developers don't set up transitions on properties that only have discrete values, there are many cases where developers have transitions set up on properties which sometimes have discrete values. E.g. going to/from auto currently results in a discrete interpolation. This means that changes to/from auto currently do not start transitions but with transitions of discrete properties they now do.

Note: We want to support smooth interpolation to/from auto (See #626). If/when we add this, if it just starts intepolating to/from auto and thus starting transitions we would run into the same set of compat issues.

Example issues

@josepharhar looked through 30 affected sites and found 3 regressions:
stackoverflow.com
With discrete transitions for width and height on page load the orange text doesn’t show up for a frame or two:

hpe.com
With discrete transitions for max-height, the accordions at the bottom don’t slide closed but instead suddenly close with a delay after clicking:

fender.com
With discrete transitions for top, the menu bar at the top of the page doesn’t stick to the top of the page but instead teleports to the top after a delay when scrolling:

Solutions

From what we have seen so far, the compat issues are only for properties which currently sometimes have interpolable transitions (e.g. length properties which are interpolable when specified but not when auto). This means that technically the only transitions which need to be avoided may be these. However, it seems ergonomically awkward to make the developer need to think about whether the property is sometimes interpolable and sometimes not. As such, I think we should come up with a new syntax for opting in to discrete transitions. A side benefit, is that explicitly specifying discrete also provides a way to opt in to discrete transitions on all without needing a keyword like discrete-too.

For comparison, the code necessary to animate out a dialog (animating display and overlay discretely, and opacity) is shown.

Some options (vote for all that you think would be reasonable):

1. 😄 Add an optional discrete keyword before each <single-transition-property> in the transition-property list. '<single-transition-property>' = discrete? all | <custom-ident>. With this change you would need to add discrete before each property you wanted to start discrete transitions on, e.g. transition: discrete display 0.2s, discrete overlay 0.2s, opacity 0.2s
2. 🎉 Similar to 1, but make a new longhand transition-property-mode which is an auto-extended list. This means that you can specify per property whether it should transition discretely or you can specify transition-property-mode: discrete and it will auto-extend and transition all specified properties discretely. e.g. transition: display 0.2s, overlay 0.2s, opacity 0.2s; transition-property-mode: discrete; (the discrete is a list that can be specified per property but is auto-extended).
3. ❤️ Add a discrete keyword optional keyword which applies to the whole transition-property-list. transition-property = none | discrete? <single-transition-property>#. With this, you would opt in to all specified properties transitioning discretely but wouldn't be able to choose per property. e.g. transition: discrete display 0.2s, overlay 0.2s, opacity 0.2s (the discrete applies to the entire list in this case)
4. 🚀 Add a transition-discrete property specifying which css properties should allow discrete transitions. E.g. transition-discrete: all; all properties, transition-discrete: none; /* initial value */, transition-discrete: border-style outline-style text-decoration-style;. This is similar to 3 in that it decouples the discrete properties from the transitions list which may or may not be desirable, but unlike 3 allows choosing specific lists of properties. See [css-transitions-2] Put discrete transitions behind new syntax for compatibility #8857 (comment)

As mentioned above, if we eventually support non-discrete animation to/from auto, we will have the same compat issues if they work with the existing syntax. As such, we should consider whether any of the above syntaxes (or some other not-yet presented option) could be extended for this auto case. E.g. maybe transition-property-mode: used-value?

[mfreed7]

Thanks for raising the issue! I voted for #2, but wanted to clarify one thing. With option 2, both of these would work, and would be equivalent, correct?

.version1 {
  transition: display 0.2s, overlay 0.2s, opacity 0.2s;
  transition-property-mode: discrete;
}
.version2 {
  transition: discrete display 0.2s, discrete overlay 0.2s, opacity 0.2s;
}

[flackr]

With option 2, both of these would work, and would be equivalent, correct?

Both would work, and in practice they're equivalent (because opacity is never discrete) but syntactically they're different.

They would expand to something like this:

.version1 {
  transition-property-name: display, overlay, opacity;
  transition-property-duration: 0.2s 0.2s 0.2s;
  transition-property-mode: discrete; /* auto-extends discrete */
}
.version2 {
  transition-property-name: display, overlay, opacity;
  transition-property-mode: discrete, discrete, continuous;
  transition-property-duration: 0.2s 0.2s 0.2s;
}

Happy to here other options for continuous, e.g. interpolable, auto, normal.

[SebastianZ]

What happens for interpolatable values? Would the transition also be turned into a discrete one or would the keyword be ignored in that case? If the transition is also made discrete, then I'd suggest an auto value which computes to either continuous or discrete depending on the values to interpolate.

Why should transition-property be turned into a shorthand for that? Wouldn't a transition-mode property as another longhand for the transition shorthand be better? transition-property would still be the controlling property for it, of course.

Also, authors should be encouraged to specify the names for the properties they want to transition instead falling back to all. Therefore, also the direct combination of both keywords should be discouraged.

Sebastian

[tabatkins]

What happens for interpolatable values?

They'd function as normal. The discrete keyword just enables discrete transitions on the property as well.

(If you want "discrete" transitions on interpolable values, provide a linear() timing function yourself.)

[fantasai]

Fourth option: Add a transition-discrete property that takes property names for which you want to allow discrete transitions. Can do values like

transition-discrete: all;
transition-discrete: none; /* initial value */
transition-discrete: border-style outline-style text-decoration-style;

Benefits:

• Don't have to track correspondences across multiple lists.
• Can easily cascade the list of properties you want to enable independently of what you're actually transitioning.

Downsides:

• Might require duplicating the property names.

(Not sure if it's a good idea or not, just wanted to throw it out there.)

[flackr]

Why should transition-property be turned into a shorthand for that? Wouldn't a transition-mode property as another longhand for the transition shorthand be better? transition-property would still be the controlling property for it, of course.

That's a good point, it would just be another transition- list-value longhand. It doesn't require making the property a shorthand for it. I've updated the option to remove the suggestion to make transition-property a shorthand as this just adds unneeded complexity.

@fantasai I've added your suggestion above as option 4. I am still leaning towards 2 myself as I feel like it is more natural to associate with the specified transition but it's good to have options 🙂

[flackr]

One question about option 2, currently it looks like the other property lists are repeated rather than last-value extended when the list is too short. Seems like naively we'd just do the same for transition-mode. I don't think this is a deal breaker as the common case will be specifying only a single value or a list for each transition.

[flackr]

Proposed resolution: Go with option 2 above, adding a transition longhand for specifying whether the transition should allow discrete interpolation. This will follow the same convention as the other transition longhands where the list is repeated if shorter than the transition-property list.

Given this is in reference to the animation-type) it's probably worth sharing some of the terminology. Possible property names:

• transition-mode
• transition-type
• transition-animation-type

Possible property values:

• For referring to interpolable transitions we could use normal (as it's the pre-existing mode), or interpolable explaining that it is anything animatable and not discrete.
• For referring to including discrete transitions, we could say discrete to refer to the specific animation type, or animatable as the intention would be that we animate anything that is animatable.

I think my preference would be transition-type: <normal | animatable>#. Using animatable rather than discrete because it matches exactly the spec terminology for what will be transitioned - anything that can be animated.

[fantasai]

Alternative naming (for option 2), which I think is maybe a bit more clear? (mode/type/etc is pretty vague)

transition-discrete: [auto | all | none]#

where

• all allows discrete values to animate for all properties
• auto disallows discrete animation on otherwise interpolable properties (i.e. those that are included in transition-property: all) to avoid the compat issue
• none disables transitions for discrete values

[css-meeting-bot]

The CSS Working Group just discussed [css-transitions-2] Put discrete transitions behind new syntax for compatibility, and agreed to the following:

• RESOLVED: Pick option 2 with name to be bikeshed

The full IRC log of that discussion

<dael> flackr: When we were trying to ship support for discrete transitions one common case overlloked is common properties that are sometimes discrete and sometimes continuous.
<dael> flackr: This has broken a few sites as shown in issue. Think we need a new syntax to opt in to discrete transitions
<dael> flackr: A bunch of proposals in the issue
<dael> flackr: Two with most support are having a long hand transition property similar to duration and easing that spec per transition if it should start on discrete property changes
<dael> flackr: Other is option 4 from fantasai having a separate property that's a switch for if you do discrete transitions
<dael> fantasai: That prop would have allow/don't allow/all for these properties and it cascades independently.
<dael> fantasai: I'm not saying it's better, but a different approach
<dael> flackr: Two ways of looking. Yours is better for site-wide switch, other is better for property by property.
<dael> flackr: In both you can say you want discrete everywhere. Harder to specify in option 2
<dael> Rossen_: If I'm reading the emoji vote, 6 for #2 and 4 for #1?
<dael> flackr: To be fair, #4 was added later
<dael> Rossen_: Should we be discounting #1? It's a smaller population
<dael> fantasai: I think that option 2 was better than 1. It should come down to 2 vs 4. We could do both
<dael> fantasai: Initial value of the transition mode is an auto value that looks up another property
<dael> flackr: Maybe consider one as a starting point and we could add the other?
<dael> fantasai: One thing that makes it trick is if we think it could be both have to think about how to name them
<dael> Rossen_: Can we live with 2 or 4 only?
<dael> flackr: and fantasai Yeah
<Rossen_> q?
<Rossen_> ack fantasai
<dael> fantasai: Tricky is what is the pattern of use and what will be easier to use in most cases. You can mostly do most of it with either
<dael> flackr: Either let you global opt in. Option 2 if you don't want all you have to go transition by transition. Option 4 is by property
<dael> fantasai: I think option 2 is better. It's more powerful
<dael> flackr: More configurable. And more consistant with other transition longhards
<dael> fantasai: Agree
<dael> Rossen_: 4 is additive?
<dael> fantasai: Could add if we want to
<dael> Rossen_: Sounds like fantasai you're leaning toward #2?
<dael> fantasai: Yeah
<dael> Rossen_: I think we have a clear winner
<dael> Rossen_: Want to hear from the rest of folks on the call
<dael> smfr: Does this make a non-discrete animating prop animate in discrete way?
<dael> flackr: No
<dael> flackr: Some properties are sometimes discete. Their discrete interpolations star with this
<dael> smfr: Transition list was opacity and display are you forced to supply a value for opacity if you want discrete on display?
<dael> flackr: No downside to discrete on opacity
<dael> smfr: Could be confusing for author
<dael> flackr: It is auto expanding list
<dael> smfr: Could also expect discrete on opacity to split to by 50%
<dael> flackr: That's why I had a bunch of options on names. I proposed animatable
<dael> fantasai: Non-animatable properties are quite exceptional I don't think should name based on that
<dael> flackr: It's what the spec says so suggested that
<dael> fantasai: True, but most people don't read spec. Need to think about best way to suggest this to authors
<dael> flackr: Maybe 'all' is value to include discrete
<dael> fantasai: Thinking transition-discrete: all|none|magic value that says if it's discrete you can animate and if it's not it doesn't animate. That way you can throw it on your site and transition discrete properties
<dael> fantasai: If you're not using the all you can set it on whole site and no effect
<dael> smfr: High level comment, discrete is probably hard for non-native speakers.
<dael> fantasai: Yeah. not sure what else. transition-non-interoperable
<dael> flackr: I think we're good with option 2
<dael> fantasai: Yeah, need to figure out what to call it and values
<dael> Rossen_: Let's take a decision and bikeshed name on the issue
<dael> Rossen_: Objections to pick option 2 with name to be bikeshed
<dael> RESOLVED: Pick option 2 with name to be bikeshed
<dael> fantasai: Do we want a magic value that says transition this property only if it is discrete or interorable. Don't transition if it's a property that has an indiscrete
<dael> flackr: Could be UI default since possibly not breaking
<dael> fantasai: Yeah
<fantasai> s/UI/UA/
<fantasai> s/Yeah/Yeah, could be/
<dael> Rossen_: Do we need to resolve on something?
<dael> fantasai: Question is do we add the value or not
<dael> flackr: And what would we call it?
<dael> fantasai: 'magic' for now. bikeshed later
<dael> flackr: If this was not initial value I'd say it's additive
<dael> fantasai: But it could be initial value
<dael> Rossen_: I think we can work this out on the issue
<dael> Rossen_: And hear more from bramus, tab, brian, and other folks who have been engaged
<dael> flackr: Sounds reasonable

[josepharhar]

It sounds like we have these potential property names:

1. 😄 transition-mode
2. 🎉 transition-type
3. ❤️ transition-animation-type
4. 🚀 transition-discrete
5. 👀 transition-interpolation

• @fantasai mentioned that "mode" and "type" are vague
• @smfr mentioned that "discrete" is hard for non-native english speakers
• The property values we choose might impose a particular property name and vice-versa

Property values:

1. normal | discrete
2. normal | animatable
3. interpolable | discrete
4. interpolable | animatable
5. auto | all | none

• @flackr mentioned that normal | animatable would be good because using animatable rather than discrete matches exactly the spec terminology for what will be transitioned - anything that can be animated
• Assuming that these property values will appear in a shorthand, I like discrete since I think it makes the following easier to understand imo: transition: discrete display 0.2s, interpolable color 0.5s;
• If we allow in the future for smooth interpolations between auto and 123px for properties like height, would we want to add a new value? Or reuse the opt-in value discrete/animatable/all?

[yisibl]

The specification ultimately chose to add transition-behavior: allow-discrete.

I would like to know if the CSS author sets * { transition-behavior: allow-discrete; }, does this affect performance?