[css-overflow-3] Clarify padding in overflow content

[jcrben]

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.

[tabatkins]

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.

[tabatkins]

We discussed this on the call today. I've added an issue to the spec for it.

[litherum]

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.

[frivoal]

Since additional information is being added here, and we haven't solved the original issue, I'm reopening this despite also having an inline issue in the spec.

[frivoal]

@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.

[tabatkins]

@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).

[tabatkins]

@litherum Ping on:

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]

This code is older than my time on the WebKit team. I'll ask tomorrow.

[sarazhang123]

@tabatkins Do you know whether firefox will fix this bug https://bugzilla.mozilla.org/show_bug.cgi?id=748518 ?

[SebastianZ]

@tabatkins Do you know whether firefox will fix this bug https://bugzilla.mozilla.org/show_bug.cgi?id=748518 ?

1. The spec. issue is not resolved yet. And I assume Mozilla won't reopen that bug report until the spec. issue got resolved.
2. Tab is working for Google, so he's probably the wrong person to ask about Firefox implementation. 😉 But @dholbert, @dbaron, or @bzbarsky might be able to provide feedback here.

Sebastian

[bzbarsky]

My two cents are that we will change behavior here no more than once. That means the WG needs to get its act together and figure out what it's doing before we make any changes.

[nuxodin]

From a web developers view the Chrome behavior makes much more sense.
I do not like it to put semantic-less wrapper-divs to get my padding.

[frivoal]

@litherum On June 22, 2016, you said:

This code is older than my time on the WebKit team. I'll ask tomorrow.

Unless you live in a very unusual time zone, I think we're past tomorrow :) Any update?

[madmoizo]

1. Hello, I'm a developer and I lost a precious time to understand why there is padding-top/left/right but no bottom on firefox/edge.
2. The spec should be clear about this, display all paddings or hide all paddings. The "show padding-bottom/right if...." leads to 1.

Gecko is close to the spec (and I like it, most of the time) but the Blink implementation makes more sense in this case.

[fantasai]

@frlinw I think historically the issue is that browsers didn't want to trigger scrollbars for overflow: auto unless visible content was overflowing the inner border edge, so they didn't count padding. Once scrollbars are in place, however, it makes sense that the padding is included in the scrollable area, otherwise (as we've all noticed) the content gets uncomfortably tight against the bottom right edge when we scroll to that corner.

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...

[madmoizo]

can cause pages which previously didn't have scrollbars to suddenly have scrollbars

Yes, I understand the issue here but actually, it is expected. Padding can cause overflow.
What is unexpected is browsers trying to workaround this expected behavior with an unexpected one.
If you go this way, padding-top can cause overflow when it's unecessary why the spec didn't decide to ignore padding-top too ? Because it breaks something, and it will be very visible. It's the same thing with padding-bottom, if you ignore it, even if it's less visible, it breaks something.

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 overflow-clip?)

existing Web content limits what we can do

CSS 2.1 broke existing web content because of this change too. Web is a living thing.

[css-meeting-bot]

The Working Group just discussed padding-bottom in overflow content, and agreed to the following resolutions:

• RESOLVED: Require that you leave space in scroll containers for block-end padding in the scrollable area
• RESOLVED: Undo the previous resolution and continue to figure out a whole model.

The full IRC log of that discussion

<dael_> Topic: padding-bottom in overflow content
<dael_> github: https://github.com//issues/129
<fantasai> https://github.com//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.
<fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=5907
<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_> s/astears/dbaron
<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?
<rune_> https://bugs.chromium.org/p/chromium/issues/detail?id=724697&q=padding%20scrollable&colspec=ID%20Pri%20M%20Stars%20ReleaseBlock%20Component%20Status%20Owner%20Summary%20OS%20Modified
<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.
<fantasai> o_O
<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?
<fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=5910
<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> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/5911
<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.

[nuxodin]

To solve the Web-Compat problem one could invent a CSS property such:
overflow-padding-behavior-right: strict;
overflow-padding-behavior-bottom: strict;
And a shorthand (right bottom):
overflow-padding-behavior: strict strict;

values are:

• strict => padding at the end
• inline-content or inline-children ? => padding-only for inline-children
• ignore => no padding at the end

The actual Chrome behavior would be:
overflow-padding-behavior: inline-content strict;

The actual Firefox behavoir would be:
overflow-padding-behavior: ignore ignore;

[madmoizo]

@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
Because your spec is supposed to give a default value for this property... So implement this spec will break (or repair, depends of the point of view) some current browsers behavior

[bfgeek]

Just as a small FYI - we've shipped mostly[1] the expected behaviour in Chromium 99.
[1] Except for the zero inflow-bounds case - this is heading out in 101 - we analyzed the library which was causing the majority of this behaviour, and doesn't affect it.
I'll Adgenda+ this in a couple of months once we are in the final state.

[bfgeek]

M101 is rolling at the moment for us. I added the tests for the padding edge behaviour in:

https://wpt.fyi/results/css/css-overflow/scrollable-overflow-padding.html?label=master&label=experimental&aligned&q=css-overflow

All of the tests in that file roughly have this form:

