Re: [csswg-drafts] [scroll-animations-1] Add a new named timeline range that is independent of subject dimensions. (#9617)

> > The current [named timeline ranges](https://drafts.csswg.org/scroll-animations-1/#view-timelines-ranges) all depend on the subject dimensions. If the subject changes dimensions, or the same range is used on another subject, the timing will be different.
> 
> That's the whole point of "view", it's the intersection of the element inside it's scrollport.

Yes. View progress timelines are for animations that start and end while the element is in view within the scrollport. That is the case here as well. Animation keyframes can be attached to named timeline ranges such as 'cover' and 'contain'. I am merely asking for another named timeline range.

> > Can we define another named timeline range size-independent-to-be-bikeshed, where:
> > 
> > * 0% progress represents the latest position where the center of the element's principal box coincides with the end edge of its view progress visibility range.
> > * 100% progress represents the latest position where the center of the element's principal box coincides with the start edge of its view progress visibility range.
> 
> What is "latest" position? "latest" relative to when?

I am borrowing the wording of the current specification here. That wording handles sticky positioned elements. To quote the spec:
> NOTE: For [sticky-positioned boxes](https://drafts.csswg.org/css-position-3/#sticky-position) the 0% and 100% progress conditions can sometimes be satisfied by a range of scroll positions rather than just one. Each range therefore indicates whether to use the earliest or latest qualifying position.



> > This will let authors set a view-timeline where the timing will not depend on the size of the subject, only its position.
> 
> Again, position relative to what? 

My wording might not have been clear enough. Apologies. 
I am referring to the elements position relative to the ['view progress visibility range'](https://drafts.csswg.org/scroll-animations-1/#view-progress-visibility-range). In most cases that will be relative to the viewport or the scrollport, if they haven't been modified by a view-timeline-inset.

> What you want is probably to "dumb down" the model and be able to reduce the element's rectangle to a point. Then you can reason only about the scrollport. So that point needs to be something you can specify, like `start`/`center`/`end`. Then you need to reference that point to the scrollport.

I do not want to "dumb down" the model. I think it would be useful with another attachment range to better specify the start and end positions of some of the animations we make. 

> > The timing of the 'cover' range will become increasingly slow as the subject size increases, while the 'contain' range will become increasingly fast as the subject size gets closer to the view progress visibility range. A timing that seems reasonable on a desktop screen, might be lighting fast on a small mobile screen.
> 
> That's true only if you animate dimensions (width/height) and/or position (top/left/bottom/right/inset). It doesn't change if you animate `transform`.

I'm sorry about the wording again. The concern here is not situations where we animate the elements size, but I get how it can seem like that from my wording. 

The timing of the 'cover' range will be 'slower' on a larger subject. If we compare the timing of an animation attached to the 'cover' range for two different elements it might be more clear:
- For a subject with height 0, the animation will progress from 0% to 100% over a scroll length of 100vh. 
- For a larger subject with height 100vh, the animation progress from 0% to 100% over a larger scroll length of 200vh. 

This is fine. Sometimes that is what you need. I'm arguing that it's useful to have an attachment range where the animation progresses equally for these two elements.

> If you do have to animate dimensions/position then you should either wrap that element in another element and use that as the subject, which isn't ideal, or use `scroll-timeline`, which also isn't ideal. But I guess that's the trade off for handling such a powerful tool. Again, unless we consider referencing a point on the element, instead of its entire rect.

As I stated in the issue text, there are better workarounds that work with the current spec. We've been using versions of them for years. I do think we can improve the notation for authors.



> I don't really see how manipulating the `view-timeline-inset` helps here, it simply changes the scrollport's reference.

There was a bug in the stylesheet there. It should have said `view-timeline-inset: 25%;`

If you set an animation range of `entry-crossing 50% exit-crossing 50%` the animation attachment range will start when the elements center is at the end edge of the scrollport, and stop when the elements center is at the start edge of the viewport. These are the endpoints of the `size-independent` animation range I suggested. 

Now that the animation attachment range is set to these endpoints, we can use inset to simulate a progress along this animation range. These two would give the same timing: 

```css
.before {
  ...
  animation-range: entry-crossing 50% exit-crossing 50%;
  view-timeline-inset: 25%;
}

.after {
  ...
  animation-range: size-independent 25% 75%;
}
```

Note: I'm not advocating `size-independent`, I'm sure we can come up with a better name.

> Bottom line, maybe the current range names are a bit too magical? We could consider having something like `entry-start`/`entry-center`/`entry-end` etc.

I think the existing names work fine. It's just that they all depend on the subject size, and I'm asking for a new range that is independent of the elements size.

-- 
GitHub Notification of comment by johannesodland
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/9617#issuecomment-1821076331 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 21 November 2023 14:52:29 UTC