Re: [csswg-drafts] [scroll-animations-1] Percentages vs Pixels for Scroll Timeline Values (#7045)

The CSS Working Group just discussed `Percentages vs Pixels for Scroll Timeline Values`, and agreed to the following:

* `RESOLVED: Use percentages for scroll-timeline values`

<details><summary>The full IRC log of that discussion</summary>
&lt;fantasai> subtopic: Percentages vs Pixels for Scroll Timeline Values<br>
&lt;fantasai> github: https://github.com/w3c/csswg-drafts/issues/7045#issuecomment-1081276755<br>
&lt;fantasai> flackr: For scroll-linked animations, now the question is, what is the internal time: is it percentages or lengths?<br>
&lt;TabAtkins> q+<br>
&lt;fantasai> flackr: This would specifically be for the output<br>
&lt;TabAtkins> ack fantasai<br>
&lt;Zakim> fantasai, you wanted to ask about birtles' opinion<br>
&lt;Rossen_> ack fantasai<br>
&lt;fantasai> flackr: This is just for what we report to the developer; can take any type as input regardless<br>
&lt;fantasai> flackr: arguments for each are in the issue, but will try to summarize<br>
&lt;fantasai> flackr: pixel-based is very analogous to the way time works for regular animations<br>
&lt;fantasai> flackr: scroll-timeline is animating over a length<br>
&lt;fantasai> flackr: whereas for percentages, these are pretty much exactly what the animation progress is, which is how devs specify keyframes<br>
&lt;fantasai> flackr: and is closer to intersection-observer API as it relates to view timelines<br>
&lt;bmathwig> q<br>
&lt;fantasai> TabAtkins: Given resolution to the previous issue, is this just about how we should interpret a double in this case or can we return a typed value, and then is it a question of which typed value to return?<br>
&lt;bmathwig> q+<br>
&lt;fantasai> flackr: question of which typed value to return<br>
&lt;Rossen_> ack tantek<br>
&lt;fantasai> flackr: for setters, we could even throw for a double, since time values don't belong in a scroll animation<br>
&lt;Rossen_> ack TabAtkins<br>
&lt;fantasai> TabAtkins: in that case, I suggest if the progress value changes as the scrollable area changes ...<br>
&lt;fantasai> TabAtkins: if you freeze an animation, and you change the scrollable area size, the time value should stay ocnstant<br>
&lt;fantasai> flackr: standard behavior is  ... mapping to progress<br>
&lt;fantasai> flackr: if a change in the scrollable length causes a change to the animation progress, using percentages the current time will also change to reflect that change in animation progress, but a length will not<br>
&lt;fantasai> flackr: because would have the same absolute scroll position<br>
&lt;Rossen_> q?<br>
&lt;fantasai> fantasai: I think that's a pretty convincing argument<br>
&lt;Rossen_> ack bmathwig<br>
&lt;fantasai> bmathwig: Just building on what Tab was saying, what are the artifacts that would occur should the case of an infinite scroller and timeline being used, and animation jumps back to a previous keyframe<br>
&lt;fantasai> bmathwig: would that cause a disruption in the continuity and disruption / artifact ?<br>
&lt;fantasai> flackr: I don't think our decision here would affect that. We can accept either type as input<br>
&lt;fantasai> flackr: the current behavior for most of the animation APIs is that you specify keyframes in percentage progress, so until we expand that to express absolute positions in time, won't have discontinuity<br>
&lt;fantasai> flackr: regardless of whether output value is pixels or percentages<br>
&lt;fantasai> bmathwig: OK, then percent is interesting... I don't have an opinion, don't have enough context.<br>
&lt;fantasai> Rossen_: OK, where does that leave us?<br>
&lt;fantasai> flackr: Seems we have slight preference for percentages, because maps directly to animation progress<br>
&lt;fantasai> flackr: if there's no objections, I would resolve on that<br>
&lt;fantasai> flackr: I think we can support both types in terms of specifying values<br>
&lt;fantasai> flackr: which should make it easy for devs to work with this<br>
&lt;fantasai> Rossen_: Should we then try to resolve on percentages?<br>
&lt;bmathwig> +1 for percentages<br>
&lt;fantasai> Rossen_: Any objections for using percentages for scroll timeline values?<br>
&lt;fantasai> RESOLVED: Use percentages for scroll-timeline values<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7045#issuecomment-1083384745 using your GitHub account


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

Received on Wednesday, 30 March 2022 16:54:32 UTC