1700858 - Implement whatever more-interoperable behavior the CSSWG comes up with, for making inline-end padding scrollable on scrollable elements

Status: REOPENED

(Core :: Layout: Scrolling and Overflow, enhancement)

Description

[Ting-Yu Lin [:TYLin] (PDT, UTC-7)]

+++ This bug was initially created as a clone of Bug #1527949 +++

Bug 1527949 deals with adding block-end padding to the scroll container's scrollable overflow areas. This behavior is expected by authors.

This bug tracks adding inline-end padding to the scroll container's. According to this table, blink and webkit only add inline-end padding to the inline lines (inline-level), but not to the block lines (block-level). Per discuss with emilio, we might want to wait until the webcompat situation is clearer and a resolution is made by CSSWG before implementing this.

Bug 1294631 and Bug 1558053 are two reports that contain testcase indicating inline-end padding is missing.

Comment 1

[Ting-Yu Lin [:TYLin] (PDT, UTC-7)]

Attachment: Bug 1700858 - Include the block container's inline-end padding for inline lines when computing its overflow area.

For webcompat, we only add block container's inline padding to its inline
lines, but not its block lines.

Since we've already included the necessary padding in either axis in
scrolled inner frame's overflow area, we have to delete the code in
ReflowScrolledFrame() which inflates the inner frame's overflow area
again with its padding [1]. It's undesired now because it recomputes
mHelper.mScrolledFrame's overflow areas by using
nsLayoutUtils::UnionChildOverflow(), which ignores special overflow area
the block frame may compute. We should just use the correct overflow
area returned via aMetrics->mOverflowAreas.

[1] I think this is needed for <textarea> and <input> that have
overflow-clip-box:content-box in their inline-axis in forms.css, in
order to add inline padding to avoid clip the content.

Comment 2

[Ole Strøm]

Thank you for you effort on this, Ting-Yu Lin ❤️

Comment 3

[Ting-Yu Lin [:TYLin] (PDT, UTC-7)]

CSS Working Group made the following resolution. https://github.com/w3c/csswg-drafts/issues/129#issuecomment-889481917

RESOLVED: Go with Firefox's behavior - no elements cause the scroll container's inline-end padding to be used

That is, we don't need to add block container's inline-end padding to the overflow area. Hence, we don't need to change our current behavior. Let's close this.

Comment 4

[Ting-Yu Lin [:TYLin] (PDT, UTC-7)]

The latest resolution https://github.com/w3c/csswg-drafts/issues/129#issuecomment-893052191

RESOLVED: Undo previous resolution. Explicitly mark as undefined in the draft for now

From Ian in the meeting:

<dael> iank_: What I'm going to do next is change behavior to include inline end padding if it was scrollable and I'll add another use counter for the case I was more worried about. I'll report back in a couple months

So blink is going to investigating whether adding inline-end padding universally to the block container's overflow area will break websites. Let's reopen this bug to keep tracking this undefined behavior in the spec.

Comment 5

[Daniel Holbert [:dholbert]]

(In reply to Ting-Yu Lin [:TYLin] (UTC-7) from comment #4)

So blink is going to investigating whether adding inline-end padding universally to the block container's overflow area will break websites.

As I understand it, IanK's proposal is a little more subtle -- he's proposing that we add inline-end padding to the scrollable area only when a scrollbar would already be showing, even without the padding. This caveat is a bit odd but I suspect it's necessary for webcompat purposes -- i.e. I can imagine that adding the padding universally might make scrollbars start showing up all over the place.

So in particular: under his proposal, the padding would not trigger a scrollbar here:

data:text/html,
<div style="width:200px;overflow:auto; border: 2px solid black; padding: 50px;">
<div style="display:block;width:249px; background:blue">Hi

...but in this case (same as above but with s/249/251/) which does show a scrollbar, Ian's proposal would give the scrollbar a lot more room to move (such that you could scroll past the blue and see another 50px of blank space between the blue and the border):

data:text/html,
<div style="width:200px;overflow:auto; border: 2px solid black; padding: 50px;">
<div style="display:block;width:251px; background:blue">Hi

Comment 6

[Ting-Yu Lin [:TYLin] (PDT, UTC-7)]

I can imagine that adding the padding universally might make scrollbars start showing up all over the place.

Yes, I can imagine this is bad, and I think IanK is going to add use counter to monitor this scenario similar to your first example (child <div> with width:249px), i.e will adding inline-end padding in block container make scrollbars start showing up. If the damage is low, then we could add inline-end padding universally.

Otherwise, we can probably only do what he's currently proposing for web: add inline-end padding to the scrollable area only when a scrollbar would already be showing, even without the padding.

I can understand why IanK wants to revert the resolution in comment 3 because blink and wekbit already add inline-end padding to inline children for ages. Implementing the resolution in comment 3 might cause another compat issue. In this case (same as your first case but with s/display:block/display:inline-block), there's already a scrollbar in blink and webkit.

data:text/html,
<div style="width:200px;overflow:auto; border: 2px solid black; padding: 50px;"> 
<div style="display:inline-block;width:249px; background:blue">Hi