Clarify whether overscroll/scrollend events are fired for programmatic or instant scrolls

[fred-wang]

cc @cathiechen

Authors can use various JS APIs e.g. Element.scroll() to scroll a view. They can specify the scroll behavior to be "smooth" (i.e. animated) or "instant". Moreover, if an animated user scroll is in progress, it will be interrupted by the JS call.

• Should overscroll/scrollend events be fired when an animated programmatic scroll overscrolls/ends? Is it the case too for instant scrolls?
• Should a scrollend event be fired when an animated user scroll is interrupted by a programmatic scroll?

[cathiechen]

I wrote a case for scrollEnd. It seems touch scroll and keyboard scroll on Mac are different.
On Mac, touch scroll is not stopped by JS instant scroll, while keyboard scroll, like page down, is stopped by JS scroll.
On Linux, both touch scroll and keyboard scroll are stopped by JS scroll.
The behavior of Chrome, Firefox and WebKit is consistent.

So if the event is fired for programmatic scroll, on Mac, it might still be in a scroll animation after receiving scrollEnd event. Or maybe we can find a way to indicate which scroll has ended? For instance, add scroll type: user or programmatic?

[NavidZ]

The plan was originally to send this for all types of scrolling. Mainly this is now spec'ed here in this pull request. Feel free to comment on exact wording if you disagree with any part or just comment on the issue for css spec itself.

[cathiechen]

cc @mustaqahmed and @flackr

Hi, I'm working on a test of fire scrollend event for the combination of user scroll and programmatic scroll. The spec seems not clear for this situation. Should we clarify whether we should fire scrollend event for each scroll, or just fire one scrollend event?
I personally support fire two scrollend events. That is sure that each scroll action has a scrollend event.

[flackr]

To be clear, you're saying what happens if a user scroll is interrupted by a programmatic scroll or vice versa right? I think it depends a lot on the use cases and forgive my naivety as I'm still catching up on the rationale for adding scrollend.

I can imagine a couple major use cases:

1. The developer wants to know when a given programmatic scroll is complete so that they can highlight some content for the user in a way that would have been obscured had it been done before the scroll.
2. The developer wants to know when scroll is complete in order to initiate some user action.

In case 1, the end of a programmatic scroll is somewhat special as you could imagine there's some action that is triggered by completion of the scroll and wouldn't need to delay on subsequent scrolls. However, if there is a subsequent scroll triggered the developer may no longer want to trigger the effect.

In case 2 however, I don't think the developer would want to initiate the action (e.g. refresh a stream, load an item) if there were more scrolling happening, as some other scrolling has interrupted the user's expressed intent. I don't think the developer has a good way of knowing whether more scrolling is coming if we sent multiple scrollend events right?

[cathiechen]

To be clear, you're saying what happens if a user scroll is interrupted by a programmatic scroll or vice versa right?

Yes, and also including the cases the user scrolling is not stopped but continue to perform scrolling after programmatic scrolling, like the momentum scrolling on Mac and the pressing scrollbar scrolling.

I can imagine a couple major use cases:

1. The developer wants to know when a given programmatic scroll is complete so that they can highlight some content for the user in a way that would have been obscured had it been done before the scroll.
2. The developer wants to know when scroll is complete in order to initiate some user action.

In case 1, the end of a programmatic scroll is somewhat special as you could imagine there's some action that is triggered by completion of the scroll and wouldn't need to delay on subsequent scrolls. However, if there is a subsequent scroll triggered the developer may no longer want to trigger the effect.

In case 2 however, I don't think the developer would want to initiate the action (e.g. refresh a stream, load an item) if there were more scrolling happening, as some other scrolling has interrupted the user's expressed intent. I don't think the developer has a good way of knowing whether more scrolling is coming if we sent multiple scrollend events right?

Hmm, yes, make sense. I guess web developer would expect scrollend event fires when the element actually stops scrolling. It fires two scrollend events in my local WebKit patch:( It seems easier to implement. But I think combining the scrollend events is reasonable to me. I guess it is not limited in user scrolling + programmatic scrolling scenario. Only one scrollend event is fired in any scrolling combination scenario. Right?

[flackr]

Right, exactly! I think that it would be too difficult to use scrollend if it were fired at times when there still is more scrolling queued (just by a different scrolling mechanism).