Re: [w3ctag/design-reviews] Request review for Scroll Boundary Behavior (#193)

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](https://github.com/w3c/css-houdini-drafts/blob/master/scroll-customization-api/explainer.md) 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.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/193#issuecomment-337021324