- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 27 Feb 2019 17:31:27 +0000
- To: public-css-archive@w3.org
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` <details><summary>The full IRC log of that discussion</summary> <fremy> Topic: Grid (padding and overscroll area)<br> <astearns> github: https://github.com/w3c/csswg-drafts/issues/3665<br> <fremy> fantasai: this is a follow-up of last issue<br> <fremy> fantasai: where we resolved to take explicit tracks into account in the scroll area<br> <fremy> fantasai: but we had a tangent discussion about considering the padding<br> <fremy> fantasai: we have compat because in the case of block<br> <fremy> fantasai: (missed the details of the compat case_<br> <fremy> fantasai: but we don't have such a compat issue for grid, so we can do this thing right<br> <fremy> astearns: and we would be doing this for flexbox as well?<br> <fremy> fantasai: yes<br> <fremy> fantasai: we already had people asking for this to be fixed for blocks<br> <fremy> fantasai: and the closest we could do was to do this correctly when alignement properties have a non-default value<br> <tantek> +1<br> <fremy> dholbert: doesn't chrome already do that in the block direction?<br> <fremy> fantasai: yes, but we want to change the spec to require both axises<br> <TabAtkins> Trying to find a room with a not-broken gvc unit<br> <fremy> dbaron: what are you proposing to include exactly?<br> <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<br> <fremy> dbaron: and what is the change?<br> <fremy> fantasai: include the paddings<br> <fremy> florian: when the alignment is the default<br> <fremy> dbaron: but how about the margins?<br> <fremy> dbaron: I thought it wasn't interoperable<br> <fremy> dbaron: I would like the spec text to be very clear about what margins are included<br> <fremy> dbaron: for example, descendant margins, collapsing margins, and their interactions<br> <fremy> florian: but this is orthogonal to padding though<br> <fremy> dbaron: yes, you're right, I just didn't know what was the change proposal about<br> <fremy> dbaron: I would be fine with any behavior, but would like the spec to be clear<br> <tantek> tests and examples for proposal?<br> <fremy> ?: do we have tests?<br> <tantek> s/?/tantek<br> <fremy> fantasai: no, but I can make one<br> <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<br> <fremy> florian: (restate what has been written above to rego)<br> <fantasai> In Firefox, there's only padding in the top/left<br> <fantasai> In Chrome, you also have padding at the bottom<br> <fremy> Rossen: sounds great, let's do it<br> <fantasai> Authors expect padding on all sides.<br> <tantek> I see padding on all sides of the blue square in FF67 nightly<br> <fremy> Rossen: back when IE implemented this, we did it "right" be default<br> <fremy> Rossen: then got compat issues<br> <fremy> Rossen: but ideally we think this should be the default, so I support this change<br> <fremy> astearns: where are we gonna write that?<br> <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<br> <fremy> jensimmons_: I think for authors it's great that the new layout work properly, and then there is legacy<br> <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<br> <fremy> astearns: what about dbaron's concern that everything should be well defined<br> <fremy> fantasai: we should add all these details in the overflow spec<br> <tantek> fantasai, I see the same result in Safari and FF67. Blue square with padding all around it between it and black border<br> <fremy> fantasai: but the general behavior should be in the alignment spec, that only deals to inflow content<br> <rego> tantek: this is another example https://jsbin.com/yizuzanado/1/edit?html,output<br> <fremy> fantasai: but well, I agree, there will be changes in a couple of specs to achieve this result<br> <fremy> astearns: grid and flexbox are probably gonna be relased before overflow though<br> <fremy> astearns: so pulling it in would help get this to REC sooner<br> <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<br> <fremy> astearns: any objection to this proposal?<br> <tantek> rego, that example is inconsistent across FF67 (no scrollable padding bottom & right), and Safari (no scrollable padding right)<br> <fantasai> proposed resolution: include padding in scrollable overflow area, edits to grid/flexbox/alignment/overflow<br> <fremy> RESOLVED: change the specs so that the default scroll area includes paddings by default for grid and flexbox<br> <fremy> tantek: is there commitment to make the change in chrome?<br> <fremy> rego: yes, we will make the change<br> <fremy> tantek: cool<br> <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...<br> <rego> at least we'll send the patch to Chromium and WebKit, if Apple doesn't agree with this I don't know<br> <fremy> Rossen: ... to minimize the amount of empty space you are scrolling to<br> <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<br> <fremy> Rossen: so I don't think dropping padding there is an option that isn't weird<br> <fremy> Rossen: but we might want to give a chance to webkit folks to take a look<br> <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<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3665#issuecomment-467955648 using your GitHub account
Received on Wednesday, 27 February 2019 17:31:30 UTC