Scroll anchoring ignores scroll-padding
Categories
(Core :: Layout: Scrolling and Overflow, defect, P3)
Tracking
()
| Tracking | Status | |
|---|---|---|
| firefox71 | --- | fixed |
People
(Reporter: tomapaunovic, Assigned: emilio)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/77.0.3865.90 Safari/537.36
Steps to reproduce:
- Enable layout.css.scroll-anchoring.highlight
- Set scroll-padding-top to non-zero value on html and body tag
- Verify it's working by executing scrollIntoView to some element -> you should see offset equal to scroll-padding-top
- Scroll anchoring is still anchoring from top of the viewport
This is contrary to CSS-Scroll-Anchoring specification since scroll-padding-top should modify "optimal viewing region" which scroll anchoring uses to determine eligible anchor nodes. More details
https://drafts.csswg.org/css-scroll-anchoring/#anchor-node-selection
https://drafts.csswg.org/css-scroll-snap-1/#optimal-viewing-region
Actual results:
Scroll anchoring is still trying to anchor on elements on top of viewport, regardless of scroll-padding value, while scrollIntoView works as expected. So if I combine scroll-padding with scrollIntoView and some dom changes (elements collapsing etc) I get unwanted scroll jumping.
Expected results:
Optimal viewing region should be modified by scroll-padding and scroll anchoring should use that area. For example, if we have scroll-padding-top: 100px, scroll anchoring should not anchor elements that are in the top 100 pixels of the viewport.
In other words, if there is a fixed navbar on top of the viewport and scroll-padding-top is set to the height of the navbar, then scroll anchoring should anchor elements right below the navbar as opposed to elements on top of the viewport (which are under navbar).
CSS-Scroll-Anchoring specification specifies that scroll-padding-top should modify "optimal viewing region" which scroll anchoring uses to determine eligible anchor nodes. More details
https://drafts.csswg.org/css-scroll-anchoring/#anchor-node-selection
https://drafts.csswg.org/css-scroll-snap-1/#optimal-viewing-region
|
||
Updated•5 years ago
|
|
Assignee | |
Updated•5 years ago
|
|
|
Assignee | |
Comment 1•5 years ago
|
||
Ryan, what was the reasoning for using the visual viewport rather than the scrollport for the root? Spec only says to use the scrollport (blink uses yet a different thing, I think, but it seems to be the layout viewport... Also doesn't seem to account for scroll-padding).
It would've been nice to have a test for bug 1518640. Or a spec change proposal, maybe...
Reason is that scroll-padding percentages are resolved against the scrollport size... Not opposed of having them resolve against a different thing here, but it's not clear what is the right thing to do here...
Should we just switch back to use the layout viewport and account for scroll-padding? Or something else?
|
|
Assignee | |
Comment 2•5 years ago
|
||
Unclear whether the visual viewport code path is the right thing to do at all.
|
||
Comment 3•5 years ago
|
||
Bug 1518640 was motivated by some negative experiences I had with local debugging of a test case. It probably slipped my mind that the spec was referring to the layout viewport there. Although I don't know what level the visual viewport is specified yet anywhere either. So I'd lean towards matching Chrome's behavior here if possible.
And the reason scroll-padding isn't accounted for is because it didn't exist when scroll-anchoring was implemented, it wasn't an oversight.
|
||
Comment 4•5 years ago
|
||
I recall having a conversation with Ryan about bug 1518640 and concluding that the visual viewport is the closer fit for what scroll anchoring is trying to accomplish conceptually.
Scroll anchoring is trying to make sure that the content you are looking at remains on-screen in the face of changes like content above loading or screen rotation. If you're zoomed in, the visual viewport is what's actually on-screen, so it makes sense to use an anchor inside the visual viewport. Otherwise, scroll anchoring could actually cause what's in the visual viewport to shift, such as in the scenario described in bug 1518640 comment 0.
I don't think it's clear that "scrollport" in a spec refers to the layout viewport in preference to the visual viewport. I think most specs gloss over the distinction. For a long time (prior to bug 1423011), our "scrollport" effectively was the visual viewport on mobile.
Pushed by ealvarez@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/c10147827a4f When using the scrollport, account for scroll-padding for anchor node selection. r=botond
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/19472 for changes under testing/web-platform/tests
Can't merge web-platform-tests PR due to failing upstream checks: Github PR https://github.com/web-platform-tests/wpt/pull/19472 * Taskcluster (pull_request) (https://tools.taskcluster.net/task-group-inspector/#/Uo8IqJFQT0aWb-r4wZQUmw)
Pushed by emilio@crisal.io: https://hg.mozilla.org/integration/autoland/rev/a49132352f5b follow-up: Rename a test so that it doesn't collide with css/css-scroll-snap/scroll-padding.html. r=me CLOSED TREE
|
|
Assignee | |
Updated•5 years ago
|
Upstream web-platform-tests status checks passed, PR will merge once commit reaches central.
|
||
Comment 10•5 years ago
|
||
| bugherder | ||
|
||
Updated•5 years ago
|
|
|
||
Comment 11•5 years ago
|
||
| bugherder | ||
Upstream PR merged by moz-wptsync-bot
|
||
Updated•5 years ago
|
|
||
Comment 13•5 years ago
|
||
Removing qe-verify+ from this bug since it's covered by automated test.
Description
•