[scroll-animations-1] Syntax of animation-range is ambiguous

[ydaniv]

Since we resolved in #7575 to allow <length-percentage> to be used as offsets in animation-range, it's now possible to have a range of:

.source {
  animation-timeline: view(self);
  animation-range: entry 0 contain 20%;
}

Which can now mean 2 things:

1. The animation's progress is at 100% when .source is at 20% of its contain range.
2. The animation's progress is at 100% when .source is at contain 0% + 20% of its parent's size (according to timeline's axis).

In order to be able to distinguish between the 2 cases we have the following options:

1. Make ranges functions, so that contain 20% becomes contain(20%)
2. Disallow <percentage> so that it only means 1. from the options above. But that seems suboptimal.
3. Adopt suggestions in [scroll-animations-1][css-animations-2] animation short-hand support for new properties #8054 to use the offset() and range() notations so that we get offset(contain 20%)

Anyhow, since we already have other ambiguity issues raised in #8054, I guess we could solve both by adopting either option 1 or option 3.

cc @flackr @fantasai @bramus

[flackr]

My assumption has always been that percentages resolve against the range length making contain 20% and contain 0% + 20% the same value.

[ydaniv]

Interesting, that's option 4, using a special case for the resolution of <percentage> in the context of ranges.
I think that will somewhat cripple this feature when used in conjunction with layout.
For example, this is easy when used with px:

.source {
  position: absolute;
  top: 10px;
  animation-timeline: view();
  animation-range: contain 0% exit -10px;
}

But becomes tricky when used with %:

.source {
  position: absolute;
  top: 10%;
  animation-timeline: view();
  animation-range: contain 0% exit -10%;
}

In this case 10% is computes to different values for top and animation-range.

[fantasai]

My assumption has always been that percentages resolve against the range length

Mine, too. Otherwise rangename 100% doesn't work!

In this case 10% is computes to different values for top and animation-range.

This... seems like what I'd expect? Who knows what top is relative to, it doesn't necessarily have anything to do with the size of the scroller or the item.

[fantasai]

In any case, I'm pretty sure there's no ambiguity here. Should this be closed as invalid?

[ydaniv]

Who knows what top is relative to

I'm assuming it resolves to it's CB's height/width.

it doesn't necessarily have anything to do with the size of the scroller or the item

Right, but I do see use cases where it's desired to be able to have the offsets of the animation correspond to layout.

In any case, I'm pretty sure there's no ambiguity here. Should this be closed as invalid?

I still think we're losing the ability to use percentages as offsets like the rest of <length> units ,but if there's a consensus here I'll close.