Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
[css-overflow-3] Clarify padding-bottom in overflow content #129
I discovered this today when my overflow content appeared cut-off in Firefox and IE. It appears this was reported to Mozilla and closed as invalid in 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 and someone there suggested bringing it up with the CSS team. I did a search for padding-bottom overflow on the www-style list and didn't see anything.
Previous practical discussions on Stack Overflow include Bottom padding not working on overflow element in non-chrome browsers and padding-bottom is ignored in Firefox and IE on overflowing elements with no content.
Perhaps this is already clear and Chrome has it wrong? I'll admit I'm not enough of an expert on the spec to be sure, just hoping for consistency.
It was never clear in 2.1. Overflow 3 is clear about it - padding should be included - but it's not 100% clear that's web-compatible. In particular, Chrome only includes padding in the block axis, and as you found, Firefox/IE don't include it in either axis. We need to dig thru this as a group and figure out what we should be doing.
In WebKit, we actually have different policies for block children and inline children. If the scroll container has inline children, we will include padding-right (or the equivalent for different writing modes) when computing layout overflow. However, if the scroll container has block children, we just consider the border boxes of the children. This is why there was some disagreement in the call today about what the policy is for the inline-direction.
@litherum Very interesting. Do you know if the decision to behave differently in the inline direction was informed by compat issues? I would not be surprised that adding the padding in the inline direction if the scroll container has block children was causing scroll bars to appear in places where they're not wanted, and had to be avoided because of that.
@litherum I thought it might be something like that; I'm glad to hear it's that simple, and I'll edit the issue accordingly. I echo @frivoal's question about whether the "don't include if if there's only block children" was done for compat (y'all were seeing pages suddenly sprout lots more scrollbars than intended), or if it was just happenstance (y'all added a hack to make inline content look better, and just didn't apply it generally).
@litherum Ping on:
Gecko is close to the spec (and I like it, most of the time) but the Blink implementation makes more sense in this case.
@frlinw I think historically the issue is that browsers didn't want to trigger scrollbars for
Unfortunately, browsers only measure overflow in one way: either include a padding/margin or don't. And changing behavior to include padding/margin when it wasn't before can cause pages which previously didn't have scrollbars to suddenly have scrollbars, and this can make a problem for the page. So we're in an uncomfortable position of what to do here.
I think it would be best artistically if we can count padding/margin as much as possible, but compatibility with existing Web content limits what we can do about it...
Yes, I understand the issue here but actually, it is expected. Padding can cause overflow.
Moreover, Blink has the highest market share, it does not implement the behavior introduced in CSS 2.1 and there is no screams about it (actually maybe there are screams, I really don't know, but blink team does not need 6 years to implement something the dev community wants).
The issue here is the developer is not in control. The spec introduced a behavior which can be unexpected but didn't give to the developer the opportunity to control it (with something like
CSS 2.1 broke existing web content because of this change too. Web is a living thing.
The Working Group just discussed
The full IRC log of that discussion<dael_> Topic: padding-bottom in overflow content
<dael_> github: https://github.com/w3c/csswg-drafts/issues/129
<dael_> fantasai: Issue was filed by frustrated devs where if they have an element with overflow scroll and it has padding and if the content overflows the padding is useless.
<dael_> TabAtkins: I'm one of these web authors.
<dael_> fantasai: Chrome includes that padding at the bottom. Request is everyone matches Chrome.
<dael_> emilio: One the spec issue there's a refrence to an old Mozilla bug.
<dael_> fantasai: I'm not sure spec is clear on what happens.
<dael_> TabAtkins: Prob not wrong that Moz thinks it's spec complient, I just think it's wrong. Everyone does it a little different.
<dael_> TabAtkins: There's a difference between block overflow and inline overflow.
<dael_> fantasai: I don't htink we can solve this all. And I think it'll be undefined for a while. but biggest pain point is the padding-bottom on the overflow container. Idea is to fix that one in a way to make web authors happy.
<dael_> fantasai: Since Chrome has shipped for a while we can be sure it's fairly compat. There's a test case ^ You can see Chrome has padding at the bottom and FF has none.
<dael_> TabAtkins: Use case: I am a blog post editor and I want the text editor behavior where I can scroll the bottom text to a reasonable region to read it.
<dael_> fremy: Reasonable.
<dael_> dbaron: Would be nice to spec something simple. Given there's incompat there's a simple thing that can be close to what current browsers do.
<dael_> fantasai: My current proposal is to leave padding and margin in general and say padding you have to leave space at the bottom.
<dael_> astearns: You're asking for a targeted fix and dbaron wants a general fix.
<dael_> TabAtkins: Would it be bad to resolve this and then try and resolve inline. It's a more complicated space.
<dael_> dbaron: I'd like to resolve we intend to change inline even thought we don't know how to do it.
<dael_> fantasai: It's possible for web compat we can't fix inline and even if tha'ts the case I think it's reasonable to try and fix this. General usability of CSS we should make this work.
<dael_> TabAtkins: When we nail down inline padding at least 2 browsers will have to change.
<dael_> dbaron: People care more about block because they scroll in that directio more.
<dael_> fantasai: And throwing in block axis overflow with scrolling is less unexpected.
<dael_> fantasai: I would like to include as much of margins and padding in the overflow areas butwe have the case of will this trigger scrollbars where it's not expected.
<dael_> fantasai: Since we don't have a web compat constraint with bottom padding I think we should do that.
<dael_> astearns: Prop: Require that you leave space in scroll containers for block-end padding?
<dael_> TabAtkins: Cool.
<dael_> astearns: Add a note saying like to enforce for inline padding, but not sure if we can for web compat.
<dael_> fantasai: We'll file another issue on that.
<dael_> astearns: Okay dbaron ?
<fantasai> testcase for inline-end padding http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=5908
<dael_> astearns: I guess so.
<dael_> dbaron: I think we used to do that and changed to compat with spec. Spec is quite clear that's what you do. Nothing to imply you should move padding.
<fantasai> Looks like Chrome includes padding-inline-end http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=5908
<dael_> myles: I talke dto hyatt and he said he did it because it was symmetrical and looked better.
<dael_> myles: In webkit.
<dael_> myles: I think webkit.
<dael_> astearns: Objections?
<dael_> fantasai: I'd be happy to resolve for inline too.
<dael_> myles: I think we should do both.
<dael_> fantasai: Okay.
<dael_> astearns: Resolve and then talk inline or block?
<fantasai> s/too; just don't want to hold up block-end/
<dael_> myles: no preference
<dael_> astearns: Resolve for just block. Obj?
<dael_> RESOLVED: Require that you leave space in scroll containers for block-end padding in the scrollable area
<dael_> astearns: Do we also require space fo inline padding because consistency is nice.
<dael_> fantasai: There's a test case above in IRC: http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=5908
<dael_> emilio: Is that compat?
<dael_> TabAtkins: Chrome puts padding on all the sides.
<dael_> astearns: Same argument applies. If Chrome has been doing it for so long. Can you see if there are bugs on extra unexpected scrollbars?
<dael_> myles: When would the scrollbars not appear?
<dael_> rune_: Bug report ^
<dael_> TabAtkins: It's a spec bug.
<dael_> rune_: Yeah, it's not compat.
<dael_> myles: Same argument applies
<dael_> astearns: And fremy agreed.
<dael_> astearns: dbaron wanted consistancy.
<dael_> astearns: Objections to Use same space saving for inline-padding?
<dael_> koji: It's a block inline
<dael_> fantasai: padding on scroll container itself. Everything else is undefined.
<dael_> TabAtkins: From test case in bug, we do apply padding if it's inline content that overflows, but not if it's a block causing the overflow. If the block is inline overflowning no padding, but the text you do.
<dael_> myles: Same as my comment.
<dael_> TabAtkins: I didn't realize we did that as well.
<dael_> astearns: Maintain that?
<dael_> TabAtkins: No.
<dael_> astearns: Worried if you don't?
<dael_> fantasai: I have concerns but I won't block.
<fantasai> s/concerns/concerns about web compat/
<dael_> dbaron: Apply to content nested arbitrarily deep? You're propagating 2 versions to know if it's block or inline overflow?
<dael_> myles: I think the answer is no, just children.
<dael_> TabAtkins: No, it looks as far down as you want to know.
<dael_> astearns: Prop: Preserve space allocated by inline-end padding on the scroll container
<dael_> fantasai: Dunno abspos.
<dael_> myles: No browser does that. Scary.
<dael_> TabAtkins: It's close to blink and chrome
<dael_> dbaron: Inlines you add the padding and blocks you don't?
<dael_> myles: yes
<dael_> TabAtkins: Presumably difficulty of reading text flush with edge was the reason.
<dael_> dbaron: But then why not blocks?
<dael_> TabAtkins: Blocks aren't text.
<dael_> TabAtkins: Clarifiation. Inline content has to be a direct shild.
<dael_> myles: Toggle looks at just the chilred.
<dael_> dbaron: Inline inside a block child you don't apply
<dael_> dbaron: I think applying all the time is good, but I'd rather leave as is then keeping the inlive vs block.
<dael_> astearns: You don't want the chrome/webkit current.
<dael_> dbaron: Right.
<dael_> fantasai: Clarification to previous resolution doesn't apply to abspos. Because that's what impl and it makes more sense. abspos is positioned with respect to padding edge.
<dael_> myles: So it's abspos and you say padding:0 it's now underdefined.
<dael_> fantasai: Previous resolution the padding is added to inflow contents.
<dael_> dbaron: Can you make inside of a scrollable area be abspos or only outside?
<dael_> fantasai: If I do abs something and the scroll container is relpos I can scroll.
<dael_> dbaron: Per spec it should be relative to height without scroll but I'm not sure that's what people implement.
<dael_> dbaron: Adjusted by size of scrollbars if you have to adjust for that.
<dael_> fantasai: Bottom edge of the abspos position container does not include the overflowing content. If the thing does overflow then things are weird.
<fantasai> s/are weird/are drawn below that boundary/
<dael_> TabAtkins: In chrome assuming scroll container is abspos and is right0 bottom0 the abspos is int he bottom right.
<dael_> dbaron: Befor eyou scroll
<dael_> dbaron: If it's causing the overflow do you scroll?
<dael_> fantasai: YOu only add the padding to the inflow content.
<rego> check chromium behavior in: https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=5909
<dael_> dbaron: But if a child of the scroll container is relpos but it has children that are bspos do you scroll?
<dael_> saDo abspos children of relpos contribute to the overflow characteristics of it's parent?
<dael_> dbaron: That's how we impl.
<dael_> TabAtkins: e do not add padding if the abspos is the overflowing.
<dael_> dbaron: Now for abspos you need to track this deep.
<dael_> fantasai: When you calc height of box and you scroll to the last thing that's inflow and you add padding bleow that thing, that's your direct child. There may be a deep nested thing.
<dael_> dbaron: Gecko used to do that but that's different then what I think we're saying. The other difference is if you have a scroll container and has an explicit height container and that overflows, do you add padding there.
<dael_> fantasai: Don't think so.
<dael_> fremy: Made a test case and it's worse then that.
<dael_> fantasai: As an author I don't expect an abspos to respect the padding but I do expect things inflow remain inside the mat that's around it.
<dael_> dbaron: You're changing the model. I thought model was you have overflow, add padding around that, and then you overflow.
<dael_> fantasai: Then we added abspos.
<dael_> dbaron: But I think my model is simple. You figure out what hte scrollable overflow area of all descendents is and then you add the padding and that's the area you add the scroll to.
<dael_> dbaron: abspos children are relative to the padding as if inside the viewport and then those are placed in the scrollable area which is prob on top of where it was befor ein the viewport.
<dael_> dbaron: This is what gecko impl and dev don't like.
<dael_> myles: In this model somet higns are inside the viewport.
<rego> this is the output of my example before: https://i.imgur.com/PQZ775X.png (edge behaves like firefox and webkit like chromium)
<dael_> florian: I'm not disputing this may be nice, but doesn't that cause oveflow where you don't expect it? Spec I believe that creating scrollbars too often is why chrome only does it in some cases because it would make scrollbars everywhere which people hate.
<dael_> fantasai: dbaron problem with your model is I have a positionrelative scroll container I put an abspos in the bottom right in your model it triggers padding. If the padding is 2em then we add 2em padding and create all this scrolling.
<dael_> dbaron: I buy that for abspos positioned reltaive tot he scroll container. I don't for things relative inside the scroll container.
<dael_> fantasai: Okay.
<dael_> dbaron: Did we test that?
<dael_> florian: Are you not worried that it would create lots of scrollbars?
<dael_> dbaron: I'ts worrying. An actual proposal with details would be good before resolve.
<dael_> fantasai: test case dbaron proposed ^
<dael_> dbaron: You can't scroll to the thing at all
<dael_> astearns: I'm worried you said this is what we used to do and dev hated.
<dael_> dbaron: I't sbecause it's not what spec said to do and partly becaues dev said it didn't yield expected but it does work as expected in the other case where we were wonrg
<dael_> astearns: We need to come up with a proposal for how to deal with scroll cotnainer padding and then evaluate the full proposal with spec text.
<dael_> astearns: Ammend preious resolution to say we will try to define a way to make scroll padding work in block and inline for all cases in a way that breaks the web.
<dael_> fantasai: If previous is inflow content I think we're scoped okay.
<dael_> myles: Not if we're doing investigation. You're doing 1/4 of the issue.
<dael_> fantasai: But people want this 1/4 to work and that's web compat.
<dael_> fremy: If we don't have a model that's clear we'll impl and then re-impl.
<dael_> myles: Agree it's wasted work.
<dael_> astearns: I suggest that we draft the whole model and the portion that's easy and see if it makes sense to do the easy part first.
<dael_> astearns: I think we need spec text first.
<dael_> florian: Mostly sounds good to me. I thought in previous discussions someone from blink stated that they're only extending padding in some cases is because it's not web compat.
<dael_> TabAtkins: It's not written anywhere to [i don't know noise]
<fremy> ^ testcase with abspos in inline relative
<dael_> fantasai: Some of these cases will be exporatory to figure out what's web compat.
<TabAtkins> s/to [i don't know noise]/and I don't remember it, so iunno./
<dael_> astearns: Prop: Undo the previous resolution and continue to figure out a whole model.
<dael_> RESOLVED: Undo the previous resolution and continue to figure out a whole model.
To solve the Web-Compat problem one could invent a CSS property such:
The actual Chrome behavior would be:
The actual Firefox behavoir would be:
@nuxodin your proposition seems good. I'm in for a css property to give some control to web authors (if there is no consensus about a default behavior) but it is not really related to the webcompat issue