748518 - padding-bottom/right(block-end/inline-end) is ignored with overflow:auto/scroll because it extends in from the border-box rather than out from the scrollable area

Status: RESOLVED FIXED

(Core :: Layout: Block and Inline, defect, P2)

Description

[luigipinca]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:11.0) Gecko/20100101 Firefox/11.0
Build ID: 20120317101735

Steps to reproduce:

http://jsfiddle.net/KPJDK/
Scroll to the end of the list (<ul>) scroll bar.


Actual results:

The padding-bottom is lost.


Expected results:

The padding-bottom should be kept (was like this in the previous versions).

Comment 1

[Boris Zbarsky [:bzbarsky]]

Seems like bug 458296 again...

Mats, dbaron, any idea what's up here?

Comment 2

[Kevin Brosnan [Ex-Mozilla]]

Talked with Luigi in irc and this is a regression during the Firefox 12 development cycle. Firefox 11 does not have this problem. If I don't get swamped with mobile work I'll bisect this to the nearest daily.

Comment 3

[Boris Zbarsky [:bzbarsky]]

That would be awesome!

Comment 4

[Kevin Brosnan [Ex-Mozilla]]

Attachment: test case

Comment 5

[Mats Palmgren (inactive)]

Attachment: Testcase #2

This is a bit clearer...

Comment 6

[Mats Palmgren (inactive)]

The layout is correct per the CSS 2.1 spec: padding is applied at the
content edge, not after any overflow.  This change is intentional (bug
665597).  We're now compatible with IE10 which has the same layout.
Opera and webkit has the same layout as Fx11 and older.

Comment 9

[Daniel Holbert [:dholbert]]

