| Summary: | scroll-padding should affect scrollIntoView, paging etc even when snapping is off | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Simon Fraser (smfr) <simon.fraser> |
| Component: | Scrolling | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED FIXED | ||
| 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 |
| Priority: | P2 | Keywords: | BrowserCompat, InRadar |
| Version: | WebKit Nightly Build | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Bug Depends on: | 219073, 219074 | ||
| Bug Blocks: | 218115 | ||
|
Description
Simon Fraser (smfr)
2017-11-07 10:49:07 PST
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). Thanks for the testcase! Martin, can we consider this fixed? 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. 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. *** Bug 219072 has been marked as a duplicate of this bug. *** |