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).
Seems like bug 458296 again... Mats, dbaron, any idea what's up here?
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.
That would be awesome!
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.
5 years ago
5 years ago
5 years ago
(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.
(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'.)
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.
> 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!
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...)
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.
(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 email@example.com 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.
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.
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.
Roan, you may want to start by reading the www-style archives, where the spec end of this has been discussed at length.
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.
a year ago
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
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.
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
I reported it to the css-wg at https://github.com/w3c/csswg-drafts/issues/129
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.
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.