search

w3c / csswg-drafts

CSS Working Group Editor Drafts
https://drafts.csswg.org/
Other
4.44k stars 657 forks source link

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

Closed jcrben closed 2 years ago

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.

tabatkins commented 8 years ago

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

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

litherum commented 8 years ago

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

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

@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 commented 8 years ago

@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 commented 8 years ago

@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 commented 8 years ago

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

sarazhang123 commented 7 years ago

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

SebastianZ commented 7 years ago

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

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

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

@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 commented 6 years ago

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

@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 commented 6 years ago

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

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

The full IRC log of that discussion <dael_> Topic: padding-bottom in overflow content
<dael_> github: https://github.com/w3c/csswg-drafts/issues/129
<fantasai> https://github.com/w3c/csswg-drafts/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 commented 6 years ago

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:

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

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

madmoizo commented 6 years ago

@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

fantasai commented 6 years ago

So, due to some issues in the css-align-3 spec (see https://github.com/w3c/csswg-drafts/issues/1425), the align-content and justify-content properties will now have this side-effect: any non-normal value will cause the padding to be honored as requested here. See https://www.w3.org/TR/css-align-3/#overflow-scroll-position I think that resolves the request for a switch. :) We should definitely note this in the Overflow spec as well, however; and this issue remains open to see what we can do to fix this in the default case (which is constrained by Web-compat). I suspect we might be able to make it work in the block axis, but not the inline one.

ashishjat commented 5 years ago

@jcrben - still no solution found for the above problem , but we can try a trick to work. create a empty div at the bottom of your scrolling div and give it some height.this will work very similar to padding bottom.

fantasai commented 5 years ago

OK, so we're also going to try to fix this for Flexbox and Grid generally (even when alignment is normal). See https://github.com/w3c/csswg-drafts/issues/3665 Cross your fingers and hope it's Web-compatible. :)

OliverJAsh commented 5 years ago

For anyone who comes here looking for a workaround/solution, here is a very well documented workaround:

https://www.brunildo.org/test/overscrollback.html

Problem: https://jsbin.com/sawuwor/1/edit?html,css,output Workaround: https://jsbin.com/wikuyif/1/edit?html,css,output

Update: I switched to using a :before pseudo element to avoid issues with line height and pseudo element causing vertical scroll.

Problem: https://jsbin.com/sokufup/3/edit?html,css,output Workaround: https://jsbin.com/fusuwod/2/edit?html,css,output

jipema commented 5 years ago

Another workaround that worked well in my case: adding bottom margin to the last child.

 .overflowing-container > *:last-child{ margin-bottom: 20px; }
silverwind commented 4 years ago

Something should be done here and I think it should be to change the spec to what Blink implements given that most developers would expect Blink/Webkit behaviour as the "correct" one.

https://bugzilla.mozilla.org/show_bug.cgi?id=748518 has accumulated 21 dupe bugs since it was opened 8 years ago, which shows developers have come to expect Blink/Webkit as the correct one and Firefox's as wrong.

It certainly seems intuitive to me that padding/margin should not dissappear just because a area is scrollable. I would visualize the scroll area as a "zoom-in" on a content area. A "zoom" should not be able to change content.

lucijanblagonic commented 4 years ago

My workaround for fixing this bug in my project was (helpful when you want the children centered with margin: auto in a flex container if there is no scroll.):

.overflowing-container > *:last-child:after { display: block; height: 1rem; /* Match bottom padding */ margin-bottom: -1rem; /* Move it outside */ content: ""; }

rahulthewall commented 4 years ago

Ran into this issue today, thankfully I was able to see this discussion. Added a margin-bottom to the div inside the scroll div and fixed the issue.

radogado commented 4 years ago

After a few days of fighting this problem, today I filed a bug https://bugzilla.mozilla.org/show_bug.cgi?id=1621708 and realised it's an 8yo known issue. Used the margin workaround, but now I can't have a flex container. Shame.

lkraav commented 4 years ago

After a few days of fighting this problem, today I filed a bug https://bugzilla.mozilla.org/show_bug.cgi?id=1621708 and realised it's an 8yo known issue. Used the margin workaround, but now I can't have a flex container. Shame.

Yep, I also filed yet another duplicate for it just a few days earlier.

Fortunately managed to find a solid x-browser workaround with making the scroll container a child of the original scroll container. With custom elements, <slot> element was already sitting there, I was able to to utilize it directly to become the new scroll container, instead of creating another <div> layer or similar. Implementation is live at https://cxl.com/blog/ right sidebar.

radogado commented 4 years ago

