- From: Majid Valipour via GitHub <sysbot+gh@w3.org>
- Date: Tue, 31 Mar 2020 16:38:18 +0000
- To: public-css-archive@w3.org
This is an interesting idea which I am in favor of. I can see how multiple scroll offsets can simplify the API and is more ergonomics due to the fact that it can be paired with multi-frame keyframe effects.
Follow the processing logic for keyframes here are some ideas on how to spec and implement this:
- Consider single-entry offsets as being the "end"
- We need to have the scroll offset in increasing order otherwise time can go negative in some sections which is almost definitely a bug (Issue #4351 but supercharged!). There are two options:
1. require scroll offsets to be in increasing order and error if not otherwise. This is consistent and easy to debug behavior.
2. allow scroll offsets to be provided in any order, sort them before using them to ensure the are in increasing offsets. This may work better with element-based offsets whose exact value may not be known before starting the animation.
- Treat these scroll offsets as equal-distanced in time. This is similar to having keyframes with no `offset` on them. See [compute missing keyframes offsets](https://drafts.csswg.org/web-animations/#compute-missing-keyframe-offsets) in web-animations for how this works.
- Note: While keyframes may have an additional offsets specified on them but it is not clear if we should allow these for scrollOffsets. The additional complexity is not justified at the moment and we can add it later.
/cc @flackr @ogerchikov @birtles for awareness and in case they have suggestions here.
--
GitHub Notification of comment by majido
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4912#issuecomment-606740077 using your GitHub account
Received on Tuesday, 31 March 2020 16:38:21 UTC