Created attachment 348974 [details] chrome canary (top), safari tech preview (middle), and firefox nightly (bottom) Steps to reproduce the problem: 1. Open up chrome canary, safari tech preview, and firefox nightly. 2. Go to this test case in each browser -> http://next.plnkr.co/edit/e5bsCLIIF5rtiFOJ?preview 3. Notice how each browser treats negative margins on the green sticky element differently. 4. The case highlights differences in... - Inaccessible overflow at start edge - Negative margin on the top edge creating "negative" margin on subsequent sibling element - Negative margin on the top edge treated differently based upon containing block being the scrolling block with padding or not? What is the expected behavior? Uniform position sticky layout between major browsers. What went wrong? Major browsers rendering engines behave quite differently when dealing with negative margins on stickily positioned elements. The attached image shows screenshots of the same test case rendered in chrome canary (top), safari tech preview (middle), and firefox nightly (bottom). Left side scrolling box has padding, right side scrolling box has a child inside it with equivalent padding values.
In that this is about compatibility and not spec related, here are links to the same issue filed with other browsers. - https://bugs.chromium.org/p/chromium/issues/detail?id=881102 - https://bugzilla.mozilla.org/show_bug.cgi?id=1488950 Good luck finding agreement.
Created attachment 348977 [details] chrome canary (top), safari tech preview (middle), and firefox nightly (bottom) Previous image didn't take into account webkit prefix of sticky property value.
The only major difference between webkit and gecko is at which point the sticky element reaches the opposite edge of its containing block as it scrolls all the way to the end. Safari "grabbing" the sticky element earlier.
<rdar://problem/44237240>
Blink decided to conform to gecko/webkit behavior for negative margin at the sticking scroll edge? So an updated version of the attached screenshot would show consistent behavior. https://bugs.chromium.org/p/chromium/issues/detail?id=814141#c_ts1524700607 But, Safari STILL has compat issues with how the sticky block is "picked up" (grabbed) when reaching the opposite edge of its containing block. Not sure about Edge, but Safari behaves different than blink/gecko in the test case where a 20 pixels or so before reaching the "scrollend" in the left side scroller, the sticky element begins moving with the flow content.
As I spend time thinking about how SCR is created from scroll containers being the offset parent of the sticky element, I think the interop issue shown here is the same as what is reported in https://bugs.webkit.org/show_bug.cgi?id=175029
Checking against recent versions of WebKit, I think this is behaving the same way in all browsers now. Feel free to leave a comment if this is still an issue and I can reopen this and fix it.