You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[css-overflow-3] Clarify padding in overflow content #129
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.
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).
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).
The spec. issue is not resolved yet. And I assume Mozilla won't reopen that bug report until the spec. issue got resolved.
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.
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.
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).
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 :).
Activity
tabatkins commentedon May 24, 2016
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 commentedon May 26, 2016
We discussed this on the call today. I've added an issue to the spec for it.
[-]Clarify padding-bottom in overflow content[/-][+][css-overflow-3] Clarify padding-bottom in overflow content[/+]litherum commentedon May 26, 2016
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 commentedon May 26, 2016
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 commentedon May 26, 2016
@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 commentedon May 27, 2016
@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 commentedon Jun 22, 2016
@litherum Ping on:
litherum commentedon Jun 22, 2016
This code is older than my time on the WebKit team. I'll ask tomorrow.
sarazhang123 commentedon Jul 11, 2017
@tabatkins Do you know whether firefox will fix this bug https://bugzilla.mozilla.org/show_bug.cgi?id=748518 ?
SebastianZ commentedon Jul 11, 2017
Sebastian
92 remaining items
Bug 1766748 [wpt PR 33833] - [css-overflow] Update/add padding overfl…
bakura10 commentedon Jun 23, 2022
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 commentedon Jun 23, 2022
That looks pretty weird! Seems to be an impl bug - are you getting it in multiple browsers?
bakura10 commentedon Jun 24, 2022
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 commentedon Jun 25, 2022
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
Bug 1766748 [wpt PR 33833] - [css-overflow] Update/add padding overfl…
mask-mode with mask-source value should take value of mask-type on re…
Block container inline-axis overflow includes padding + block-level c…
Fix nav overlap: inner wrapper pattern (proven flexbox scroll fix)