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

Open
jcrben opened this Issue May 20, 2016 · 19 comments

Comments

Projects
None yet
@jcrben

jcrben commented May 20, 2016

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

This comment has been minimized.

Show comment
Hide comment
@tabatkins

tabatkins May 24, 2016

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.

Member

tabatkins commented 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

This comment has been minimized.

Show comment
Hide comment
@tabatkins

tabatkins May 26, 2016

Member

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

Member

tabatkins commented May 26, 2016

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

@tabatkins tabatkins closed this May 26, 2016

@frivoal frivoal changed the title from Clarify padding-bottom in overflow content to [css-overflow-3] Clarify padding-bottom in overflow content May 26, 2016

@litherum

This comment has been minimized.

Show comment
Hide comment
@litherum

litherum May 26, 2016

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.

Contributor

litherum commented 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

This comment has been minimized.

Show comment
Hide comment
@frivoal

frivoal May 26, 2016

Contributor

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.

Contributor

frivoal commented 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 frivoal reopened this May 26, 2016

@frivoal

This comment has been minimized.

Show comment
Hide comment
@frivoal

frivoal May 26, 2016

Contributor

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

Contributor

frivoal commented 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

This comment has been minimized.

Show comment
Hide comment
@tabatkins

tabatkins May 27, 2016

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

Member

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

@hallvors hallvors referenced this issue in webcompat/web-bugs Jun 13, 2016

Open

www.amazon.co.uk - mobile site is not usable #803

@tabatkins

This comment has been minimized.

Show comment
Hide comment
@tabatkins

tabatkins Jun 22, 2016

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

Member

tabatkins commented Jun 22, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@litherum

litherum Jun 22, 2016

Contributor

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

Contributor

litherum commented Jun 22, 2016

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

@tabatkins tabatkins self-assigned this Jun 23, 2016

@sarazhang123

This comment has been minimized.

Show comment
Hide comment

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

@SebastianZ

This comment has been minimized.

Show comment
Hide comment
@SebastianZ

SebastianZ Jul 11, 2017

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

Contributor

SebastianZ commented Jul 11, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@bzbarsky

bzbarsky Jul 11, 2017

Collaborator

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.

Collaborator

bzbarsky commented Jul 11, 2017

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

This comment has been minimized.

Show comment
Hide comment
@nuxodin

nuxodin Oct 18, 2017

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.

nuxodin commented Oct 18, 2017

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

This comment has been minimized.

Show comment
Hide comment
@frivoal

frivoal Dec 14, 2017

Contributor

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

Contributor

frivoal commented Dec 14, 2017

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

@frivoal frivoal self-assigned this Dec 14, 2017

@frlinw

This comment has been minimized.

Show comment
Hide comment
@frlinw

frlinw Jan 10, 2018

  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 commented Jan 10, 2018

  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

This comment has been minimized.

Show comment
Hide comment
@fantasai

fantasai Mar 6, 2018

Contributor

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

Contributor

fantasai commented Mar 6, 2018

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

@frlinw

This comment has been minimized.

Show comment
Hide comment
@frlinw

frlinw Mar 6, 2018

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.

frlinw commented Mar 6, 2018

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.

@fantasai fantasai added the Agenda+ F2F label Mar 6, 2018

@css-meeting-bot

This comment has been minimized.

Show comment
Hide comment
@css-meeting-bot

css-meeting-bot Apr 12, 2018

Member

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

css-meeting-bot commented Apr 12, 2018

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

This comment has been minimized.

Show comment
Hide comment
@nuxodin

nuxodin Apr 12, 2018

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 commented Apr 12, 2018

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;

@frlinw

This comment has been minimized.

Show comment
Hide comment
@frlinw

frlinw Apr 12, 2018

@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

frlinw commented Apr 12, 2018

@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

@dholbert dholbert referenced this issue in webcompat/web-bugs Apr 13, 2018

Open

recharts.org - design is broken #14385

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