- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Thu, 29 Jul 2021 21:46:03 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `clarify padding-bottom in overflow`, and agreed to the following: * `RESOLVED: Go with Firefox's behavior - no elements cause the scroll container's inline-end padding to be used` <details><summary>The full IRC log of that discussion</summary> <TabAtkins> Topic: clarify padding-bottom in overflow<br> <TabAtkins> github: https://github.com/w3c/csswg-drafts/issues/129<br> <fantasai> https://github.com/w3c/csswg-drafts/issues/129#issuecomment-887901550<br> <TabAtkins> florian: We've been working for a while on what does and doesn't count as scrollable overflow<br> <TabAtkins> florian: This is one of few remaining<br> <TabAtkins> florian: When you have an inline that pokes out of the scrollable area<br> <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<br> <TabAtkins> florian: but in this case, in the inline case, there's not interop<br> <TabAtkins> florian: In firefox if your inline pokes out in the inline direction, firefox doesn't add padding<br> <TabAtkins> florian: Chrome and WebKit do *some* of the time<br> <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<br> <TabAtkins> florian: for chrome/webkit, if a block pokes out in the inline direction it gets padding<br> <TabAtkins> florian: (correction - it does not get padding)<br> <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<br> <TabAtkins> florian: So initial though it that 'padding' means you want it, so having as much padding as we can is nice<br> <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<br> <TabAtkins> florian: But that usually makes authors unhappy<br> <TabAtkins> florian: So "as much padding as we can get" is probably what we have today<br> <emilio> q+<br> <TabAtkins> florian: Was initially tempted to spec chrome/webkit behavior, but it's too weird<br> <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<br> <TabAtkins> emilio: I agree.<br> <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<br> <fantasai> hatoverflows%3C%2Fdiv%3E%0A%3C%2Fdiv%3E<br> <TabAtkins> emilio: curiosity question - do chrome/webkit use layouttree parent, or dom parent? does shadow dom matter?<br> <fantasai> testcase: https://www.software.hixie.ch/utilities/js/live-dom-viewer/saved/9521<br> <TabAtkins> florian: [shrugs]<br> <TabAtkins> emilio: yeah exactly. i'm in favor of something simple<br> <TabAtkins> Rossen_: thoughts?<br> <TabAtkins> TabAtkins: Other than agreeing with Florian that we shoudl have had padding, I think his current idea is good<br> <flackr> +1<br> <TabAtkins> myles: reason we implemented this originally was we wanted visual area to look more symmetrical<br> <TabAtkins> myles: I think the resolution would stop that?<br> <TabAtkins> myles: if you scroll down you're likely to get something not matching the top?<br> <TabAtkins> fantasai: The block axis already respects padding, this is for the inline axis<br> <TabAtkins> fantasai: We also resolved earlier that if you set justify-content to anything not 'normal', we apply the padding<br> <TabAtkins> fantasai: So there's an opt-in in the spec<br> <TabAtkins> florian: Right, forgot to mention that. this is only for justify-content:normal<br> <argyle> made this when i learned about this https://codepen.io/argyleink/pen/vYNYVOB<br> <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<br> <TabAtkins> RESOLVED: Go with Firefox's behavior - no elements cause the scroll container's inline-end padding to be used<br> <TabAtkins> <br dur=10min><br> <toga> requests a new scribe so I can spend more time with Tab<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-889481917 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 29 July 2021 21:46:05 UTC