Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[css-grid-1] Include padding in scrollable overflow area #3665

Closed
fantasai opened this issue Feb 20, 2019 · 2 comments
Closed

[css-grid-1] Include padding in scrollable overflow area #3665

fantasai opened this issue Feb 20, 2019 · 2 comments
Labels

Comments

@fantasai
Copy link
Collaborator

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

@css-meeting-bot
Copy link
Member

The CSS Working Group just discussed Grid (padding and overscroll area), and agreed to the following:

  • RESOLVED: change the specs so that the default scroll area includes paddings by default for grid and flexbox
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
<tantek> +1
<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?
<tantek> s/?/tantek
<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

fantasai added a commit that referenced this issue Apr 18, 2019
…e overflow area except for block containers (which is where the Web-compat problem is). #3665
fantasai added a commit that referenced this issue Apr 18, 2019
…e overflow area except for block containers. Trying again because the last commit was wrong and bad. This time working off https://www.w3.org/TR/2018/WD-css-align-3-20181206/#overflow-scroll-position as a model. #3665
@fantasai
Copy link
Collaborator Author

OK, fixed this in css-overflow-3 as follows:

Padding on the end-edge sides of the scrollable overflow rectangle representing the end-side padding applied to the scroll container, added such that its content can be scrolled to a position that would satisfy the requirements of place-content: end alignment. Including this padding is optional for block containers in any axis whose corresponding content-distribution property (align-content/justify-content) is normal.

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants