[scroll-animations-1][css-animations-2] animation short-hand support for new properties

[flackr]

scroll-animations-1 upgrades animation-delay to both be a shorthand for animation-delay-start and animation-delay-end as well as to support a new syntax for each of animation-delay-start and animation-delay-end of <timeline-range-name> <percentage> and just a <timeline-range-name> by itself for the overall property. Note that issue #7901 is bikeshedding some of the particulars but the high level is that more values will be part of animation-delay.

Since animation-delay is also part of the animation short-hand we also have to make sure that these new values can be uniquely parsed and differentiated from other properties in that shorthand. Issue #6946 touches on the general difficulty of extending the animation shorthand.

If we assume the format of <animation-delay> within the animation property is the same, we will have a compat risk with any named ranges which could overlap with animation keyframe names (i.e. currently cover, contain, enter, exit but potentially user defined range names in the future), as well as limit the ability to add any other numerical properties which could be confused with the offsets (currently percentages but #7575 will likely add lengths as well).

After discussing this with @andruud, we think functional notation would make animation delays unambiguous w.r.t animation-names or other future values which may also want to specify lengths, times, percentages. Specifically, we could add two functions (open to bikeshedding names):

• offset(<timeline-range-name> <percentage>) would map to an animation-delay, the first occurrence being start delay and the second being end delay. (Alternate name ideas: delay to be consistent with underlying property)
• range(<timeline-range-name>) would map to animation-delay: <timeline-range-name> 0% <timeline-range-name> 100%.

The scroll-animations spec also builds on the ability to specify an animation-timeline which has additionally been added to the animation shorthand in css-animations-2. The spec doesn't currently explain how to disambiguate a named timeline from an animation-name, but we could either use the positions like we do to currently differentiate duration and start delay or we could add a function for this as well, e.g. timeline(<timeline-name>) to unambiguously specify a timeline. We could keep the existing support for referring to anonymous timelines since those already have a functional notation. Open to other ideas here. @tabatkins

[ydaniv]

A few questions:

• Any reason to prefer offset(<timeline-range-name> <percentage>) offset(<timeline-range-name> <percentage>) over offset(<timeline-range-name> <percentage>, <timeline-range-name> <percentage>)? I guess the latter maps better to a single delay value that is expected today, or is there an intent to add end delay to the shorthand's definition?
• Is <percentage> mandatory? Or defaults to 0%/50%?
• How about optional percentages for range() ? Like range(<timeline-range-name>[, <percentage>][, <percentage>]), first for start and second for end.

[ydaniv]

Another question:

It used to be common for scroll-linked animations, which were all based on ScrollTimeline-like implementations, to use a start offset (delay) and pixel-duration (duration), rather then an end offset (end delay). Though this technique may be obsolete with the invention of ViewTimeline, I think it may still be worthwhile to allow specifying a timeline either by a duration or and end-offset.

Is there a way to achieve this? I guess simply using positive/negative values won't work, perhaps with using offset() and range() with ScrollTimeline?

[flackr]

• Any reason to prefer offset(<timeline-range-name> <percentage>) offset(<timeline-range-name> <percentage>) over offset(<timeline-range-name> <percentage>, <timeline-range-name> <percentage>)? I guess the latter maps better to a single delay value that is expected today, or is there an intent to add end delay to the shorthand's definition?

The intent would be to add end delay to the shorthand definition, though putting the start and end in one function is also fine with me. This could be delay or range, whichever we go with in #7901.

• Is <percentage> mandatory? Or defaults to 0%/50%?

I would prefer it being mandatory, though if we have a positional function like you proposed it might be reasonable to default to 0% for the start range / delay and 100% for the end range / delay.

• How about optional percentages for range() ? Like range(<timeline-range-name>[, <percentage>][, <percentage>]), first for start and second for end.

Isn't this just becoming the same as the offset function?

[flackr]

It used to be common for scroll-linked animations, which were all based on ScrollTimeline-like implementations, to use a start offset (delay) and pixel-duration (duration), rather then an end offset (end delay). Though this technique may be obsolete with the invention of ViewTimeline, I think it may still be worthwhile to allow specifying a timeline either by a duration or and end-offset.

Is there a way to achieve this? I guess simply using positive/negative values won't work, perhaps with using offset() and range() with ScrollTimeline?

This issue is merely to decide on the syntax for the animation shorthand ideally avoiding parsing ambiguity. It is a helper for all of the longhand properties. If in #7575 we decide to go with allowing lengths there then we would allow them here as well.

[flackr]

I suspect this is a nice to have but that we could not support the new properties and values in the short-hand for the initial version.

[fantasai]

(Agreed that it's not necessary to support the new features in the animation shorthand to start with.)

[css-meeting-bot]

The CSS Working Group just discussed [scroll-animations-1][css-animations-2] animation short-hand support for new properties, and agreed to the following:

• RESOLVED: New features are not added to the animation shorthand (for now), they're just reset

The full IRC log of that discussion

<fantasai> s/Topic/Subtopic/
<TabAtkins> fantasai: proposed resolution is we don't need to support new features in the 'animation' shorthand
<TabAtkins> (agreed, the animation shorthand is already a trash fire of parsing)
<TabAtkins> fantasai: We might come up with a good idea for later, but for now
<TabAtkins> astearns: Close the issue, or tag it to a different level?
<TabAtkins> fantasai: tag it
<TabAtkins> astearns: so proposed resolution is "not now"
<TabAtkins> dbaron: The shorthand is still resetting those new props, just can't set them?
<TabAtkins> fantasai: yes
<TabAtkins> RESOLVED: New features are not added to the animation shorthand (for now), they're just reset