Workarounds with pseudo elements don't work when I need to set the padding to percentage. Please fix it or add an option to support end padding. Thanks.

bfgeek commented 4 years ago

I'm about to add use-counters into blink to determine how often we have overflow-x + inline-end padding. We should have data in 2-3 months.

Ian

bfgeek commented 3 years ago

Over the past few weeks I've done a fair bit of investigation on the model here. Broadly speaking there is the "ideal" model which is as follows.

When calculating the scrollable-overflow for a scroll-container there are two rectangles we need to keep track of:

[1] Inflow bounds

To determine this correctly the engine needs to keep track of the bounds of all inflow children and their margins (pre relative-positioning and transform adjustments). Padding of the scroll container is then added to this rectangle and added to the scrollable-overflow.

Importantly this doesn't include any float, or out-of-flow positioned children.

This also only happens for a scroll container, this isn't part of the scrollable-overflow for non-scroll containers.

[2] Scrollable-overflow bounds

On top of this the "regular" scrollable overflow calculations apply, e.g. the scrollable-overflow for propagation rectangle which is post-transform, post-relative-positioning.

The result of the scrollable overflow rectangle is the union of [1], [2].

Web-compat concerns

Broadly speaking everything is a relative mess :). However the compat concerns only surround [1].

I created this handle table! Blink (inline) Blink (block) WebKit (inline) WebKit (block) Gecko (inline) Gecko (block) EdgeHTML (inline) EdgeHTML (block)
block-flow (inline-level) padding padding padding padding none none none none
block-flow (block-level) none child-margin + padding none child-margin + padding none child-margin none child-margin
flex none child-margin + padding none child-margin + padding none none none none

