Skip to content

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

Closed

Description

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

Activity

  1. tabatkins commented on May 24, 2016

    @tabatkins
    Member

    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.

  2. tabatkins commented on May 26, 2016

    @tabatkins
    Member

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

  3. changed the title [-]Clarify padding-bottom in overflow content[/-] [+][css-overflow-3] Clarify padding-bottom in overflow content[/+] on May 26, 2016
  4. litherum commented on May 26, 2016

    @litherum
    Contributor

    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.

  5. frivoal commented on May 26, 2016

    @frivoal
    Collaborator

    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.

  6. frivoal commented on May 26, 2016

    @frivoal
    Collaborator

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

  7. tabatkins commented on May 27, 2016

    @tabatkins
    Member

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

  8. tabatkins commented on Jun 22, 2016

    @tabatkins
    Member

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

  9. litherum commented on Jun 22, 2016

    @litherum
    Contributor

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

  10. self-assigned this
    on Jun 23, 2016
  11. sarazhang123 commented on Jul 11, 2017

    @sarazhang123

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

  12. SebastianZ commented on Jul 11, 2017

    @SebastianZ
    Contributor

    @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

  13. 92 remaining items

  14. bakura10 commented on Jun 23, 2022

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

  15. tabatkins commented on Jun 23, 2022

    @tabatkins
    Member

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

  16. bakura10 commented on Jun 24, 2022

    @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

  17. bfgeek commented on Jun 25, 2022

    @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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Type

No type

Projects

No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions