On longstanding webcompat issue about padding-bottom/padding-right missing in scroll containers

[Ting-Yu Lin 林庭宇]

Over the years, we accumulate a lot of duplicates in Bug 748518
<https://bugzilla.mozilla.org/show_bug.cgi?id=748518> about
`overflow:auto/scroll` container's padding-bottom / padding-right is
missing in Firefox when scrolling to the bottom / right. Blink and WebKit
have this behavior for most container types [1], and web developers are
expecting this rendering.

Relevant spec: https://drafts.csswg.org/css-overflow-3/#scrollable

I want to improve the webcompat situation via the following bugs.

Bug 1527949 <https://bugzilla.mozilla.org/show_bug.cgi?id=1527949>: add
block container's block-end padding for scrolling block containers.
I'm fixing this bug, targeting Firefox 89.

Bug 1700858 <https://bugzilla.mozilla.org/show_bug.cgi?id=1700858>: add
block container's inline-end padding for scrolling block containers.

Blink and WebKit's behavior is not consistent. Currently, both engines only
add inline-end padding to the inline children but not to the block
children. Wait for a resolution on spec issue #129
<https://github.com/w3c/csswg-drafts/issues/129>.

Bug 1697349 <https://bugzilla.mozilla.org/show_bug.cgi?id=1697349>: add
flex container's padding and flex item's margin in both axes for scroll
flex container.
It was fixed, targeting Firefox 89.

Bug 1527539 <https://bugzilla.mozilla.org/show_bug.cgi?id=1527539>: add
grid container's padding and grid item's margin in both axes for scroll
grid container.
No plan yet, but I hope I can get to it in Firefox 89 or 90.

Ting-Yu

[1] This table
<https://github.com/w3c/csswg-drafts/issues/129#issuecomment-697691447> in
the spec issue summarizes the webcompat situation across different element
types and engines.

[Anne van Kesteren]

Thanks for untangling this mess! Always great to see.

On Thu, Mar 25, 2021 at 8:20 PM Ting-Yu Lin 林庭宇 <tl...@mozilla.com> wrote:
> [1] This table
> <https://github.com/w3c/csswg-drafts/issues/129#issuecomment-697691447> in
> the spec issue summarizes the webcompat situation across different element
> types and engines.

Could you please summarize what the table ends up looking like after
these changes? I also saw bz note that we only want to change our
behavior once in this area, but I guess since this has taken so long
to resolve we changed our mind on that and will now proceed in two
stages?

[Ting-Yu Lin 林庭宇]

> Could you please summarize what the table ends up looking like after
these changes?

Good idea! I update the table in
https://github.com/w3c/csswg-drafts/issues/129#issuecomment-808526584

> I also saw bz note that we only want to change our behavior once in this
area, but I guess since this has taken so long to resolve we changed our
mind on that and will now proceed in two stages?

Right, it's best we don't change our behavior back and forth. With Bug
1527949 <https://bugzilla.mozilla.org/show_bug.cgi?id=1527949> fixed
(already in Nightly), I believe it resolved most of the webcompat issues on
this subject, and we can deal with other bugs that have less webcompat
demanding later.

Ting-Yu