Add animation-range support for ScrollTimeline

[bramus]

This PR adds support for animation-range for ScrollTimeline based SDAs. It is done by parsing the animation range (with a fallback to the defaults of 0% and 100%) and then calculating the relative ScrollTimeline position. This flow has been copied over from how ViewTimelines are being handled.

It also includes a little refactoring that splits off normalizeAxis into its own function, as the logic to determine that ended up being present 3 times in the source code.

Fixes #151.

[bramus]

Addressed the remarks (+ merge conflict), but am wondering: maybe I should also move the parseAnimationRange functions onto the classes as statics?

[ryantownsend]

+1 for this issue – great to see the PR @bramus

My usage includes viewport units which I can see aren't included in the PR, would that be straight-forward to introduce? I'm not asking you to do it, I'm happy to contribute if I can, I'm just unfamiliar with the codebase – I just figure the responsive nature of viewport units could be tricky if the values are evaluated on discovery rather than in 'real time'.

[bramus]

@ryantownsend I once started a PR to add viewport units – #52 – but that one has stalled. Haven’t found time to further look into it, but feel free to pick it up. It’s quite an old PR, so does need a rebase …

[kevers-google]

Hi Ryan,
If you would like to contribute, I'll be happy to review the code. Alas, I'm a bit short on free cycles, or I'd dive in and help tidy things up.

[ryantownsend]

Thanks @bramus / @kevers-google – I'll see if I get some time over the next week or so.

[bramus]

Converting to draft as I noticed a bug in the calculations … need to dig into that.

[bramus]

FYI: I’m awaiting some of the refactors from @johannesodland’s PRs before picking this one up again.

[bramus]

I think I re-landed the changes of the original branch on top of master. As I suspected, the issue with the wrong range being applied got fixed thanks to #176 (confirmed through manual testing)

The tests, however, don’t seem to have made a huge jump: only 2 extra tests pass. Also seeing timeouts for the tests with the timeline-range … that needs to be looked into.

Changes have been included while re-landing this commit.

[bramus]

Addressed all remarks. Requesting a new review, @flackr @johannesodland

[johannesodland]

LGTM 👍

I've added some comments with regards to #209 that adds a function to split a string into component values.

If we merge #209 first we should use that function here, otherwise I can include those changes in #209.

[flackr]

Looks good.