Last Comment Bug 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
: padding-bottom/right(block-end/inline-end) is ignored with overflow:auto/scro...
Status: RESOLVED INVALID
: regression
Product: Core
Classification: Components
Component: Layout: Block and Inline (show other bugs)
: 12 Branch
: x86_64 Linux
: -- normal with 1 vote (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
: Jet Villegas (:jet)
Mentors:
: 753681 813543 878058 887422 1198902 1209400 1237643 (view as bug list)
Depends on:
Blocks: 665597
  Show dependency treegraph
 
Reported: 2012-04-24 13:27 PDT by luigipinca
Modified: 2016-11-25 10:17 PST (History)
21 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
test case (803 bytes, text/html)
2012-04-24 15:32 PDT, Kevin Brosnan [:kbrosnan]
no flags Details
Testcase #2 (549 bytes, text/html)
2012-04-24 15:40 PDT, Mats Palmgren (:mats)
no flags Details

Description luigipinca 2012-04-24 13:27:01 PDT
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 [:bz] (still a bit busy) 2012-04-24 13:49:00 PDT
Seems like bug 458296 again...

Mats, dbaron, any idea what's up here?
Comment 2 Kevin Brosnan [:kbrosnan] 2012-04-24 14:08:28 PDT
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 [:bz] (still a bit busy) 2012-04-24 14:13:39 PDT
That would be awesome!
Comment 4 Kevin Brosnan [:kbrosnan] 2012-04-24 15:32:29 PDT
Created attachment 618074 [details]
test case
Comment 5 Mats Palmgren (:mats) 2012-04-24 15:40:40 PDT
Created attachment 618078 [details]
Testcase #2

This is a bit clearer...
Comment 6 Mats Palmgren (:mats) 2012-04-24 15:42:23 PDT
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 7 Boris Zbarsky [:bz] (still a bit busy) 2012-05-10 10:57:25 PDT
*** Bug 753681 has been marked as a duplicate of this bug. ***
Comment 8 Boris Zbarsky [:bz] (still a bit busy) 2012-11-20 12:32:53 PST
*** Bug 813543 has been marked as a duplicate of this bug. ***
Comment 9 Daniel Holbert [:dholbert] 2013-02-19 13:21:30 PST
(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 10 Mats Palmgren (:mats) 2013-05-31 13:41:59 PDT
*** Bug 878058 has been marked as a duplicate of this bug. ***
Comment 11 Mike Pennisi [:jugglinmike] 2013-06-26 12:14:24 PDT
*** Bug 887422 has been marked as a duplicate of this bug. ***
Comment 12 Simon Sapin (:SimonSapin) 2013-07-12 11:45:31 PDT
(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 2014-01-13 12:55:23 PST
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 [:bz] (still a bit busy) 2014-01-13 13:13:39 PST
> 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 2014-01-13 13:32:51 PST
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) 2014-01-14 10:14:10 PST
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 (:mats) 2014-01-14 13:23:14 PST
(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 www-style@w3.org 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 2014-04-12 11:02:09 PDT
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 2014-05-05 18:47:24 PDT
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 [:bz] (still a bit busy) 2014-05-05 19:24:52 PDT
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 2015-07-11 03:09:08 PDT
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 22 Hallvord R. M. Steen [:hallvors] 2015-08-26 15:38:52 PDT
*** Bug 1198902 has been marked as a duplicate of this bug. ***
Comment 23 David Baron :dbaron: ⌚️UTC-10 (vacation, returning December 19) 2015-09-29 00:28:26 PDT
*** Bug 1209400 has been marked as a duplicate of this bug. ***
Comment 24 Boris Zbarsky [:bz] (still a bit busy) 2016-01-07 11:05:55 PST
*** Bug 1237643 has been marked as a duplicate of this bug. ***
Comment 25 djFD 2016-04-25 21:49:50 PDT
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] 2016-04-25 22:56:11 PDT
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 2016-04-25 23:24:24 PDT
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 2016-05-20 15:23:44 PDT
I reported it to the css-wg at https://github.com/w3c/csswg-drafts/issues/129
Comment 29 studio.felk 2016-11-23 01:39:42 PST
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 [:bz] (still a bit busy) 2016-11-23 07:46:36 PST
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.

Note You need to log in before you can comment on or make changes to this bug.