- From: Majid Valipour via GitHub <sysbot+gh@w3.org>
- Date: Tue, 30 Jun 2020 14:07:59 +0000
- To: public-css-archive@w3.org
[Earlier](https://github.com/w3c/csswg-drafts/issues/4912#issuecomment-606740077) in this thread I speculated if we should allow "offsets" for these scrollOffset similar to how we have these on keyframes. My conclusion then was that perhaps its complexity is not justified but I wonder if having offset makes achieving the desired clamping behavior without unnecessary speed up actually simpler. Consider if we actually have implied offsets for the current example. So `[100, 300, 200, 400]` is actually interpreted as the following map: `{0 => 100, 0.33 => 300, 0.66 => 200, 1 => 400}`. Notice the implied input offsets are equi-distance in the case where no offset is provided by the author. The logic for clamping then detects any series of offsets that don't match the expected order then it clamps *both the values and their offsets* to the middle point. So in the example case it will turn it into `{0 => 100, 0.5 => 250, 0.5 => 250, 1 => 400}` (or even `{0 => 100, 0.5 => 250, 1 => 400}` if we eliminate duplicate entries for `0.5 => 250`) The advantages are: - Achieves the most preferred outcome where animations are not sped up. - Easier to reason about since the output of scroll timeline can easily be determined given the calculated offset. - More consistent with keyframes having offsets. - We can allow authors to provide offset for better ergonomics in more complex cases. -- GitHub Notification of comment by majido Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4912#issuecomment-651814938 using your GitHub account
Received on Tuesday, 30 June 2020 14:08:01 UTC