Bug 179379 – scroll-padding should affect scrollIntoView, paging etc even when snapping is off

• Status: RESOLVED
• Resolution: FIXED
• Component: Scrolling

[Simon Fraser (smfr)]

See https://drafts.csswg.org/css-scroll-snap/#scroll-padding

[Radar WebKit Bug Importer]

<rdar://problem/61915456>

[Diane Ko]

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).

[Simon Fraser (smfr)]

Thanks for the testcase!

[Simon Fraser (smfr)]

Martin, can we consider this fixed?

[Martin Robinson]

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.

[Matt Ryan]

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.

[Martin Robinson]

*** Bug 219072 has been marked as a duplicate of this bug. ***