(In reply to Mats Palmgren [:mats] from comment #6)
> We're now compatible with IE10 which has the same layout.
> Opera and webkit has the same layout as Fx11 and older.

Note that Opera (w/ Presto) now matches us on this, so it looks like Webkit is the only engine that's applying the bottom-padding now.

Comment 12

[Simon Sapin (:SimonSapin)]

(In reply to Mats Palmgren (on vacation) from comment #6)
> The layout is correct per the CSS 2.1 spec: padding is applied at the
> content edge, not after any overflow.

I’m not finding this in the spec. Mats (or anyone), could you give point to the part of the spec that calls for this behavior, and makes 'padding-bottom' special compared to padding on the other three sides?

(This is affecting my patch for 483446 when 'background-clip' is 'content-box'.)

Comment 13

[T.Rosenau]

Here it is: http://www.w3.org/TR/CSS2/box.html#box-padding-area

The padding surrounds the *content area*, not the content as such.

Note that overflowing occurs when the actual content height exceeds the content edges: http://www.w3.org/TR/CSS2/visufx.html#overflow-clipping

Thus, the content area itself does not change in height, so there is no reason to add any spacing to the bottom.

Same holds for padding-right, BTW.

Comment 14

[Boris Zbarsky [:bzbarsky]]

> and makes 'padding-bottom' special compared to padding on the other three sides?

It's not.  padding-right has the same behavior of you overflow in that direction.  For that matter so do the left and top padding if you overflow in _those_ directions!

Comment 15

[T.Rosenau]

The only difference being that scrollbars generally don't permit scrolling beyond the left or upper padding edge.
(Though there's nothing in the specs that would prohibit this...)

Comment 16

[Simon Sapin (:SimonSapin)]

Let’s call "scrolling box" the thing whose size is set by the 'width' and 'height' CSS properties, and "scrolled area" the thing that moves when using the scrollbar and gets bigger when more content is added.

As far as I know, the size of the scrolled area is not defined in CSS specifications. I believe that the root of this issue is different understandings of what this size should be.

Padding at the "start" (in either direction) moves content and therefore affects the size of the scrolled area. I argue that it would make more sense for padding at the "end", although it does not move content, to also affect the size of the scrolled area.

Comment 17

[Mats Palmgren (inactive)]

(In reply to Simon Sapin (:SimonSapin) from comment #16)
> As far as I know, the size of the scrolled area is not defined in CSS
> specifications.

The size of the scrolled area follows from 11.1, which says:
"Whenever overflow occurs, the 'overflow' property specifies whether
a box is clipped to its padding edge, and if so, whether a scrolling
mechanism is provided to access any clipped out content."

From that I read:
1. overflow that only overlaps the padding box but not the border box
isn't clipped and thus should not trigger a scrolling mechanism
2. the scrolled area should be the size needed to "access any clipped
out content" which is the overflow that goes beyond the padding edge

> Padding at the "start" (in either direction) moves content and therefore
> affects the size of the scrolled area. I argue that it would make more sense
> for padding at the "end", although it does not move content, to also affect
> the size of the scrolled area.

I think we should keep the "would make more sense" and "what authors
want" out of this bug.  It's a separate issue from what the spec
actually says, which is the layout implemented in IE/Gecko.

I think [e-mail] is a better forum for discussing new layout
alternatives.  I don't think the recent proposal from Ojan would be
web compatible though, since he/she wants to break 1. for overflow:auto.
That has to be opt-in in the form of a separate property IMO.

Comment 18

[Nathan Hammond]

Just ran into this, just created a simplistic test case:
http://jsbin.com/lireg/6/edit?html,css,js,console,output

No matter what the spec says (call it a spec bug if you want) this violates the principle of least surprise for me as a web author. There is a reason that this keeps coming up as a duplicate bug report.

Further, there is a different calculus for this issue as the alternative behavior is in both WebKit and Blink (Opera, Safari, Chrome). Or in other words, some stupidly high percentage of mobile devices.

Firefox and IE are now the odd ones out (summing to less than 50% of my users), and we have proof in other shipped implementations that this doesn't break the web.

This needs to be addressed, Gecko needs to stop hiding behind the spec.

Comment 19

[Roan Kattouw]

Another test case that makes it very obvious what's happening and why it's nasty: http://jsfiddle.net/8m3FP/5/

Padding is usually applied around scrollable containers to avoid the content in the container coming right up to the edge. If the bottom element is a paragraph, this isn't as much of a problem because paragraphs get some margin from the default UA stylesheet, but if the last element is a text box, it looks ugly because it comes right up to the edge. Padding prevents this from happening but only if the container (or the user's screen) happens to be large enough; if it's too small and starts scrolling, there is no way (except for crazy hacks) to create space below the last element in the Gecko interpretation of CSS 2.1, while padding just works in the Webkit/Blink interpretation.

Note that using margin on the scrollable container doesn't really work either: it provides for whitespace between the last element and the container's edge, but it also pushes the scrollbar away from the container's edge.

I think the reading of the spec as outlined in comment 17 is flimsy at best, but I haven't had time to look into the details of how the spec defines various things (like, is the bottom padding of the last element part of the "clipped out content"?). When I have time to look into this more, I'll see if there is language elsewhere in the spec that unambiguously resolves this one way or the other, and if not propose to the W3 folks that the spec be clarified.

Comment 20

[Boris Zbarsky [:bzbarsky]]

Roan, you may want to start by reading the www-style archives, where the spec end of this has been discussed at length.

Comment 21

[Ronald]

I'm sorry guys, but the fact that you *intentionally* break the padding functionality just because you disagree on some spec is ridiculous. It proves to me that firefox is a lost cause with absolutely no sense of direction just like IE. Put your egos aside and fix this bug.

Comment 25

[djFD]

hi guys,

looks as a bug. please look at http://www.w3.org/TR/CSS2/box.html#box-padding-area once more

Margin part is explicitly marked as `transparent`, unlike other box parts (border, padding). So presumably padding part can be non-transparent too, just like as border (e.g. tomorrow there will be new css property for describing padding area color, background, transparency)...

not having it at right/bottom in scrolling boxes will broke visual appearance...

Out of curiosity, how other browsers do handle that?

thanks

Comment 26

[Daniel Holbert [:dholbert]]

This bug was closed as INVALID 4 years ago.  INVALID bugs are not good places to try to start up new discussions, generally.  If you really want to see something change, or you're concerned that you've found a bug in the spec, you'd be better off emailing the CSSWG (who writes the spec that we're matching here).

Briefly answering the first part of your question, though:
> Margin part is explicitly marked as `transparent`, unlike other box parts
> (border, padding). So presumably padding part can be non-transparent too,
> just like as border

Yes, padding can absolutely be non-transparent -- it gets painted with whatever color/image is specified in the "background" property (so "background: lime" gives you lime padding area).  That doesn't mean the padding area needs to be scrollable, though.

Anyway, I don't believe any browser's scroll calculations are influenced by whether the padding is transparent or not. Feel free to test various browsers to compare behavior -- but as noted above, this bug isn't a good place for further discussion on this stuff at this point.

Comment 27

[djFD]

Hi Daniel,

thank you for a quick response, sorry did not notice that this bug is too old and invalid :D.

'That doesn't mean the padding area needs to be scrollable, though.' maybe yes and maybe no. usually it is better to see that scrollable contents get finished and there is whitespace after it. eg. for table data. Well, it is just a matter of user experience, and can be solved by simply adding an extra wrapper div. thanks to angular I resolved it for myself already.

Thanks again,
bye

Comment 28

[ben]

I reported it to the css-wg at https://github.com/w3c/csswg-drafts/issues/129

Comment 29

[studio.felk]

The newest spec states "The scrollable overflow region is the union of the box’s own content and padding areas" (https://www.w3.org/TR/2016/WD-css-overflow-3-20160531/#scrollable), which makes this a valid bug again.

Comment 30

[Boris Zbarsky [:bzbarsky]]

No, it doesn't.  That just says that you have to be able to scroll to at least the bottom of the padding.  The problem people are complaining about in this bug is that when the overflowing kids' bottom is _below_ the bottom of the padding then there is no more space below the bottom of the overflowing kids' to scroll to.  But that's because the bottom of the padding area is well above the bottom of the scrollable overflow region in that case.

Comment 32

[frlinw]

It is nice to be close to the spec but this behaviour is totally unexpected for developers. That's probably why blink is not totally spec compliant but closer to developer's expectations.
Spec should be all or nothing, but particular cases like 'ignore bottom/right padding if' lead to use ugly workarounds like it was a bug.
Show all paddings or add an overflow-clip property to give some control to the developer. But seriously, this behaviour is ridiculous

Comment 33

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

The CSS WG just resolved in https://github.com/w3c/csswg-drafts/issues/129 to change this behavior for the block direction.  (Inline direction still pending.)

Comment 35

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

... although maybe not, since it was more complicated than people thought.

Though there may be a resolution coming.

Comment 39

[Mitar]

There seems to be progress here in the spec: https://github.com/w3c/csswg-drafts/issues/129#issuecomment-417525242

The align-content and justify-content properties will now have this side-effect: any non-normal value will cause the padding to be honored. So there is at least now a workaround for this.

Now, the question is, does Firefox respect this workaround?

Comment 40

[Daniel Holbert [:dholbert]]

(In reply to Mitar from comment #39)
> The align-content and justify-content properties will now have this
> side-effect: any non-normal value will cause the padding to be honored.

Thanks for calling this out. I filed bug 1499443 on implementing the spec section that includes this text.

> Now, the question is, does Firefox respect this workaround?

Not until we've implemented it.

Comment 46

[Robert Utasi [:hunboy]]

Attachment: workaround testcase with pseudo

I found a workaround with pseudo, this can be usable until it will be reopened and fixed

Comment 47

[Thomas Wisniewski [:twisniewski]]

It's also possible to use something like height:calc(100% - 10px) to add bottom-padding, if the containing block is also position:relative or position:absolute.

Comment 48

[Thomas Wisniewski [:twisniewski]]

This is also biting CNN's site, as per https://webcompat.com/issues/25092.

Comment 49

[Daniel Holbert [:dholbert]]

FWIW, I filed bug 1527949 as a placeholder to cover the eventual implementation of the eventual spec-text. (This behavior is still under/un-specified at the moment.)

Comment 55

[Leho Kraav (:macmaN @lkraav)]

Attachment: Screenshot from 2020-03-09 20-48-10.png

I'm the author of the last yet another duplicate bug 1620978

Everything's already been said about padding areas etc, but in Firefox 73 I'm also seeing actual content cut off with zero everything outside content-box.

Screenshot in the attachment clearly shows the container doesn't have any EDIT bottom properties outside content-box, yet the bottom right widget text is cut off. Chrome, again, displays this correctly.

Is this overflow handling situation borked in more than one way? Is there another bug to follow for content cut-off?

EDIT this has an effect of killing a whole bunch of workaround attempts with ::after etc, because now context box itself is displayed at unequal height cross-browser.

EDIT update: I've managed to overcome my sidebar issues by re-using <aside> element's <slot> child as the scroll container, effectively using it as a "free" wrapper (it's there anyway), instead of previously scrolling <aside> itself. This has magically solved all overflow issues.

Comment 58

[Mike Taylor [:miketaylr]]

Sean, I think we should considering re-opening this bug (and matching Blink's behavior) for compat reasons. Thoughts?

Comment 59

[tobias.buschor]

I really hope that this issue will be solved.
It is my biggest WTF in CSS.
As much as I love Firefox, I ignore the behavior of Firefox and do not use any additional elements or CSS hacks to get a padding-bottom.

Comment 60

[epiqu1n]

I also have this issue (https://bugzilla.mozilla.org/show_bug.cgi?id=1630496) and would be appreciative if this report was reopened.

Comment 61

[florentin.rieger]

Please consider fixing it. I stumble across the issue on nearly every project I am working on.

Comment 62

[Leho Kraav (:macmaN @lkraav)]

(In reply to Mike Taylor [:miketaylr] from comment #58)

Sean, I think we should considering re-opening this bug (and matching Blink's behavior) for compat reasons. Thoughts?

Matching Blink behavior for now makes sense. Currently, Firefox users seem to be getting a degraded experience on a surface potentially bigger than it appears. Many developers probably don't even bother testing much on FF due to market share dynamics (extrapolating from people I personally know), and others may not be able to figure out what the problem is and just leave it. It took me nearly a year and random events from first seeing the problem effect and finally ending up here at the root cause.

Comment 63

[Sean Voisen (:svoisen)]

Reopening this for further team discussion.

Comment 64

[Areen Said]

I also have this issue very often. Thanks for reopening this thicket!

Comment 65

[bryan.a.leewood]

Thanks for re-opening this bug. I'm experiencing this as well as per FF 75 in Material-UI Dialog boxes.

Comment 66

[fantasai]

Fwiw, relevant spec is here: https://drafts.csswg.org/css-overflow-3/#scrollable
To the extent that it's Web-compatible, I think we should be including padding/margins in the scrollable overflow area, since that is what authors expect. CSSWG has already resolved to do this for flex/grid (where we're less concerned with Web-compat), see https://github.com/w3c/csswg-drafts/issues/3653 and https://github.com/w3c/csswg-drafts/issues/3665

Since this is a compat bug wrt Chrome, it seems fixable: compat appears to be in the direction we want to go in. So long as that's actually true, we should fix it, and get the specs and Gecko to match Chrome.

(Also worth noting that the css-align-3 spec currently requires including the padding for all non-normal alignments; since we had to mess with this behavior to get alignment in scroll containers to work anyway. See https://www.w3.org/TR/css-align-3/#overflow-scroll-position Since 'normal' behavior is generally equivalent to 'start' for block containers, has the side-effect of giving us an opt-in switch for situations where Web-compat won't allow us to change.)

Comment 67

[Emilio Cobos Álvarez [:emilio]]

Part of the problem with Chrome's behavior is that it's inconsistent. It includes the inline-end but not the block-end, which is a bit odd.

Comment 68

[Emilio Cobos Álvarez [:emilio]]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #67)

Part of the problem with Chrome's behavior is that it's inconsistent. It includes the inline-end but not the block-end, which is a bit odd.

Err, exactly the other way around, sorry :)

Comment 69

[Emilio Cobos Álvarez [:emilio]]

But I agree implementing that resolution for flex / grid would be a good first step towards fixing this more generally.

Comment 70

[mo]

+1 thanks for re-opening. I hope this gets fixed soon <3

Comment 71

[moran]

+1

Comment 72

[Karl Dubost💡 :karlcow]

More discussions around this. The CSS WG is trying to decide if the resolution should be on both axis.
https://github.com/w3c/csswg-drafts/issues/129#issuecomment-697691447

We (Blink) are prepared to try and incrementally move to the "child-margin + padding" case for both axis, however stop when we find real world compat concerns.

Firefox is the outlier now on this. WebKit and Blink have the same behavior.

Sean, Given the accumulation of duplicates and SeeAlso let's move this up for webcompat.

Comment 73

[Sean Voisen (:svoisen)]

Agreed, and we've talked about this bug a few times within the team. Bumping in our backlog priority.

Comment 75

[Ole Strøm]

I'd also like to point out that this issue appeared in https://bugzilla.mozilla.org/show_bug.cgi?id=1099204, specifically my comment https://bugzilla.mozilla.org/show_bug.cgi?id=1099204#c22

After great input from Emilio, we got the textarea working pretty much as expected, except the padding on the bottom: https://bug1099204.bmoattachments.org/attachment.cgi?id=9200379

(Note: I increased Github's textarea padding to 20px to showcase it better)

Comment 77

[Frank Griffith Jr]

Jonathan Kew: I'm showing this Bug tied to Epic https://mozilla-hub.atlassian.net/browse/FFXP-360. Are we stalled on this? Just seeing it bumped from P3->P2->P1 just raises eyebrows. Thanks.

Comment 78

[Jonathan Kew [:jfkthame]]

It looks like bug 1527949 (landed in FF 89) addressed this for the block-axis case, which was probably the main source of compat pain (at the time Daniel filed it, apparently Blink also implemented this only for the block axis). The original testcases attached here render OK now, afaics.

So what remains is the inline-axis case (bug 1700858), which I think is less critical (but we should still fix, of course). Ting-Yu has work in progress there, but my understanding is that we're waiting for CSS WG resolution of questions raised in https://github.com/w3c/csswg-drafts/issues/129.

Given that bug 1527949 is fixed, though, I'd say the webcompat priority here could be dialled back.

Comment 79

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

Agree with Jonathan's comment 78. All the major bugs blocking this has been fixed, let's close this, and keep tracking the remaining inline-end padding issue in bug 1700858.