[scroll-animations-1] Range for entire scroll range

[flackr]

It has come up a few times (https://github.com/w3c/csswg-drafts/issues/8942#issuecomment-1722261722, https://github.com/w3c/csswg-drafts/issues/8672#issuecomment-1545980510, https://github.com/w3c/csswg-drafts/issues/8578#issuecomment-1540705525) that we don't have any way to specify the entire scroll range for view timelines.

We decided in other issues that because we want the default range for a view timeline to be the cover range we should have cover by the normal range. If we want to preserve this but still support the use cases for the entire scroll range we should add a new range name for view timelines to cover this. E.g. the scroll range could represent the full range. Then authors could do something like animation-range: entry 0% scroll 1000px to make an animation from when an element enters to when you're scrolled 1000px down.

My preference would be to have animation-range without a range name use this range, e.g. just animation-range: entry 0% 1000px or animation-range: 200px 1000px but I think @fantasai had concerns with having the default animation range be cover except if you specify an animation-range without a named range.

[ydaniv]

Big +1 in general.

Regarding:

My preference would be to have animation-range without a range name use this range, e.g. just animation-range: entry 0% 1000px or animation-range: 200px 1000px but I think @fantasai had concerns with having the default animation range be cover except if you specify an animation-range without a named range.

I'm not sure I'm following. For now we have no range defaults to the timeline's full range, which is cover for View, and scroll for Scroll. IIRC animation-range: entry 0% 1000px should expand to animation-range: entry 0% cover calc(0% + 1000px). So if you specify a range without a name it uses default range, right?

[ydaniv]

@flackr ok I think I understand your point. I guess for ViewTimeline having the default be cover is more sensible than scroll, then 0% 90% for view would default to an actual view timeline. Otherwise it would default to yet another ScrollTimeline. So cover seems like a good default, and having scroll as an opt-in for breaking out of that range is also very useful.

I think this issue is ready for agenda+, WDYT?

[bramus]

Two thoughts:

1. Instead of scroll why not name it full? As that’s what it targets, right?
2. When using no range-name, I think it would be most consistent if it uses the range-name that is used for normal.
   • For ViewTimeline that would be cover
   • For ScrollTimeline that would be full

Some examples:

• VT: animation-range: 10% 90% = animation-range: cover 10% cover 90%;
• VT: animation-range: entry 10% 90% = animation-range: entry 10% cover 90%;
• ST: animation-range: 10% 90% = animation-range: full 10% full 90%;

[css-meeting-bot]

The CSS Working Group just discussed [scroll-animations-1] Range for entire scroll range, and agreed to the following:

• RESOLVED: add 'scroll' named range to view timelines, represents entire scroll range, bikeshed keyword in issue

The full IRC log of that discussion

<fantasai> flackr: We decided that the default range for 'view' timelines is the 'cover' range, because this is a sensible default animation
<fantasai> ... for animating as some element goes through the viewport
<fantasai> ... but no way to express the total scroll range
<fantasai> ... so sometimes might want start of scroll to some position in view range
<fantasai> ... or view range position to end of scroll
<fantasai> ... simplest think we could do is add a named range that refers to the full scroll range, so we can refer to it in the animation-range
<fantasai> ... suggestion is "full"
<fantasai> flackr: also raised issue specifying pixel values as offsets from cover range
<fantasai> ... but might be awkward
<bramus> q+
<fantasai> ... also would be a breaking change
<fantasai> ... to change interpretation of values without range name
<fantasai> ... because default animation range for view timelines is 'cover'
<Rossen_> ack bramus
<fantasai> bramus: if you specify 3 values, if you don't specify a range name it defaults to 'cover' for view timeline and 'full' for scroll timelines?
<fantasai> flackr: I thought we already resolved 3-value syntax
<TabAtkins> fantasai: I'm trying to think thru this
<Rossen_> ack fantasai
<TabAtkins> fantasai: Not sure "full" is actually better than "scroll"
<TabAtkins> fantasai: view timelines are supposed to be about when the element is in view, there's different interps of what that might mean, but that's what it's about
<TabAtkins> fantasai: saying "full" timeline is the entire scroll range might be a little odd
<TabAtkins> fantasai: if you wanted the full scroll range you should use the scroll timeline rather than view timelien
<TabAtkins> fantasai: I can see use-cases for wanting one end or another tied to the end of the scroll
<TabAtkins> fantasai: But we should make it clearer you're extending outside the conceptual range of the view timeline
<TabAtkins> fantasai: And it definitely shouldn't be the default
<bramus> q+
<fantasai> flackr: originally why I proposed 'scroll', full range of view timeline should be considered to be 'cover'
<schenney> q+
<Rossen_> ack bramus
<fantasai> bramus: if we use 'scroll', then it wouldn't make sense for other timelines e.g. media playback timelines
<fantasai> flackr: for media timelines, default would be the full playback range
<fantasai> bramus: for scroll timelines, default is the full scroll timeline
<Rossen_> ack schenney
<fantasai> schenney: "full" is referring to "full page", might help to clarify
<fantasai> flackr: not quite, talking about entire scroll range
<fantasai> schenney: complete scrollable area?
<fantasai> flackr: yes
<fantasai> Rossen_: That excludes the scroll-margin areas?
<fantasai> flackr: I don't think so, it represents offset zero and max offset
<fantasai> Rossen_: if I have something in the negative space?
<fantasai> flackr: yes, that's excluded
<fantasai> Rossen_: and something beyond end of range?
<fantasai> flackr: right
<fantasai> fantasai: do we want to accept and bikeshed later?
<schenney> content?
<fantasai> Rossen_: let's pick one of the two names for now, and then go with it
<fantasai> Rossen_: Let's stick to 'scroll' because then at least one person doesn't like it, and we can bikeshed to find the right name
<fantasai> Rossen_: Proposed to add 'scroll' named range to view timelines, represents entire scroll range
<fantasai> RESOLVED: add 'scroll' named range to view timelines, represents entire scroll range, bikeshed keyword in issue

[schenney-chromium]

I think I get why scroll makes sense as a name: You are using the range of a scroll timeline for a view timeline. In which case I am fine with scroll.

[flackr]

bikeshed keyword in issue

To carry out this bikeshedding, the proposals are:

1. 😄 scroll as in the scrollable range of the associated scrolling container and the range you would get from a scroll timeline.
2. 🎉 full as in the full scrollable range of the associated scrolling container. Confusingly, this can be smaller than the cover range when the scrollable range cannot scroll the subject out of view.
3. ❤️ content as in the range of the scrollable content in the associated scrolling container, minus the size of the scrollport.

I think we're pretty well aligned on #1, but happy to have emoji votes / comments or rationales for the others, or suggestions for alternatives.

[bramus]

If we do name it scroll, then that should also be a valid range name for ScrollTimeline, right?

That way, using scroll 0% scroll 100% as the range on both a ScrollTimeline and ViewTimeline (that track the same scroller) is the same.

Additionally, for ScrollTimeline specifically, all these range values would mean the same:scroll 0% scroll 100% = 0% 100% = normal normal.

[bramus]

If we do name it scroll, then that should also be a valid range name for ScrollTimeline, right?

That would also allow fixing that non spec-compliant situation in Chrome where you have to pass in "none" as the name when trying to set a range using an object in JavaScript. If this were "scroll" then it’d make sense.

anim.rangeStart: {
  offset: CSS.px(100),
  rangeName: 'none', // This needs to be `"none"`, but `none` is not defined in the spec as a valid `rangeName`.
},

[ydaniv]

If we do name it scroll, then that should also be a valid range name for ScrollTimeline, right?

According to spec range names are only defined for ViewTimeline, so why should this be any different?

That would also allow fixing that non spec-compliant situation in Chrome where you have to pass in "none" as the name when trying to set a range using an object in JavaScript.

That sounds unfortunate. But in CSS the name is optional. Can't it be the same in JS?