Replace scrl with a native scroll implementation

[hirasso]

Closes #87

Description

• remove the dependency to gmrchk/scrl, decreasing the bundle size while increasing the feature set
• support scrolling the closest scrollingElement as seen from an anchor element (overflowing div, dialog,...)
• keep the hooks working
• keep the autoKill feature working (cancel the scroll upon user interaction)
• keep the maximum scroll position detection (prevent a sudden stop at end of scroll container)
• still worth a major version I think, as the default scroll animation changes significantly with this vs. scrl
• maybe the major version would be a good chance to add support for scrolling on the x-axis if necessary, as well?

I'm surprised how well this whole thing works! The "scrollend" event I'm using to dispatch the "scroll:end" hook doesn't work in safari just yet – but I've never actually used it, so I'd be fine with it being missing.

Checks

• The PR is submitted to the main branch
• The code was linted before pushing (npm run lint)
• All tests are passing (npm run test) OMG this plugin doesn't have any tests yet 😂
• Tested in local playground with both window and overlays
• The documentation was updated as required

[daun]

Fantastic! 🥳 I'll give this a try soon. Major version sounds good, since the scroll duration is now different and some sites might rely on that. Also, all in favor of finally adding tests! Although I suspect there's a reason it's currently untested — lots and lots of flaky Playwright magic...

[hirasso]

Yeah... let alone the fixtures we'll need for writing proper tests 🤯😅

[daun]

I love it, works great! Scrolling is quite a bit smoother when using the native implementation.

Would be amazing to extend this and both scroll the overflow container into view, as well as scroll the container to reveal the nested anchor element. Recursive scrollIntoView, so to say. I'll see if I can make it work without too much contortion...

And I'd like to think of a nicer API than overwriting the scrollTo method. This screams "replaceable hook" to me :)

[hirasso]

Should we still do these things in separate PRs? This one changes a lot already.

[hirasso]

Maybe we could merge these things into a next branch. And publish that branch as a beta to npm?

[daun]

Yes to both! I've started tinkering with this on a separate branch. Let's merge this one into develop or next and take it from there. Personally, I'm fine with testing this locally using symlinks or yalc, I'm a bit hesitant to juggle the whole npm release tag thing 😅

[daun]

Maybe we can revert the changes to the readme where the linter added ; after every line of JSON :(

[daun]

I've created PR #89 we can use as a launchpad for further improvements once this is one merged 🥬

[hirasso]

Merged this into next. We can base all upcoming PRs to that branch.

[hirasso]

While at it I also renamed the master branch to main. #90 is already based on that branch.