Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
[css-grid-1] Include padding in scrollable overflow area #3665
We've been wanting to include padding in the scrollable overflow area (to provide the specified space between the content and the border in all cases, not just when there's no overflow) in general, but we're constrained by compat in the general case. Florian points out that we're not so constrained for Grid/Flexbox, so maybe we should consider fixing this in Grid/Flexbox in general, not just for 'align-content: not-normal'.
The CSS Working Group just discussed
The full IRC log of that discussion<fremy> Topic: Grid (padding and overscroll area)
<astearns> github: https://github.com//issues/3665
<fremy> fantasai: this is a follow-up of last issue
<fremy> fantasai: where we resolved to take explicit tracks into account in the scroll area
<fremy> fantasai: but we had a tangent discussion about considering the padding
<fremy> fantasai: we have compat because in the case of block
<fremy> fantasai: (missed the details of the compat case_
<fremy> fantasai: but we don't have such a compat issue for grid, so we can do this thing right
<fremy> astearns: and we would be doing this for flexbox as well?
<fremy> fantasai: yes
<fremy> fantasai: we already had people asking for this to be fixed for blocks
<fremy> fantasai: and the closest we could do was to do this correctly when alignement properties have a non-default value
<fremy> dholbert: doesn't chrome already do that in the block direction?
<fremy> fantasai: yes, but we want to change the spec to require both axises
<TabAtkins> Trying to find a room with a not-broken gvc unit
<fremy> dbaron: what are you proposing to include exactly?
<fremy> fantasai: boxes that are in flow, and their border box, plus the entire grid, and the padding around all this should be included in the scrollable area
<fremy> dbaron: and what is the change?
<fremy> fantasai: include the paddings
<fremy> florian: when the alignment is the default
<fremy> dbaron: but how about the margins?
<fremy> dbaron: I thought it wasn't interoperable
<fremy> dbaron: I would like the spec text to be very clear about what margins are included
<fremy> dbaron: for example, descendant margins, collapsing margins, and their interactions
<fremy> florian: but this is orthogonal to padding though
<fremy> dbaron: yes, you're right, I just didn't know what was the change proposal about
<fremy> dbaron: I would be fine with any behavior, but would like the spec to be clear
<tantek> tests and examples for proposal?
<fremy> ?: do we have tests?
<fremy> fantasai: no, but I can make one
<fantasai> testcase - http://software.hixie.ch/utilities/js/live-dom-viewer/?%3C!DOCTYPE%20html%3E%0A%3Cdiv%20style%3D%22display%3A%20grid%3B%20width%3A%20100px%3B%20height%3A%20100px%3B%20padding%3A%2010px%3B%20overflow%3A%20scroll%3B%20border%3A%20solid%22%3E%0A%20%20%3Cdiv%20style%3D%22width%3A%20100px%3B%20height%3A%20100px%3B%20background%3A%20blue%3B%22%3E%3C%2Fdiv%3E%0A%3C%2Fdiv%3E
<fremy> florian: (restate what has been written above to rego)
<fantasai> In Firefox, there's only padding in the top/left
<fantasai> In Chrome, you also have padding at the bottom
<fremy> Rossen: sounds great, let's do it
<fantasai> Authors expect padding on all sides.
<tantek> I see padding on all sides of the blue square in FF67 nightly
<fremy> Rossen: back when IE implemented this, we did it "right" be default
<fremy> Rossen: then got compat issues
<fremy> Rossen: but ideally we think this should be the default, so I support this change
<fremy> astearns: where are we gonna write that?
<fremy> fantasai: in the same place as where the rules are today, but we can add a note to explain why block must be an exception
<fremy> jensimmons_: I think for authors it's great that the new layout work properly, and then there is legacy
<fremy> jensimmons_: it's great to clean cut from the past, if you rely on new things, you don't have to be aware of old legacy issues
<fremy> astearns: what about dbaron's concern that everything should be well defined
<fremy> fantasai: we should add all these details in the overflow spec
<tantek> fantasai, I see the same result in Safari and FF67. Blue square with padding all around it between it and black border
<fremy> fantasai: but the general behavior should be in the alignment spec, that only deals to inflow content
<rego> tantek: this is another example https://jsbin.com/yizuzanado/1/edit?html,output
<fremy> fantasai: but well, I agree, there will be changes in a couple of specs to achieve this result
<fremy> astearns: grid and flexbox are probably gonna be relased before overflow though
<fremy> astearns: so pulling it in would help get this to REC sooner
<fremy> florian: we can add a note in those specs, but in the end overflow is required for all modes, so it doesn't matter all that much
<fremy> astearns: any objection to this proposal?
<tantek> rego, that example is inconsistent across FF67 (no scrollable padding bottom & right), and Safari (no scrollable padding right)
<fantasai> proposed resolution: include padding in scrollable overflow area, edits to grid/flexbox/alignment/overflow
<fremy> RESOLVED: change the specs so that the default scroll area includes paddings by default for grid and flexbox
<fremy> tantek: is there commitment to make the change in chrome?
<fremy> rego: yes, we will make the change
<fremy> tantek: cool
<fremy> Rossen: just wanted to note that I had prior discussion on this topic, and one of the rules that some webkit engineers cared about was...
<rego> at least we'll send the patch to Chromium and WebKit, if Apple doesn't agree with this I don't know
<fremy> Rossen: ... to minimize the amount of empty space you are scrolling to
<fremy> Rossen: but for grid and flexbox, they are used as structure for other things, and it's important to preserve space because the space is part of the structure
<fremy> Rossen: so I don't think dropping padding there is an option that isn't weird
<fremy> Rossen: but we might want to give a chance to webkit folks to take a look
<fremy> astearns: as for all resolutions, things can be reversed if needed but as far as I know, we have a webkit contributor here planning to make the change
referenced this issue
Apr 18, 2019
OK, fixed this in css-overflow-3 as follows:
This is working off the precise definitions of where and how that padding is added introduced by css-align-3, which is afaict the correct definition that behaves the way we want it to behave in all the fun and weird edge cases.
Also for reference, see #129 where a lot of authors are describing their frustration with this problem--the more places we fix it, the happier they'll be. :)