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

jcrben commented 8 years ago

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.

dholbert commented 2 years ago

@bfgeek, just wanted to check whether there are any updates / timeline-ETAs on the proposed use-counter/webcompat-data-gathering phase, for determining whether your proposal is web-compatible? (per https://github.com/w3c/csswg-drafts/issues/129#issuecomment-893052191 )

This is an area of occasional interop pain (just got a bug report in https://bugzilla.mozilla.org/show_bug.cgi?id=1744414 ) so I'm looking forward to having a resolution for something coherent and (hopefully) web-compatible, so we can become interoperable. :)

bfgeek commented 2 years ago

@dholbert - Getting there. We successfully shipped adding inline-end padding to blocks which already scrolled. E.g.

<!DOCTYPE html>
<div style="overflow: scroll; padding: 10px; border: solid; width: 100px; height: 100px;">
  <div style="width: 100px; height: 100px; background: lime;"></div>
</div>

https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=9874

We are still determining if we can add this inline-end padding universally. There is one interesting subcase which is highly prevalent:

<!DOCTYPE html>
<div style="overflow: scroll; padding: 10px; border: solid; width: 100px; height: 100px;">
  <div style="width: 100px; height: 0; background: lime;"></div>
</div>

https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=9875

Specifically if there appears to be one JS library which uses this pattern (an zero height element which would trigger overflow if we added padding universally). I need to study this library some more to determine if making it scrollable will cause any issues for it.

The next step is likely going to be try to ship adding inline-end padding for the non-empty case. E.g.

<!DOCTYPE html>
<div style="overflow: scroll; display: block; padding: 10px; border: solid; width: 100px; height: 100px;">
  <div style="min-width: 90px; height: 100px; background: lime;"></div>
</div>

will be the same as

<!DOCTYPE html>
<div style="overflow: scroll; display: flex; padding: 10px; border: solid; width: 100px; height: 100px;">
  <div style="min-width: 90px; height: 100px; background: lime;"></div>
</div>

This is likely going to be web compatible as the UseCounter is lower than when we made the similar change for flexbox.

TL;DR at the very least we can add inline-end padding to block boxes which already scroll. But I'd like to keep pushing to try and add this universally.

bfgeek commented 2 years ago

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 commented 2 years ago

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 commented 2 years ago

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/w3c/csswg-drafts/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 commented 2 years ago

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 commented 2 years ago

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

bakura10 commented 2 years ago

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 commented 2 years ago

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

w3c / csswg-drafts

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