- From: Robert Flack via GitHub <sysbot+gh@w3.org>
- Date: Mon, 27 Mar 2017 22:20:33 +0000
- To: public-css-archive@w3.org
> Agenda+ to discuss adding it to an actual spec draft. If this is something we want to add, we should have it in a draft somewhere and people can file issues on specifics. We (@flackr, @majido, @RByers ) will be in Tokyo for the CSSWG meeting and would be happy to lead a session to get into details there if this would be helpful. We can draft up something after Tokyo F2F if that makes sense. > Also, since this is (afaict) a CSS property and not an OM feature, it probably belongs in css-overflow rather than cssom-view... No particular opinion here. It will be great if we land on an answer here in next telecom. The original rationale for why cssom was in comment#1: > 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's a related proposal with a confusingly similar name 'overscroll-action': https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/Uzit4zDQ1ps/pD_3k2rqBAAJ I have chatted with @majido to ensure we are on the same page with regards to the overscroll-action vs scroll-boundary-behavior API: > overscroll-action applies to the gesture on the viewport for history navigation (2 finger swipe back on Mac) and pull-to-refresh. A bit of history here, we developed overscroll-action API idea first in response to a specific set of overscroll navigation usecases. But now we think it is possible to address those use cases with scroll-boundary-behavior API in a simpler and more generic way. > I find the nomenclature a bit confusing because 'overscroll-action: auto' would suggest that the element would behave as if it had 'scroll-boundary-behavior: propagate' which is orthogonal. > 1. Should the two proposal be considered orthogonal? If so it allows over-scroll animations (glow/bounce) to be toggled independently from navigation gestures. We should avoid having two different ways to control overscroll navigation actions. So if we allow scroll-boundary-behavior to control overscroll navigation then it is best to ditch overscroll-action. Toggling overscroll animations independent from navigation gesture could be accomplished using the extended API you proposed in #3. > 2. If we consider the specifications to be orthogonal can we come up with better nomenclature? I would suggest that 'navigation-action' would be better name 'overscroll-action'. > 3. Right now it's not possible to propagate scrolling while disabling the overscroll animation. If this is something that's important perhaps a better proposal to cover the 4 logical states could be: scroll-boundary-behavior: [auto || [ [propagate || contain] | [overscroll || no-overscroll] ] I think it’s best left to the UA’s discretion whether showing a bounce or glow makes sense when you are going to propagate the scroll. The intention of disabling it is to allow the author to control the containment case. > 4. Does 'overscroll-action-x: contain' behave as if 'overscroll-action: no-navigation-x' was set? From an implementation point of view I believe 'overscroll-action-x: contain' should behave as if the script was performing preventDefault on any overscroll and thus disallow events from reaching the viewport and thus would implicitly disallow overscroll (navigation) actions. scroll-boundary-behavior-x: contain (I assume you meant scroll-boundary-behavior-x since contain is not a property of overscroll-action-x) does behave as if overscroll-action: no-navigation-x was set as the scroll does not propagate to the “default” browser behavior, e.g. this may be navigation, refresh, etc. This is equivalent to the script performing preventDefault on the additional events as you had suggested. -- GitHub Notification of comment by flackr Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/769#issuecomment-289603479 using your GitHub account
Received on Monday, 27 March 2017 22:20:39 UTC