(I didn't test grid). The "ideal" thing here (which developers are asking for) would be for each of the layout modes to include "child-margin + padding".

(For the "block-flow (inline-level)" case "child-margin + padding" == "padding").

What to do

We (Blink) are prepared to try and incrementally move to the "child-margin + padding" case for both axis, however stop when we find real world compat concerns. As an example this may end up as the following:

We've got some UseCounters in place, but we are in the process of adding more precise ones.

css-meeting-bot commented 3 years ago

The CSS Working Group just discussed [css-overflow-3] Clarify padding-bottom in overflow content.

The full IRC log of that discussion <dael> Topic: [css-overflow-3] Clarify padding-bottom in overflow content
<dael> github: https://github.com/w3c/csswg-drafts/issues/129
<dael> iank_: Introduction for this
<dael> iank_: Broadly we have been investigating scrollable overflow problems in blink. Lot of inconcsitent tests and inconsistent impl.
<dael> iank_: Including child margin plus scollable padding is what devs want we believe. Inconsistent between layouts and directions
<dael> iank_: 2 calculations. You take post tranform rectangle of child and add to scrollable. This is interop. Second is this issue. Take pre-transform rectangle and add it inflow bounds. Use that to determine where padding edge goes.
<dael> iank_: We think the model works. How webcompat is it is the question.
<dael> iank_: Think we should aim for what webdevs want but stop when web incompat. Prepared to slowly switch on various behaviors to get closer and closer. May hit a case where cna't go further due to compat.
<dael> fantasai: Totally in favor. Great to get to where authors want. Less likely to have problems with newer layouts flexbox and grid. more problems with older like block where trying not to add scrollbars when not necessary. Triggering when scrollbars appear is where will find problems
<dael> iank_: That's where we expect. We're going to do this slowly over 3-4 months and can report back success. For block in inline direction if there weren't going to be scrollbars previously we may not add padding but if there would be we add padding. Might end up with that which is a bit strange.
<dael> Rossen_: Sounds like a good proposal. Should we resolve and think about block more?
<dael> fantasai: I think we resolved on flex and grid
<dael> Rossen_: I think so too. Don't want to hold them waiting on block?
<dael> iank_: If we agree on direction we can report back on each step what was not web-compat. We'll start with flex probably. Report back. DO resolution on broad model now and web compat resolutions later maybe
<fantasai> current spec - https://www.w3.org/TR/css-overflow-3/#scrollable
<dael> Rossen_: Prop is for flexbox and grid? Want to make sure I'm going for right resolution
<dael> fantasai: Spec requires this for flex and grid, optional for block with an issue about web compat
<dael> iank_: Leave as is and in a few months I can come back with web compat data.
<dael> iank_: Tentative agreement we want to go that direction is good
<dael> florian: sgtm. We've been blocked on web compat data so let's get the data.
<dael> Rossen_: Then this is everything for today
bfgeek commented 3 years ago

@fantasai The primary difference from the spec and above, is that the padding-edges contributing to scrollable-overflow are determined "pre-transform, pre-relative-position". E.g. this means that you can animate an element "in" from the top for example, without affecting the scrollable-overflow. This is obviously still union'ed if a child is transformed "outside" this area.

This is what Blink/WebKit do today for block-end edges (and what grid somewhat requires, making the grid part of the scrollable-area).

bfgeek commented 3 years ago

Additionally OOF-positioned children aren't considered for the padding calculation.

bfgeek commented 3 years ago

@fantasai & I chatted quicky and are on the same page regarding my previous two comments.

davidhmays commented 3 years ago

Another workaround that worked well in my case: adding bottom margin to the last child.

 .overflowing-container > *:last-child{ margin-bottom: 20px; }

This would have been a great workaround for me as well, until I had dynamically created cards in a grid. This left the last child having a nice look, but if there were several children next to each other, only having the last one have padding threw it all off.

aethanyc commented 3 years ago
I'm fixing this webcompat issue for gecko. I update @bfgeek's compat table in the previous comment based my test. Please let me know if there's any error. Testcase Blink (inline-end) Blink (block-end) WebKit (inline-end) WebKit (block-end) Gecko (inline-end) Gecko (block-end)
block-flow (inline-level) padding padding padding padding none [3] padding
block-flow (block-level) none child-margin + padding none child-margin + padding none [3] child-margin + padding
flex child-margin + padding child-margin + padding none child-margin + padding child-margin + padding child-margin + padding
grid none [1] none [1] none child-margin + padding none [2] none [2]

(For the "block-flow (inline-level)" case "child-margin + padding" == "padding").

[1] Blink is planning to change grid to "child-margin + padding" in both axes in GridNG (from my communication with @bfgeek) [2] Gecko is planning to change grid to "child-margin + padding" in both axes, too. Tracking in Bug 1527539. [3] Both Blink and WebKit are not consistent on whether the inline-end padding is added in block-flow (yes for inline-level, no for block-level), so Gecko is waiting until there's resolution for this issue. Tracking in Bug 1700858.

fantasai commented 3 years ago

The primary difference from the spec and above, is that the padding-edges contributing to scrollable-overflow are determined "pre-transform, pre-relative-position".

@bfgeek If the spec isn't clear about that, then that's a problem with the spec that should be fixed. It's certainly intending to specify that. Padding gets applied essentially at the edge of what would have been the content edge of the box, if it were auto-sized to its contents. Are you saying the spec is unclear, or that implementations attach padding after transforms/relpos rather than before?

Additionally OOF-positioned children aren't considered for the padding calculation.

"Out of flow" includes floats. I think floats are intended to be included here, no?

franktopel commented 3 years ago

I mean, it's good to see this being discussed frequently (with an estimate 2-year-interval at first glance), but in the meantime another question about this has been raised and suggested quirky workarounds on StackOverflow.

Considering this issue has been reported on bugzilla more than 9 (!!!!) years ago, to an outside person this does make the impression that whoever decides on such issues doesn't do their job in anywhere near acceptable timely manner.

radogado commented 3 years ago

Considering this issue has been reported on bugzilla more than 9 (!!!!) years ago, to an outside person this does make the impression that whoever decides on such issues doesn't do their job in anywhere near acceptable timely manner.

Must be said again. Frontenders are disheartened by browser bugs, quirks and undefined behaviour. From all-time favourites like scroll padding and missing subpixel scroll offset to relatively new unstable stuff like scroll snapping, web dev is a minefield.

frivoal commented 3 years ago

As far as I can tell, other than possible editorial tweaks to make the prose cleaner, the only reminaing open quesiton is that of “[3]” in https://github.com/w3c/csswg-drafts/issues/129: do we add that padding in the inline-end of block-flow or not (limited to the case of justify-content: normal).

I think that:

That would mean that even though the current webkit/blink behavior is odd, it represents the most padding we'll ever get, so we might want to spec that.

However, the blink/webkit "odd" behavior is really odd: they add the scroll container’s padding to the inline-end of inline children of the container, but not to other descendents of the container, be they block containers or inline descendents other than children.

This is not just weird, it also violates the principle that inserting an unstyled div should make no difference to the layout.

We probably should for consistency, and never add that padding to the inline-end.

css-meeting-bot commented 3 years ago

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

The full IRC log of that discussion <TabAtkins> Topic: clarify padding-bottom in overflow
<TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/129
<fantasai> https://github.com/w3c/csswg-drafts/issues/129#issuecomment-887901550
<TabAtkins> florian: We've been working for a while on what does and doesn't count as scrollable overflow
<TabAtkins> florian: This is one of few remaining
<TabAtkins> florian: When you have an inline that pokes out of the scrollable area
<TabAtkins> florian: For most things that poke out, you add the scroll container's padding at the end edge, so when you scroll all the way you still have padding between the poking thing and the scrollbar
<TabAtkins> florian: but in this case, in the inline case, there's not interop
<TabAtkins> florian: In firefox if your inline pokes out in the inline direction, firefox doesn't add padding
<TabAtkins> florian: Chrome and WebKit do *some* of the time
<TabAtkins> florian: clarification: in the inline direction, in firefox, whether it's an inline or block poking out doesn't amtter; it doesn't get padding
<TabAtkins> florian: for chrome/webkit, if a block pokes out in the inline direction it gets padding
<TabAtkins> florian: (correction - it does not get padding)
<TabAtkins> florian: For inlines poking out int he inline direction, it gets padding if it's a direct child of the scroll container, but not if it's nested
<TabAtkins> florian: So initial though it that 'padding' means you want it, so having as much padding as we can is nice
<TabAtkins> florian: But also if we start adding padding where we didn't before, we're likely to make scrollbars that don't exist right now
<TabAtkins> florian: But that usually makes authors unhappy
<TabAtkins> florian: So "as much padding as we can get" is probably what we have today
<emilio> q+
<TabAtkins> florian: Was initially tempted to spec chrome/webkit behavior, but it's too weird
<TabAtkins> florian: So even tho I think we should have padding, I think we're compat constrained. We should pick something reasonable, which means Firefox's beahvior
<TabAtkins> emilio: I agree.
<fantasai> https://www.software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%0A%3Cdiv%20style%3D%22overflow%3A%20scroll%3B%20width%3A%20100px%3B%20border%3A%20solid%3B%20padding%3A%2020px%3B%22%3E%0A%20%20directchildtextthatoverflows%0A%3C%2Fdiv%3E%0A%0A%3Cdiv%20style%3D%22overflow%3A%20scroll%3B%20width%3A%20100px%3B%20border%3A%20solid%3B%20padding%3A%2020px%3B%22%3E%0A%20%20%3Cdiv%3Etextinsidedivt
<fantasai> hatoverflows%3C%2Fdiv%3E%0A%3C%2Fdiv%3E
<TabAtkins> emilio: curiosity question - do chrome/webkit use layouttree parent, or dom parent? does shadow dom matter?
<fantasai> testcase: https://www.software.hixie.ch/utilities/js/live-dom-viewer/saved/9521
<TabAtkins> florian: [shrugs]
<TabAtkins> emilio: yeah exactly. i'm in favor of something simple
<TabAtkins> Rossen_: thoughts?
<TabAtkins> TabAtkins: Other than agreeing with Florian that we shoudl have had padding, I think his current idea is good
<flackr> +1
<TabAtkins> myles: reason we implemented this originally was we wanted visual area to look more symmetrical
<TabAtkins> myles: I think the resolution would stop that?
<TabAtkins> myles: if you scroll down you're likely to get something not matching the top?
<TabAtkins> fantasai: The block axis already respects padding, this is for the inline axis
<TabAtkins> fantasai: We also resolved earlier that if you set justify-content to anything not 'normal', we apply the padding
<TabAtkins> fantasai: So there's an opt-in in the spec
<TabAtkins> florian: Right, forgot to mention that. this is only for justify-content:normal
<argyle> made this when i learned about this https://codepen.io/argyleink/pen/vYNYVOB
<TabAtkins> myles: the reason we didn't do it in inline axis was it was inconvenient to implement in the beginning. wasn't an intentional design choice. horizontal scrollbars are fairly rare anyway
<TabAtkins> RESOLVED: Go with Firefox's behavior - no elements cause the scroll container's inline-end padding to be used
<TabAtkins> <br dur=10min>
<toga> requests a new scribe so I can spend more time with Tab
aethanyc commented 3 years ago

http://wpt.live/css/css-overflow/overflow-padding.html should be fixed to match the resolution.

frivoal commented 3 years ago

@bfgeek Can you say a little bit about why you want this back on the agenda? Should I hold off doing the edits?

bfgeek commented 3 years ago

Yes - sorry I was OOO last week. I'm pretty sure that we can do something better for web developers here but we'd need to un-resolve that resolution. We aren't necessarily compat constrained here. (have data).

css-meeting-bot commented 3 years ago

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

The full IRC log of that discussion <dael> Topic: [css-overflow-3] Clarify padding-bottom in overflow content
<dael> github: https://github.com/w3c/csswg-drafts/issues/129#issuecomment-891194919
<dael> iank_: I wasn't around last week. We have data that weren't not as compat constrained as we thought. So I'd like to undo resolution
<dael> iank_: We've been slowly changing our behavior. most recently for flex to consider inline and block end padding. Did this in Chrome 91 which has been out for 2 months. Haven't received any bug reports
<dael> fantasai: That's in the spec already
<dael> florian: Resolution is only block layout
<dael> iank_: Getting to that. As part of this we had use counters
<dael> iank_: 1 for if we change behavior for if flexbox already scrolled
<dael> iank_: [missed] If block it's already scrollable that's less than the change we did for flexbox. So if the block scrollable element is scrollable in that axis we can add the end padding
<dael> iank_: Second is that we're making something not previously scrollable in inline direction. looking at data might be web compat as well but need to investigate more. One library is causing use counter to be relatively high and I need to research more. May be one trick we need to do
<dael> florian: If I got that right you say that even w/o adding padding we were scrollable that case is safe? And looking at remaining?
<dael> iank_: Coorrect
<dael> florian: How long to get data? I think you're right that if we can do it it's preferable
<dael> iank_: That's why i want to undo previous
<dael> florian: Or at least hold
<dholbert> q+
<dael> iank_: If something is scrollable and we add inline-end padding that's fine. Should revert that. we're prepared to try and we can report back. We're doing this slowly and watching metrics
<dael> iank_: I think still might be possible to do it universally. one trick we might need to do
<astearns> ack dholbert
<dael> dholbert: The bit about if things are already scrollable makes me slightly uneasy. Are you saying whether or not we include inline padding depends on if we're overflowing and what happens to content changes where we wouldn't be
<astearns> +1 to concern if we can only do this for already-scrollable things
<dael> iank_: Today Chrome calc both overflow areas and return one or the other. With these 2 overflow areas can compare to padding rect and see this is already scrollable so we could return slightly larger one.
<dael> iank_: If it became dynamic and it didn't have overflow we would stp including inline end padding
<dael> dholbert: And if it would if you inlcude inline end and wouldn't if you didn't? Or if you weren't in that scenario and content is deleted do we suddenly not include the inline padding?
<dael> iank_: Correct
<dael> florian: Prop we resolve on this, leave rest, and you tell us when you know? Or leave whole undefined?
<dael> iank_: Prob easiest to leave undefined at the moment with an explanation. I think might be able to do universal but I need more use counters
<dael> florian: I suspect it's worth waiting for if it's a reasonable timeframe. It's a better behavior
<dael> iank_: Yeah. I need to add use counters to detect for this library to see if we break
<fantasai> I'm ok with leaving this specific case -- inline-end padding within block container scroller -- to be undefined for now
<dael> florian: Do we need to be concerned about different compat concerns for other browsers?
<dael> iank_: Not for inline. I would have been more concerned about block
<dael> iank_: Example timeframe for the data is 3-6 months
<dael> astearns: Is that reasonable timeframe?
<dael> florian: I guess. Was hoping for CR shorter
<dael> iank_: Issue has been open for 5 years
<dael> astearns: And we have reverted resolutions in the past too
<dael> astearns: My understanding is that we are gaining consensus on undo previous resolution and leave the issue open until more data
<dael> fantasai: Happy to leave undefined but I don't think needs to block CR
<dael> astearns: Undefined in draft?
<dael> florian: It's an issue. We'll mark as issue and undefined
<dael> astearns: Prop: Undo previous resolution. Explicitly mark as undefined in the draft for now
<dael> astearns: Obj?
<dael> RESOLVED: Undo previous resolution. Explicitly mark as undefined in the draft for now
<fantasai> s/mark/mark inline-end padding of block container scrollers/
<dael> iank_: What I'm going to do next is change behavior to include inline end padding if it was scrollable and I'll add another use counter for the case I was more worried about. I'll report back in a couple months
keviinnch commented 3 years ago

umm, I'm sorry, but is this issue resolved? I use Chrome 92.0.4515.131 and it seems that the padding (right-padding) is already work as expected, or this thread is only for discussing the draft spec, but not the issue itself? (sorry if this is a dumb question..)

frivoal commented 3 years ago

this thread is only for discussing the draft spec

Yes, this whole repository is for discussing specifications. Of course, specs and implementations are expected to match each-other, but if you're interested in the status of a particular bug in a particular browser, this is the wrong repo to be looking at.

lyjk-underdog commented 2 years ago

If the scroll container has different types of children, how to determine the scrollable overflow rectangular area?