1488950 - [css-position][css-sticky] Negative margin, sibling element flow placement, containing block overflow compatibility between chrome/safari/firefox

Status: UNCONFIRMED

(Core :: Layout: Positioned, defect)

Description

[jonjohnjohnson]

Attachment: chrome canary (top), safari tech preview (middle), and firefox nightly (bottom)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:63.0) Gecko/20100101 Firefox/63.0
Build ID: 20180830010250

Steps to reproduce:

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?

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.


Actual results:

Major browsers rendering engines behave quite differently when dealing with negative margins on stickily positioned elements.


Expected results:

Uniform position sticky layout between major browsers.

Comment 1

[jonjohnjohnson]

In that this is about compatibility and not spec related, here are links to the same issue filed with other browsers.

- https://bugs.webkit.org/show_bug.cgi?id=189324
- https://bugs.chromium.org/p/chromium/issues/detail?id=881102

Good luck finding agreement.

Comment 2

[Emilio Cobos Álvarez (:emilio)]

What does the spec say? Should an issue be filed against the spec if it's not clear enough?

Comment 3

[jonjohnjohnson]

Attachment: chrome canary (top), safari tech preview (middle), and firefox nightly (bottom)

Comment 4

[jonjohnjohnson]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #2)
> What does the spec say? Should an issue be filed against the spec if it's
> not clear enough?

AFAIK the editor of that spec left. And nobody else in the group has really wanted to weigh in on any issues against the modules language on "sticky" in over a half a year. So I just figured it was more beneficial to bring to the vendors.

Comment 5

[jonjohnjohnson]

The only major difference between webkit and gecko is when 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. *could be related to the age old padding-bottom on a scroller difference in gecko.

Comment 6

[jonjohnjohnson]

Blink has emerged to align with gecko regarding this case.

R(In reply to jonjohnjohnson from comment #5)

The only major difference between webkit and gecko is when 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. *could be
related to the age old padding-bottom on a scroller difference in gecko.

Now it's just webkit that differs in how it treats margins when reaching the opposing boundary of a sticky offset edge? But only when the scroll containers content box plays the part of the SCR containing block? Also, it's definitely not related to the age old padding-bottom scroller compat.

So I s'pose this could be closed as far as gecko is concerned?