|Summary:||scroll-padding should affect scrollIntoView, paging etc even when snapping is off|
|Product:||WebKit||Reporter:||Simon Fraser (smfr) <simon.fraser>|
|Severity:||Normal||CC:||709922234, alex, charlie.croom, diane.ko, julien.roncaglia, kyle.bavender, lfloyd, mqr5815, mrobinson, simon.fraser, steffen.weber, viktor.holmberg, webkit-bug-importer, wenson_hsieh|
|Version:||WebKit Nightly Build|
|Bug Depends on:||219073, 219074|
Description Simon Fraser (smfr) 2017-11-07 10:49:07 PST
Comment 2 Diane Ko 2020-07-30 15:24:57 PDT
From the CSS spec definition for scroll-padding (https://www.w3.org/TR/css-scroll-snap-1/#scroll-padding), scroll-padding should apply to any scroll container, not just scroll snap containers. This issue is particularly problematic when using scroll-padding to adjust for any fixed content (for example, a fixed header or footer). This behavior exists on both iOS and macOS Safari, but not on Chrome or Firefox. Note: this is particularly problematic when using iOS with VoiceOver on, as VoiceOver will trigger tapping on the location where its focus is, which means that if you're focused on an element that's underneath a fixed container, the click event will trigger on the fixed container and not the element that gets read out as having focus. As this issue isn't a problem in Chrome, I was able to successfully avoid this issue on an Android device with TalkBack enabled. I created a really basic codepen (https://codepen.io/backwardok/pen/6980c6068b69618a90bd5b12716dde8b) that demonstrates this problem (full page version: https://cdpn.io/backwardok/debug/6980c6068b69618a90bd5b12716dde8b).
Comment 3 Simon Fraser (smfr) 2020-07-30 15:36:48 PDT
Thanks for the testcase!
Comment 4 Simon Fraser (smfr) 2020-12-16 17:06:49 PST
Martin, can we consider this fixed?
Comment 5 Martin Robinson 2020-12-17 04:18:37 PST
The main blocker here is to implement the part of scroll-padding that affects scrolling area paging behavior. I don't think this should be a lot of work, but I've been dragging my feet a bit here.
Comment 6 Matt Ryan 2021-01-14 13:15:21 PST
This is a major blocker to site authors implementing sticky-position banners; there is seemingly no alternative that works across the various use cases out there; for example, a common CSS approach (negatively absolute positioned generated content) does not work if the fragment refers to a replaced element like an <input>. And Safari is the only major browser that does not properly support this feature. I'm hoping this comment can serve as a +1 on prioritizing this bug.