It doesn't sound like it from the article, but I wish other scrollbar misbehavior was included in this work. Scroll wheels and touch are not the only way people scroll! I wish they would also work on the broken scrollbar behavior when content is added to page while the scrollbar handle is being dragged. For example, pages which append new batches of content as you approach the bottom.
The symptom is that it treats the scrollbar position as a ratio of page length, and as the page length changes, the viewport is suddenly warped to a new position at the same ratio of the new page size. To fix this, I think it should continue to use the old page length to calculate scroll position until you release the drag. You won't always be able to scroll past the previous end of page in one movement, but the content visible in the viewport should remain coherently related to your drag motions.
I recognize that something has to be made inconsistent in the ratio-based scrollbar UX if the page length changes. I think having the scrollbar handle jump away from the mouse cursor on drag-release would be much less annoying than having the viewport jump around on each DOM edit. You can continue reading what you were reading and only be distracted when you need to go find the handle again to scroll further down, much like if you accidentally let your mouse drift out of the scrollbar and then released the drag.
Indeed; they made tabs work similarly a long time ago (tabs do not resize when you close a tab until you move your mouse away) and this made closing tabs so much better. Infinite scrolling on sites is so painful when using the scrollbar.
There isn't really an incentive to opt out. The constant referencing of ads is a bit misleading. It's just that ads happen to very often be the slowest loading content on the page, which causes lots of annoying reflows. Really it's any image, video, or any kind of embedded element whose size is not known during the initial page render. Ads just happen to be a serial offender for this, because they are typically served by 3rd party networks, so the page cannot reserve a particular bounding box as is usually done with images.
It's not that sites are intentionally scrolling ads into view. In the rare cases where they do that, scroll anchoring won't make any difference anyway. Usually what happens is that the content just changes position randomly, whether or not the ad is even within the viewport.
The weird thing is it used to be less of a problem, because people used the damned height and width attributes in the img element. So the browser could calculate the dimensions before and lay the document out correctly before the slow loading images came in.
Now people largely ignore them, use publishing tools that don't bother, and dynamically build pages with garbage scripts instead of having a sane document already marked up.
I've wanted this to be a thing for about 20 years! Back then I didn't understand how it could be so difficult. Well, I guess I still don't. But I'm glad it's finally happening in my lifetime.
This is great! Pages usually jump up and down multiple times.
I need one more thing. Prevent the same jump up/down behavior when using infinite scoll. E.g. if you use scoll bar to scroll down, new content apprearing changes the page height, making the scroll bar recalculate its position, and the whole thing jumps.
Likewise, when I press the browser back button tp go back to the page with infinite scroll, it is only hard to find the point on that oage where I was.
I think I'd rather prefer not having the opt-out option. Although ultimately I feel like if you're malicious enough, you can fool the algorithm to produce the behaviour that you're looking for.
The need/audience for the opt-out option is for websites with legit behavior that is broken by the guesswork involved in scroll anchoring implementations. If a site wants to be "malicious" towards their users, there are myriad ways to do that already.
The symptom is that it treats the scrollbar position as a ratio of page length, and as the page length changes, the viewport is suddenly warped to a new position at the same ratio of the new page size. To fix this, I think it should continue to use the old page length to calculate scroll position until you release the drag. You won't always be able to scroll past the previous end of page in one movement, but the content visible in the viewport should remain coherently related to your drag motions.
I recognize that something has to be made inconsistent in the ratio-based scrollbar UX if the page length changes. I think having the scrollbar handle jump away from the mouse cursor on drag-release would be much less annoying than having the viewport jump around on each DOM edit. You can continue reading what you were reading and only be distracted when you need to go find the handle again to scroll further down, much like if you accidentally let your mouse drift out of the scrollbar and then released the drag.