May I please take this opportunity to ask everyone to never ever consider forcing smooth scrolling upon the visitors of their websites.
Smooth scrolling is enabled by default in browsers and as a user I've therefor actively opted out of that behaviour because I genuinely dislike it and feel that it destroys my user experience. By forcing that experience on me I will have the same feelings towards your website.
This has nothing to do with that though. This is "smooth scrolling" as in animating the transition to the anchor point, compared to just jumping straight to it.
What sucks is that every smooth-scroll implementation is just another copy of "the most popular one" - a simple S-curve, where it accelerates up to a point and then begins to slow down at the midpoint. If they were implemented with a 1/x curve, you'd get the immediate response from input, without that "slow and drunk" feel typical smooth scrolling delivers, in addition to a smooth animation.
On linux (Xubuntu 16.04/ATI card) smooth scrolling in both Firefox and Chrome causes horrible tearing even with sync to vblank on, The first thing I do on both is disable it and then increase the number of lines scrolled in FF, it's a much better experience then.
mousewheel.min_line_scroll_amount set to 30 (you might need to play with it)
If you use Chrome with the open ATI driver if you go in chrome:/flags you can force it to enable hardware acceleration via "
Override software rendering list" even if it's not on the (very cautious) whitelist.
To even get to chrome://flags I have to (on first run) do google-chrome --disable-gpu then change the flag then restart.
After that everything works flawlessly, it took me a while to track that one down!.
Please note that as pointed out in the Microsoft article fron a few days ago, any JS-based scrolling is subject to main-thread jank. Instead, you should try to use the scroll-behavior CSS property [1] or scrollToOptions [2] in browsers where it is available, and only fall back to JS if it is not.
Any scrolling on the main thread (i.e. driven by JS) is subject to jank, not just user-input scrolling. CSS-based smooth scrolling of anchor links can be offloaded to the compositor because the browser knows ahead of time what is going to happen, and in those cases the smooth scroll animation can run smoothly even if the main thread is bogged down.
It is a scroll hijacking library, it's just not as wretched as most. It's not animating the links but rather animating scrolling to the links by slowing the scrolling.
Is there a way to remove this library (like de-register its event handlers etc) once it has been activated somewhere on the page?
The reason I'm asking is that I've often ran into problems with similar no-dependency libraries in highly dynamic environment, that they often leave dangling event handlers on elements, that have been since removed from the page. That leads to various memory leaks and weird bugs.
Unfortunately not available for the moment. It just registers click event if It has a trigger. Yes you are right, It should be destructible. I will do that in a couple of days.
Could someone explain why, you would choose to use something like this on your site? Every time I have experienced a site messing scroll presentation it has left me very frustrated.
Like in the demo, as long as you don't hijack native scrolling and just use it to do smooth jumps to anchors then it's fine. This library is a nice tool for anyone who doesn't want jQuery bloat on their site, but like animated transitions. Of course, there are plenty of designers who think it's a good idea to hijack scrolling...
I got the point but planning logic about for these 50 lines of code takes much more time than just import this kind of small packages. For example redux-thunk is also about 10 lines but all redux community uses it when needed.
Seriously though, the fact that this breaks the standard behavior of the anchor point becoming part of the URL bothers me more than the animation. When I hover over a link and see a URL, I'd really like clicking it to take me to that URL.
very nice also the "scroll up" looks to be more resiliant to "mouse scroll wheel" interference while auto-scrolling, while "scroll up" behave a little differently at least on edge, i dont know why, anyway it is very beauty
Without looking at the code, I thought the same thing until I read this comment for sure, and I'm not stupid all of the time.
Perhaps the library would benefit from not describing itself as 'smooth scrolling', which many of us might associate with 'hijacking the scroll wheel/trackpad'.
1) It's intrusive and destroys the user experience which ironically is what it pretends to enhance.
2) Even if it feels right on the designer's machine, we never know what scrolling implementations there may be in the future that will certainly break such gimmicks.
Smooth scrolling is enabled by default in browsers and as a user I've therefor actively opted out of that behaviour because I genuinely dislike it and feel that it destroys my user experience. By forcing that experience on me I will have the same feelings towards your website.