Scroll anchoring opt out / exclusion API (overflow-anchor)

[skobes-chromium]

Scroll anchoring is a mechanism for preventing visible jumps from offscreen content changes, described in detail here and at https://skobes.github.io/ScrollAnchoring/.

This is a proposal to define the CSS overflow-anchor property as described in the spec. Please report any concerns about the design here, or under https://github.com/skobes/ScrollAnchoring/issues, or on the blink-dev intent-to-ship thread, or on the tag review thread, or on the WICG transfer proposal.

[RByers]

Note that we're shipping this in Chrome 56 despite failing to get much feedback from other engines. Given the user enthusiasm , I suspect there will eventually be more interest. The actual API surface area is tiny and rarely needed, so I'm optimistic we can continue to incubate, including making breaking changes if it becomes necessary to get interop in the future.

[FremyCompany]

I provided some feedback during last TPAC, but I just had a look and the spec is in much better shape now than it was back then. I am glad Google decided to went with it and get the feature used in the wild. Please report the experiments results further when you have them!

I am not a huge fan of the anchor node heuristic but I want to see the feature being used by more users and get feedback on how often it mistriggers before making another proposal; I don't want to create work just for the sake of creating work.

[RByers]

Thanks Francois! Yeah there are a ton of tough tradeoffs around web compat here. We will learn a lot more as this makes it to Chrome stable and we get more feedback from users and developers. We'll keep iterating here.

If you think Edge may be interested in working with us more on this, then perhaps we should move the repo to the WICG to get some basic IP protection? If so just express Microsoft interest on WICG discourse.

[FremyCompany]

I am not aware of such plans and I am not the right person to chime further on this, scroll being a feature that does not belong to the layout team. But a successful experiment would help drive traction, of course.

[RByers]

Note the spec and explainer are now here: https://github.com/WICG/ScrollAnchoring

[css-meeting-bot]

The CSS Working Group just discussed TAG review of scroll anchoring, and agreed to the following resolutions:

• RESOLVED: Request to graduate from WICG to CSSWG

The full IRC log of that discussion

<surma> Topic: TAG review of scroll anchoring
<rbyers> https://github.com/WICG/ScrollAnchoring/blob/master/README.md
<rbyers> github issue: https://github.com//issues/676
<rbyers> Video: https://blog.google/products/chrome/taking-aim-annoying-page-jumps-chrome/
<fantasai> rbyers: gave a presentation on i t at TPAC
<fantasai> rbyers: wanted it to be opt-out, not opt-in
<surma> rbyers: This is a feature to avoid jumping while the page is loading. We talked about it at TPAC. We didn’t want it to be opt-in, so we needed to make sure the heuristics are good. We have written all the details in the spec. Shipped in Chrome 55. We see it used on 10% of pages views on Android. The pages that use it hit the heuristics 5 times poer page
<surma> load
<surma> rbyers: We wanted to check if theres other interest. We can still make changes.
<surma> [general signals of interest]
<surma> rbyers: People didn’t notice they had this problem. Now that Chrome corrects it, it might get worse in other browsers.
<surma> rbyers: Should we warn on console about hitting the heuristics?
<surma> rbyers: We are careful about spamming warnings
<surma> dbaron: I‘d want this to work when I resize a window, too. That shouldn‘t issue a warning.
<surma> [rbyers checks if it is tie to resizing too]
<surma> Rossen: Let say you have implemented snap points. How much can be built on top of this
<surma> TabAtkins: nothing
<surma> rbyers: This lets you customize what is considered an anchor. Snap points set the anchors.
<surma> Florian: Is this writing-mode aware?
<surma> rbyers: It should be
<surma> Florian: The interesting part is that the implementation is complex, but the api is small, so changes can be made in the future to the heuristic
<surma> fantasai: We should publish a FPWD through CSSWG(?)
<surma> TabAtkins: Since Google is a member of the group, any Googler can continue work on the draft, even if the person themselves is not a member of the group. Correct, ChrisL ?
<surma> ChrisL: I think so, yes
<surma> ChrisL: If they are not a member, tho, what if they start doing whatever they want
<surma> astearns: we take them off as an editor
<surma> fantasai: Its better for the editor to be a member of the group for access to all the tools etc
<surma> rbyers: we’ll ask him to join
<fantasai> fantasai: No expectation of him showing up to meetings etc.
<surma> Rossen: this is in WICG, no? What is the migration process?
<surma> Florian: We just did it
<surma> Rossen: not sure that is the case
<surma> astearns: We dont have a clear handoff
<surma> Florian: We take the spec, put it in our repo
<surma> rbyers: We’ll ask cwilso how to migrate
<surma> Rossen: We’d like to know as well for future WICG migrations. There used to be a high bar, I don’t want to just ignore/circumvent that
<surma> TabAtkins: Worst case I’ll be co-editor
<surma> astearns: It could be nice to have the editor on calls to have their expertise
<surma> RESOLVED: Graduate scroll-anchoring from WICG to CSSWG
<surma> RESOLVED: Request to graduate from WICG to CSSWG

[xfq]

Should we close this issue now?