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.

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

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.

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.

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

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

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

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

@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

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.

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.

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

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.

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

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.

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.

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;

@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

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.

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

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.

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

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

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

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