[cssom-view] New feature - scroll-boundary-behavior (an extension of -ms-scroll-chaining)

[majido]

We are proposing standardization of "-ms-scroll-chaining" with some modification. The details of the proposal can be found in this WICG where it is being incubated but here is the executive summary of proposed feature:

scroll-boundary-behavior: propagate | contain | none

• propagate: propagate scroll to the parent scroller. If there is no parent scroller (e.g., viewport) user-agent may perform a default action (e.g. navigation) or show any appropriate overscroll UI affordance. This is the default value.
• contain: do not propoagate. The user agent may show an appropriate overscroll UI affordance such as glow/bounce etc.
• none: same as contain but also prevents any overscroll UI affordance e.g. bounce or glow.
  There will be scroll-boundary-behavior-{x,y} long-hands too.

Here are the differences compared to existing -ms-scroll-chaining which is fairly limited in functionality:

1. Applies to all user scrolls (not just touch/touchpad)
2. Per axis control (matching overflow-{x,y})
3. Meaningful and useful definition of chaining behavior at viewport level
4. Additional control over bounce/glow affordances

I think CSSOM View is probably the right spec to host this new attribute as it provides an API to control certain aspects of scrolling (similar to scroll-behavior in this respect).

There is some agreement on WICG that the proposed changes are reasonable and useful. So if you think this is the right spec to standardize I can start working on a pull request with appropriate changes to make the proposal more concrete. Any feedback on functionality and naming is also very welcome and appreciated.

[majido]

/cc @zcorpan @ChumpChief

[zcorpan]

Personally I think this is a reasonable proposal and cssom-view seems like a good home for the feature.

The name of the property was brought up in the WICG thread. I don't have a strong opinion at this time.

The property IE/Edge support has been discussed in the context of Houdini:
https://lists.w3.org/Archives/Public/public-houdini/2016Feb/0010.html

esphren: If everyone always implemented -ms-scroll-chain:none
always, we wouldn't need the property.
@RByers: Well, might be nice to have the ability to bubble if you
wanted, but we removed it and no one complained.

Did someone complain? :-)

It would be good to have relevant people from Apple and Mozilla also, so we don't spec and ship something that they object to. cc @hober @dbaron

[majido]

The property IE/Edge support has been discussed in the context of Houdini:
https://lists.w3.org/Archives/Public/public-houdini/2016Feb/0010.html

esphren: If everyone always implemented -ms-scroll-chain:none
always, we wouldn't need the property.
@RByers: Well, might be nice to have the ability to bubble if you
wanted, but we removed it and no one complained.

Did someone complain? :-)

I think at that point in time @RByers assumption was that -ms-scroll-chaining only applies during a single gesture and is not applicable at the beginning of the gesture. This is not correct.

Chrome has disabled chaining only during the gesture and I don't think we have any major complains there. However, it still does scroll chaining at the beginning of the gesture and I doubt very much if we ever want to disable that by default. This is the case that we see the most value for having an API that provides an escape hatch.

[majido]

@hober @dbaron do you have any major objection to the propose direction?

We like to start implementing this in Blink behind a flag to gain experience with the feature so I appreciate any public signal you can provide.

[staktrace]

FWIW I think this is a reasonable proposal and it would give us a good way to fix bug 951793 in Firefox.

[dbaron]

So from today's teleconference a number of points came up:

• across multiple (but maybe not all?) engines, this decision is made not per-pixel-of-scrolling but per-scrolling-gesture. If that's true in all engines, maybe it should just be specified that way. If not, it needs to account for differences somehow
• In Gecko at least, propagate is not the default behavior for keyboard scrolling. This should be tested as well. (But maybe it should be?)

So I think, at the very least, the initial value would need to have a better match for what today's behavior is, assuming we don't have a wide agreement to change the behavior.

There was also concern about the name of the propagate value (hard to spell) and the name of the property.

[majido]

Thanks for the feedback.

across multiple (but maybe not all?) engines, this decision is made not per-pixel-of-scrolling but per-scrolling-gesture. If that's true in all engines, maybe it should just be specified that way. If not, it needs to account for differences somehow.

We can actually leave when the decision is made unspecified and leave it up to UA implementation. I More below.

In Gecko at least, propagate is not the default behavior for keyboard scrolling. This should be tested as well. (But maybe it should be?)

I can confirm this is indeed the case in Gecko for keyboard (tested on Linux).

So I think, at the very least, the initial value would need to have a better match for what today's behavior is, assuming we don't have a wide agreement to change the behavior.

I think this is reasonable. I don't believe we need to have all UAs agree on which inputs and exactly when (per-pixel or per-gesture) they chain the scroll. All main usecases that need this feature actually care about a consistent method to prevent the default chaining as opposed to forcing chaining to happen for a particular input or at a particular time.

Here is one way we can spec this to achieve the above without taking away the UA flexibility in deciding when to chain.

• Replace 'propagate' with 'auto'. So we don't prescribe what is the default boundary behavior and leave it up to UA. This also addresses the spelling concern with 'propagate'.
• Keep 'none' and 'contain' as they are. They simply prevent the default behavior which is propagation.

[ChumpChief]

+1 for auto | contain | none, good points made about other scrolling mechanisms. We also decline to propagate keyboard scrolling in Edge by design, and for other scrolling mechanisms it may be even less clear what forcing propagation should even mean (e.g. scrollbar, JS scrolling).

Also agreed the specifics of when to propagate don't need specification. Something like this should be fine: "UAs may elect to scroll an ancestor element when the targeted element has reached its boundary in the direction of the scroll. This ancestor scrolling behavior must be disabled by..."

[majido]

If I am reading this correctly, it seems that there is enough consensus around the last proposed version of the API and its applicability. We are planning to start working on its implementation in Blink fairly soon. Perhaps, it is best to start a pull request to the spec to clarify the language and details.

BTW, in last BlinkOn conference, we had a chance to chat with some Facebook DevRel folks which mentioned they are very interested in this feature:

This would be fantastic for FB as it's the main thing blocking us from making the wheel event passive.

[bmaurer]

Confirming that this is really important to FB. We can test this out pretty quickly once it's committed to Blink.

[zcorpan]

@majido yes a pull request sounds good to me, we can discuss in more detail then.