What case does this make simpler by doing this?

My first reaction is that we should treat programmatic scroll the same as user scroll. Programmatic scroll is largely used to implement custom scrolling. As far as the user is concerned, the page is scrolled though. They don't know or care that under the hood it wasn't done via the built-in browser scroll. If an image loads above where they are, they still don't want the content to move around.

I think it's surprising for web developers if their explicit instruction to set a scroll position is overridden.  The conservative thing is to avoid anchoring in this case.

There are many scrolling features (fling gestures etc.) that don't work with "custom scrolling" unless the web author implements them by hand.  I'm not sure why scroll anchoring should be different in this regard.

There's a tradeoff between developer predictability and user experience here. But, I actually expect that the majority of web devs would want the anchoring to work with their custom scrollers. I worry that we'll be forcing them off a big cliff...any page that uses custom scrolling now starts annoying users.

Also, this is actually not possible for web authors to implement by hand in any reasonable way that I can see.

If we're worried about surprising web developers, I'd rather we do the thing that's best for users and make sure to have an opt-out for web authors that they can use when they don't want that behavior.

"any page that uses custom scrolling now starts annoying users."

Shouldn't this be: 
 v1: "page that don't use custom scrolling may be less annoying to users."
 v2: we figure out how to make Scroll Anchoring work with custom scrolling


"The conservative thing is to avoid anchoring in this case."
+1 for v1.

Why do we want to do the conservative thing to start with? Lets try the aggressive thing that's the best user experience. We can easily scale it back before shipping (or after even) if we find content that breaks.

I'm worried that we won't realize that it breaks things until it reaches stable. At which point, we would have to turn it off for up to 2 milestone (assuming we can't merge the patch) :(

I would rather take less risk and work* and make a difference that stick.


*: "make sure to have an opt-out for web authors that they can use when they don't want that behavior." <= extra work, potentially pushing the time at which we can deploy the first iteration of the intervention.

I guess the main concern here is that when a developer programmatically sets scrollTop, and an image loads above the viewport, the page will not be where the developer expects it to be? If that's true, presumably without scroll anchoring, the user isn't where the developer wants it to be (or think it is) anyway right?

What's the exact use case for scroll anchoring in relation to programmatic scrolls?

Also, do we want scroll anchoring to entirely be an under the hood feature or are there plans to tell the developer that the browser intervened? Presumably we can send an event to js every time a scroll is adjusted.

We are potentially breaking any site where Javascript sets scrollTop = X and then changes the DOM in some way.  The developer may be intending the user to be at position X after the change.

I don't think the scroll event should expose the fact that it came from scroll anchoring.  But I do think there should be an opt out (thus not entirely "under the hood").

+1 to giving some kind of opt-out. Let's file a new bug to track figuring out the proper opt-out mechanism?

As for resolving this discussion, let's look at a few real world cases of programmatic scroll and see whether they'd be better off with scroll anchoring on or off.

SGTM.  Filed  issue 599180  for figuring out the opt out mechanism.

If we have an opt-out, this is probably not important to do.