<style>
    scrollable-container {
        display: block;
        width: 100px;
        height: 100px;
        overflow: scroll;
        padding: 10px 5px;
    }

    scrollable-container > div {
        width: 200px; height: 0; /* The child has zero area - so shouldn't directly contribute to scrollable overflow. */
        position: relative; left: -1000px; /* Additionally it is rel-pos'd before the scroll origin. */
        margin-right: 50px; /* end margin to push out the padding edge. */
    }
</style>
<scrollable-container data-expected-scroll-width="260">
    <div></div>
 </scrollable-container>

The test does this for various writing-mode + direction combinations + block/inline level children.

Currently all the browsers agree on the block direction scrollable overflow tests. The tests check that the behaviour is the same in the inline direction.

Additionally one this I also wanted to clarify was that there was some discussion in the issue that these two cases should behave the same:

<div style="width: 100px; height: 100px; overflow: scroll; padding: 10px;">
   veryveryverylongword
</div>
<div style="width: 100px; height: 100px; overflow: scroll; padding: 10px;">
   <div>veryveryverylongword</div>
</div>

These shouldn't behave the same as the alignment rectangle is different for each. E.g. in the 2nd case the div is ~100px, rather than the width of the longest word.

If the <div> had something like:

<div style="width: 100px; height: 100px; overflow: scroll; padding: 10px;">
   <div style="min-width: min-content;">veryveryverylongword</div>
</div>

Then the test cases would behave the same.

Ian

[css-meeting-bot]

The CSS Working Group just discussed [css-overflow-3] Clarify padding in overflow content, and agreed to the following:

• RESOLVED: Always require inline-end padding to be added against the inline-end alignment edge for block/flow layout when it’s a scroll container, thus matching the tests.

The full IRC log of that discussion

<emeyer> Topic: [css-overflow-3] Clarify padding in overflow content
<emeyer> Github: https://github.com//issues/129#issuecomment-1113489051
<emeyer> iank_: Browser have been very inconsistent about when something is a scroll container to apply block- or inline-end padding.
<emeyer> …Chrome very slowly has been moving towards end padding in both inline and block directions in block layout mode.
<iank_> https://wpt.fyi/results/css/css-overflow/scrollable-overflow-padding.html?label=master&label=experimental&aligned&q=css-overflow
<emeyer> …I added an exhaustive set of tests that’s linked in the comment. This test creates a zero-area div and then relposed out of the way, but that zero area div is used to push padding out in either inline or block direction is various writing modes.
<emeyer> …As I was reading back through the issue, there was a conception that there are two cases that should behave the same. If you’ve got inline content that’s very long in a scroll behavior, it should behave the same as if it’s been warpped in a div. But the div isn’t intrinsically sized and won’t push parent padding out.
<emeyer> astearns: The test cases you’re talking about are supported by spec text?
<emeyer> iank_: Yes.
<emeyer> florian: We have a conceptual agreement that there might be web compatibility issues because if scrollbars show up where they didn’t used to be, that could be a problem.
<emeyer> iank_: The spec text has written down our curtent behavior. We’re shipping that behavior now.
<TabAtkins> spec text: "Including this padding is optional for block containers in the inline axis if align-content is normal." with a note saying "hopefully this isn't optional, we're waiting for web compat"
<florian> s/We have a conceptual agreement that/We have a conceptual agreement that adding the padding would be good, but/
<emeyer> s/curtent/current/
<emeyer> fantasai: Do we want to tighten up the spec now, or wait to tighten it up once there’s field data?
<emeyer> astearns: Has there been enough time to evaluate web compatibility?
<emeyer> iank_: We think so. We shipped the “scary” behavior a couple of months ago and got zero pushback.
<emeyer> florian: If other implementors are happy with it, would be happy to tighten the spec now.
<emeyer> dholbert: This sounds fine to me, speaking from Firefox’s perspective. Having that barrier removed makes this pretty straightforward.
<emeyer> smfr: Seems reasonable.
<fantasai> s/that barrier/the Web-compat concern/
<emeyer> RESOLVED: Always require inline-end padding to be added against the inline-end alignment edge for block/flow layout when it’s a scroll container, thus matching the tests.

[bakura10]

Hi everyone,

I'm allowing to comment on this issue to have a clarification about a problem I am facing.

When working with grid whose content is overflowing, applying a padding is now honored in the scrolling container (which is what as a developer I expect), however this only works if columns are sized in PX. As soon as elements as expressed as a percentage of the parent, this fails and we have here as well an unintuitive behavior.

The issue can be reproduced here: https://codepen.io/bakura10/pen/VwQJEJL

Is this expected as per spec, or is this an implementation issue of browsers (speaking about that, Safari gives a completely different result from other browsers).

[tabatkins]

That looks pretty weird! Seems to be an impl bug - are you getting it in multiple browsers?

[bakura10]

Chrome and Firefox has a consistent result in not showing the padding end, while Safari has a completely odd output. I will send a ticket to each vendor then :).

EDIT: I filled the different bugs:

Blink: https://bugs.chromium.org/p/chromium/issues/detail?id=1339124
Gecko: https://bugzilla.mozilla.org/show_bug.cgi?id=1776328
WebKit: https://bugs.webkit.org/show_bug.cgi?id=241950

[bfgeek]

I left a comment at https://bugs.chromium.org/p/chromium/issues/detail?id=1339124#c1 the percentage column case is working as expected - Ian