- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 12 Apr 2018 14:02:28 +0000
- To: public-css-archive@w3.org
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.` <details><summary>The full IRC log of that discussion</summary> <dael_> Topic: padding-bottom in overflow content<br> <dael_> github: https://github.com/w3c/csswg-drafts/issues/129<br> <fantasai> https://github.com/w3c/csswg-drafts/issues/129<br> <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.<br> <dael_> TabAtkins: I'm one of these web authors.<br> <dael_> fantasai: Chrome includes that padding at the bottom. Request is everyone matches Chrome.<br> <dael_> emilio: One the spec issue there's a refrence to an old Mozilla bug.<br> <dael_> fantasai: I'm not sure spec is clear on what happens.<br> <dael_> TabAtkins: Prob not wrong that Moz thinks it's spec complient, I just think it's wrong. Everyone does it a little different.<br> <dael_> TabAtkins: There's a difference between block overflow and inline overflow.<br> <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.<br> <fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=5907<br> <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.<br> <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.<br> <dael_> fremy: Reasonable.<br> <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.<br> <dael_> fantasai: My current proposal is to leave padding and margin in general and say padding you have to leave space at the bottom.<br> <dael_> astearns: You're asking for a targeted fix and dbaron wants a general fix.<br> <dael_> TabAtkins: Would it be bad to resolve this and then try and resolve inline. It's a more complicated space.<br> <dael_> dbaron: I'd like to resolve we intend to change inline even thought we don't know how to do it.<br> <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.<br> <dael_> TabAtkins: When we nail down inline padding at least 2 browsers will have to change.<br> <dael_> dbaron: People care more about block because they scroll in that directio more.<br> <dael_> fantasai: And throwing in block axis overflow with scrolling is less unexpected.<br> <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.<br> <dael_> fantasai: Since we don't have a web compat constraint with bottom padding I think we should do that.<br> <dael_> astearns: Prop: Require that you leave space in scroll containers for block-end padding?<br> <dael_> TabAtkins: Cool.<br> <dael_> astearns: Add a note saying like to enforce for inline padding, but not sure if we can for web compat.<br> <dael_> fantasai: We'll file another issue on that.<br> <dael_> astearns: Okay dbaron ?<br> <fantasai> testcase for inline-end padding http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=5908<br> <dael_> astearns: I guess so.<br> <dael_> s/astears/dbaron<br> <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.<br> <fantasai> Looks like Chrome includes padding-inline-end http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=5908<br> <dael_> myles: I talke dto hyatt and he said he did it because it was symmetrical and looked better.<br> <dael_> myles: In webkit.<br> <dael_> myles: I think webkit.<br> <dael_> astearns: Objections?<br> <dael_> fantasai: I'd be happy to resolve for inline too.<br> <dael_> myles: I think we should do both.<br> <dael_> fantasai: Okay.<br> <dael_> astearns: Resolve and then talk inline or block?<br> <fantasai> s/too; just don't want to hold up block-end/<br> <dael_> myles: no preference<br> <dael_> astearns: Resolve for just block. Obj?<br> <dael_> RESOLVED: Require that you leave space in scroll containers for block-end padding in the scrollable area<br> <dael_> astearns: Do we also require space fo inline padding because consistency is nice.<br> <dael_> fantasai: There's a test case above in IRC: http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=5908<br> <dael_> emilio: Is that compat?<br> <dael_> TabAtkins: Chrome puts padding on all the sides.<br> <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?<br> <dael_> myles: When would the scrollbars not appear?<br> <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<br> <dael_> rune_: Bug report ^<br> <dael_> TabAtkins: It's a spec bug.<br> <dael_> rune_: Yeah, it's not compat.<br> <dael_> myles: Same argument applies<br> <dael_> astearns: And fremy agreed.<br> <dael_> astearns: dbaron wanted consistancy.<br> <dael_> astearns: Objections to Use same space saving for inline-padding?<br> <dael_> koji: It's a block inline<br> <dael_> fantasai: padding on scroll container itself. Everything else is undefined.<br> <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.<br> <dael_> myles: Same as my comment.<br> <dael_> TabAtkins: I didn't realize we did that as well.<br> <dael_> astearns: Maintain that?<br> <dael_> TabAtkins: No.<br> <dael_> astearns: Worried if you don't?<br> <dael_> fantasai: I have concerns but I won't block.<br> <fantasai> s/concerns/concerns about web compat/<br> <dael_> dbaron: Apply to content nested arbitrarily deep? You're propagating 2 versions to know if it's block or inline overflow?<br> <dael_> myles: I think the answer is no, just children.<br> <dael_> TabAtkins: No, it looks as far down as you want to know.<br> <fantasai> o_O<br> <dael_> astearns: Prop: Preserve space allocated by inline-end padding on the scroll container<br> <dael_> fantasai: Dunno abspos.<br> <dael_> myles: No browser does that. Scary.<br> <dael_> TabAtkins: It's close to blink and chrome<br> <dael_> dbaron: Inlines you add the padding and blocks you don't?<br> <dael_> myles: yes<br> <dael_> TabAtkins: Presumably difficulty of reading text flush with edge was the reason.<br> <dael_> dbaron: But then why not blocks?<br> <dael_> TabAtkins: Blocks aren't text.<br> <dael_> TabAtkins: Clarifiation. Inline content has to be a direct shild.<br> <dael_> myles: Toggle looks at just the chilred.<br> <dael_> dbaron: Inline inside a block child you don't apply<br> <dael_> dbaron: I think applying all the time is good, but I'd rather leave as is then keeping the inlive vs block.<br> <dael_> astearns: You don't want the chrome/webkit current.<br> <dael_> dbaron: Right.<br> <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.<br> <dael_> myles: So it's abspos and you say padding:0 it's now underdefined.<br> <dael_> fantasai: Previous resolution the padding is added to inflow contents.<br> <dael_> dbaron: Can you make inside of a scrollable area be abspos or only outside?<br> <dael_> fantasai: If I do abs something and the scroll container is relpos I can scroll.<br> <dael_> dbaron: Per spec it should be relative to height without scroll but I'm not sure that's what people implement.<br> <dael_> dbaron: Adjusted by size of scrollbars if you have to adjust for that.<br> <dael_> fantasai: Bottom edge of the abspos position container does not include the overflowing content. If the thing does overflow then things are weird.<br> <fantasai> s/are weird/are drawn below that boundary/<br> <dael_> TabAtkins: In chrome assuming scroll container is abspos and is right0 bottom0 the abspos is int he bottom right.<br> <dael_> dbaron: Befor eyou scroll<br> <dael_> dbaron: If it's causing the overflow do you scroll?<br> <dael_> fantasai: YOu only add the padding to the inflow content.<br> <rego> check chromium behavior in: https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=5909<br> <dael_> dbaron: But if a child of the scroll container is relpos but it has children that are bspos do you scroll?<br> <dael_> saDo abspos children of relpos contribute to the overflow characteristics of it's parent?<br> <dael_> dbaron: That's how we impl.<br> <dael_> TabAtkins: e do not add padding if the abspos is the overflowing.<br> <dael_> dbaron: Now for abspos you need to track this deep.<br> <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.<br> <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.<br> <dael_> fantasai: Don't think so.<br> <dael_> fremy: Made a test case and it's worse then that.<br> <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.<br> <dael_> dbaron: You're changing the model. I thought model was you have overflow, add padding around that, and then you overflow.<br> <dael_> fantasai: Then we added abspos.<br> <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.<br> <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.<br> <dael_> dbaron: This is what gecko impl and dev don't like.<br> <dael_> myles: In this model somet higns are inside the viewport.<br> <rego> this is the output of my example before: https://i.imgur.com/PQZ775X.png (edge behaves like firefox and webkit like chromium)<br> <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.<br> <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.<br> <dael_> dbaron: I buy that for abspos positioned reltaive tot he scroll container. I don't for things relative inside the scroll container.<br> <dael_> fantasai: Okay.<br> <dael_> dbaron: Did we test that?<br> <dael_> florian: Are you not worried that it would create lots of scrollbars?<br> <fantasai> http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=5910<br> <dael_> dbaron: I'ts worrying. An actual proposal with details would be good before resolve.<br> <dael_> fantasai: test case dbaron proposed ^<br> <dael_> dbaron: You can't scroll to the thing at all<br> <dael_> astearns: I'm worried you said this is what we used to do and dev hated.<br> <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<br> <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.<br> <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.<br> <dael_> fantasai: If previous is inflow content I think we're scoped okay.<br> <dael_> myles: Not if we're doing investigation. You're doing 1/4 of the issue.<br> <dael_> fantasai: But people want this 1/4 to work and that's web compat.<br> <dael_> fremy: If we don't have a model that's clear we'll impl and then re-impl.<br> <dael_> myles: Agree it's wasted work.<br> <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.<br> <dael_> astearns: I think we need spec text first.<br> <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.<br> <dael_> TabAtkins: It's not written anywhere to [i don't know noise]<br> <fremy> http://software.hixie.ch/utilities/js/live-dom-viewer/saved/5911<br> <fremy> ^ testcase with abspos in inline relative<br> <dael_> fantasai: Some of these cases will be exporatory to figure out what's web compat.<br> <TabAtkins> s/to [i don't know noise]/and I don't remember it, so iunno./<br> <dael_> astearns: Prop: Undo the previous resolution and continue to figure out a whole model.<br> <dael_> RESOLVED: Undo the previous resolution and continue to figure out a whole model.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/129#issuecomment-380815931 using your GitHub account
Received on Thursday, 12 April 2018 14:02:36 UTC