New issue
Advanced search Search tips
Note: Color blocks (like █ or █) mean that a user may not be available. Tooltip shows the reason.

Issue 635719 link

Starred by 2 users
Status: WontFix
Owner: ----
Closed: Oct 2016
Cc:
█ ymalik@chromium.org
█ kenjibaheux@chromium.org
ojan@chromium.org
█ tabatkins@chromium.org
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug

Blocking:
issue 558575



Sign in to add a comment

[scroll anchoring] add opt-in distinct from auto behavior

Project Member Reported by skobes@chromium.org, Aug 9 2016 
Scroll anchoring has accumulated a lot of hacks and heuristics for web compatibility.  To get a saner platform, we could extend overflow-anchor to support three modes:

- none - opt out, no scroll anchoring
- auto - default mode, scroll anchoring with hacks
- visible - opt in, scroll anchoring without hacks

In the opt in mode, we would disable the following hacks:

(1) bounce suppression (for  issue 598233 ,  issue 601906 , and  issue 603376 )
(2) limit of 20 adjustments between user scrolls (for  issue 601906 )
(3) exclusion of position:absolute with non-zero left/top (for  issue 604996 )
(4) suppression during non-scrolling drag gestures (in progress for  issue 628074 )
(5) suppression after border/padding changes (in progress for  issue 630788 )

(Note that hack #5 might obviate the need for hacks #1 and #2.)

Ojan also asked to change "visible" back to "viewport" contrary to suggestion on https://github.com/WICG/interventions/pull/20 review thread.  I have no opinion either way on that.

Comment 1 by tabatkins@chromium.org, Aug 10 2016 

Those values and meanings sound pretty reasonable to me.  We should pull this out to a proper independent WICG spec intended for CSSWG consumption.

I'll fight Ojan over the name; "viewport" isn't great for this.

Comment 2 by ojan@chromium.org, Aug 10 2016 

Does it count as a fight if one side doesn't fight back? I don't care about the name. :)

Comment 3 by ymalik@chromium.org, Aug 10 2016 

How will the behavior for 'auto' be explained on the spec / to the developers? Is the aim here to ultimately converge 'auto' with 'visible'?

Comment 4 by skobes@chromium.org, Aug 10 2016 

The approach we've taken so far is to spec all the hacks, so I assume we will continue to spec the "auto" hacks.

Convergence would be nice but I wouldn't count on it happening.  If we need the hacks today we will probably need them for the forseeable future.

Comment 5 by dtapu...@chromium.org, Aug 25 2016

Labels: Hotlist-Input-Dev

Comment 6 by skobes@chromium.org, Sep 6 2016 

I think this is lower-priority now thanks to SANACLAP (r413010), but keeping it open pending discussion on https://github.com/WICG/interventions/issues/2.

Currently the only changes our hypothetical opt-in would trigger are:

(1) disabling SANACLAP
(2) disable position-change suppressions proposed for  issue 641814

Comment 7 by skobes@chromium.org, Oct 26 2016

Status: WontFix (was: Available)
Let's close this one - after  issue 658834  we have an even smaller set of suppression triggers, and I haven't heard strong support for adding an opt in.
►

Sign in to add a comment