Request review for Scroll Boundary Behavior

[majido]

Hello TAG!

I'm requesting a TAG review of:

• Name: scroll-boundary-behavior
• Specification URL: https://wicg.github.io/scroll-boundary-behavior/
• Explainer, Requirements Doc, or Example code: https://github.com/WICG/scroll-boundary-behavior
• Tests: not available but we have plans to upstream existing tests.
• Primary contacts: @bgirard, @majido

Further details (optional):

• Relevant time constraints or deadlines: We like to ship this feature in Chrome M63 (feature freeze in 24 days)
• I have read and filled out the Self-Review Questionnare on Security and Privacy. The assessment is here.
• I have reviewed the TAG's API Design Principles

You should also know that...

The current design is the result of discussion with various CSSWG and WICG members.
You can see relevant discussion on this CSSWG github issue and WICG discourse thread.

We have a working prototype implemented in Chromium behind web platform experimental features flags. The API has received positive feedback from Edge and Mozilla and addresses a real need from web developers here and here.

We'd prefer the TAG provide feedback as (please select one):

• [] open issues in our Github repo for each point of feedback
• [] open a single issue in our Github repo for the entire review
• leave review feedback as a comment in this issue and @-notify [github usernames]

[dbaron]

We discussed this very briefly in the TAG meeting this morning and again in more depth in a breakout this afternoon. A few points came up:

• Are there events that allow a page to detect and act on overscroll behavior? (perhaps a separate point, but worth looking into)
• Should this be a new property, or should this be a new part of the value on 'overflow'? It wasn't clear to us which is the right thing; in CSS this is often decided by whether the pieces should cascade together or separately.
• Another related question is whether there should be logical (inline-direction and block-direction rather than x and y) versions of these -- and also whether there should be logical versions of overflow-x and overflow-y. https://drafts.csswg.org/css-logical/ doesn't have those, though.

[majido]

Thanks for the feedback. Here is our initial thinking about these.

Are there events that allow a page to detect and act on overscroll behavior? (perhaps a separate point, but worth looking into)
Response: No currently there is no event that covers overscroll but this CSS property is complementary to something like that and does not preclude it. We have chosen to focus our effort on CSS property first as it does not require implementors to introduce a new blocking events in the performance sensitive machinery of scrolling.

I don't think however that there is a major issue with having a non-blocking event. Also there is already a scroll customization effort that aims to create low-level primitive that explain scrolling. I think that spec is an appropriate venue to explore the idea of adding an event if there is enough interest.

Should this be a new property, or should this be a new part of the value on 'overflow'? It wasn't clear to us which is the right thing; in CSS this is often decided by whether the pieces should cascade together or separately.
Response: I can imagine situations where there is a need to control SBB (scroll-boundary-behavior) independent of the overflow. For example a pull-to-refresh component is only interested in controlling the SBB but shouldn't need to control the viewpoer overflow. Another example is a page that wants to set SBB for all scrollers to be contain using a *{} rule but does not necessarily want to control the overflow that way (this later one seems a bit far fetched).

Also we have the precedent of scroll-behavior here which is an independent property. I think scroll-behavior plays a similar role as scroll-boundary-behavior which is why it is good to be consistent here. However I am not able to find the rationale for that particular decision.

Another related question is whether there should be logical (inline-direction and block-direction rather than x and y) versions of these -- and also whether there should be logical versions of overflow-x and overflow-y. https://drafts.csswg.org/css-logical/ doesn't have those, though.
Response: scroll-boundary-behavior-{x,y} was chosen to match overflow-{x,y}. I think it is reasonable to have logical directions but I suggest doing so in conjunction with adding them to overflow.
I think it is important to ensure consistency here.

[tantek]

subscribe

[majido]

FYI, there was some discussion and we reached consensus to use a slightly shorter name overscroll-behavior instead of scroll-boundary-behavior.

[dbaron]

... and the spec has moved.

[majido]

Thanks @dbaron for pointing that out. I should have mentioned this as well but I was incorrectly assuming that GH redirects the links after repo rename. It actually does so for the repo itself but not for the associated gh-pages.

Is there any concern or question regarding the above answers? Btw here is a blog post with more examples and demo of the feature.

[plinss]

Discussed in out 2017-11-21 telcon and generally approved. Our primary concern at this point is where this fits in to Houdini scrolling APIs, e.g. how can this behavior be explained in terms of the lower-level API? how does the scrolling API provide the missing pieces to implement functionality like "pull-to-refresh"? We accept this property is but one part of a larger picture, we just want to see the rest...