- From: David Bokan via GitHub <sysbot+gh@w3.org>
- Date: Thu, 07 Apr 2022 22:38:38 +0000
- To: public-css-archive@w3.org
@emilio @smfr since I came across this recently again while fixing a bug in a related area.
I've written a test case to help show the different behaviors: https://mparch-bokan.glitch.me/bug/scrollIntoView-fixed.html
Each orange box is position: fixed with a child target that gets `scrollIntoView({block:'start', inline:'start'})` called on it:
Box A: Is unscrollable
Box B: Is scrollable
Box C: Is unscrollable and inside an iframe
Box D: Is scrollable and inside an iframe
### Bubbling Behavior
Box A: No scroll - all engines agree
Box B: Container scrolls, no window scroll - all engines agree
Box C:
* Safari: Scrolls outer window so that target is in top left corner
* **Firefox: No scroll**
* **Chrome: No scroll**
Box D:
* Safari: Scrolls container, scrolls outer window
* Firefox: Scrolls container, scrolls outer window
* **Chrome: Scrolls container**
IMO Chrome's behavior is clearly a bug in the C/D cases. I also think the Firefox behavior in C seems like a bug; the fact that the container is scrollable shouldn't make the different of whether to bubble the scrollIntoView up to the outer window. I'd propose adopting Safari's behavior in the spec, WDYT?
### Clipping Behavior
If you tick the checkbox it'll shift the position: fixed elements so that the target, after being scrolled into view in the container, is outside of the frame.
Box A: No scroll - all engines agree
Box B: Container scrolls - all engines agree
Box C:
* Safari - Scrolls outer window to target location (i.e. where the target would be if it weren't clipped)
* Firefox - No Scroll
* Chrome - No Scroll
Box D:
* Safari - Scrolls container then scrolls outer window to target location
* Firefox - Scrolls container then scrolls outer window to target location
* Chrome - Scrolls container
When I fix the bug for the bubbling behavior Chrome has the same behavior as Safari but it seems unintuitive to me to scroll something into view that isn't visible.
I wonder though if changing that is web-compatible. In Chrome we intersect the target's rect to the scroll port rect each time we bubble up but we have an edge-case that sets an empty rect dimension to 1px that IIRC we had to add for web compat.
I'll try to put together a more exhaustive test set for how scrollIntoView behaves w.r.t. overflow clips but any thoughts you may have here would be helpful.
--
GitHub Notification of comment by bokand
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5492#issuecomment-1092274017 using your GitHub account
--
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 7 April 2022 22:38:40 UTC