Shallow dive into scroll driven animations

I'm not particularly fond of scroll driven animations in webpages (tends to come across gaudy and unsubtle) but it's undeniable that it's a common frontend trope at this point. My main issue with it is of course performance, and it seems like Chrome has been leading the charge on improving the absolute morass of jank that you get yourself into when you try to apply scroll based logic per frame with javascript.

Here is an informative article: https://developer.chrome.com/blog/scroll-animation-performance-case-study

The key change is in allowing the CSS engine to wire up animations to the scroll offset without involving the main JS thread. This is exactly what's necessary and sufficient to transform this from being awful to viable for my needs.

Unfortunately Safari has no support for it, but in the past year they have started to implement it. We are in an awkward place now where slightly over 70% of users already have the feature, which means trying to use a JS fallback is going to be suboptimal for the majority of users, but where the fallback remains necessary for all the Safari users.

One reason for me to look into this is to do something for my sticky nav bar in all my pages. I want it to be a lot more unintrusive while it's visible before you scroll all the way down, and I'd like to animate it. Unlike parallax scrolling and such things I would only want to maybe use a bit of JS to toggle a class on my nav element to switch it to/from hovering/anchored states... But, right now i am JS-free on the page and I am actually willing to make compromises to keep it that way for now for the minimalism factor. Meanwhile, I can deploy this animation-timeline scroll() based CSS for Chrome users to benefit from already, and some time next year I hope Safari users will also magically receive it.

The above is a general way to get fine animation control based on scroll state but here is a hybrid approach that might also be able to avoid impinging on the main thread.

And yet another approach is also fairly interesting, but will be pretty tricky to tweak and also leaves extra non-semantic HTML in the page. Definitely food for thought.

I would consider this to be (or at least it would have been) the place on the internet to collect solutions for the issue I'm currently having.

Truth be told though I don't actually really need the position:sticky and after reviewing all the options I'm probably going to just keep my nav at the top of pages and have static positioning for them.