Re: [csswg-drafts] [css-overflow-3] Clarify padding in overflow content (#129)

The CSS Working Group just discussed `[css-overflow-3] Clarify padding in overflow content`, and agreed to the following:

* `RESOLVED: Always require inline-end padding to be added against the inline-end alignment edge for block/flow layout when it’s a scroll container, thus matching the tests.`

<details><summary>The full IRC log of that discussion</summary>
&lt;emeyer> Topic: [css-overflow-3] Clarify padding in overflow content<br>
&lt;emeyer> Github: https://github.com/w3c/csswg-drafts/issues/129#issuecomment-1113489051<br>
&lt;emeyer> iank_: Browser have been very inconsistent about when something is a scroll container to apply block- or inline-end padding.<br>
&lt;emeyer> …Chrome very slowly has been moving towards end padding in both inline and block directions in block layout mode.<br>
&lt;iank_> https://wpt.fyi/results/css/css-overflow/scrollable-overflow-padding.html?label=master&amp;label=experimental&amp;aligned&amp;q=css-overflow<br>
&lt;emeyer> …I added an exhaustive set of tests that’s linked in the comment. This test creates a zero-area div and then relposed out of the way, but that zero area div is used to push padding out in either inline or block direction is various writing modes.<br>
&lt;emeyer> …As I was reading back through the issue, there was a conception that there are two cases that should behave the same.  If you’ve got inline content that’s very long in a scroll behavior, it should behave the same as if it’s been warpped in a div.  But the div isn’t intrinsically sized and won’t push parent padding out.<br>
&lt;emeyer> astearns: The test cases you’re talking about are supported by spec text?<br>
&lt;emeyer> iank_: Yes.<br>
&lt;emeyer> florian: We have a conceptual agreement that there might be web compatibility issues because if scrollbars show up where they didn’t used to be, that could be a problem.<br>
&lt;emeyer> iank_: The spec text has written down our curtent behavior.  We’re shipping that behavior now.<br>
&lt;TabAtkins> spec text: "Including this padding is optional for block containers in the inline axis if align-content is normal." with a note saying "hopefully this isn't optional, we're waiting for web compat"<br>
&lt;florian> s/We have a conceptual agreement that/We have a conceptual agreement that adding the padding would be good, but/<br>
&lt;emeyer> s/curtent/current/<br>
&lt;emeyer> fantasai: Do we want to tighten up the spec now, or wait to tighten it up once there’s field data?<br>
&lt;emeyer> astearns: Has there been enough time to evaluate web compatibility?<br>
&lt;emeyer> iank_: We think so.  We shipped the “scary” behavior a couple of months ago and got zero pushback.<br>
&lt;emeyer> florian: If other implementors are happy with it, would be happy to tighten the spec now.<br>
&lt;emeyer> dholbert: This sounds fine to me, speaking from Firefox’s perspective.  Having that barrier removed makes this pretty straightforward.<br>
&lt;emeyer> smfr: Seems reasonable.<br>
&lt;fantasai> s/that barrier/the Web-compat concern/<br>
&lt;emeyer> RESOLVED: Always require inline-end padding to be added against the inline-end alignment edge for block/flow layout when it’s a scroll container, thus matching the tests.<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-1124000267 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 11 May 2022 16:36:13 UTC