[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.