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

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

* `RESOLVED: Undo previous resolution. Explicitly mark as undefined in the draft for now`

<details><summary>The full IRC log of that discussion</summary>
&lt;dael> Topic: [css-overflow-3] Clarify padding-bottom in overflow content<br>
&lt;dael> github: https://github.com/w3c/csswg-drafts/issues/129#issuecomment-891194919<br>
&lt;dael> iank_: I wasn't around last week. We have data that weren't not as compat constrained as we thought. So I'd like to undo resolution<br>
&lt;dael> iank_: We've been slowly changing our behavior. most recently for flex to consider inline and block end padding. Did this in Chrome 91 which has been out for 2 months. Haven't received any bug reports<br>
&lt;dael> fantasai: That's in the spec already<br>
&lt;dael> florian: Resolution is only block layout<br>
&lt;dael> iank_: Getting to that. As part of this we had use counters<br>
&lt;dael> iank_: 1 for if we change behavior for if flexbox already scrolled<br>
&lt;dael> iank_: [missed] If block it's already scrollable that's less than the change we did for flexbox. So if the block scrollable element is scrollable in that axis we can add the end padding<br>
&lt;dael> iank_: Second is that we're making something not previously scrollable in inline direction. looking at data might be web compat as well but need to investigate more. One library is causing use counter to be relatively high and I need to research more. May be one trick we need to do<br>
&lt;dael> florian: If I got that right you say that even w/o adding padding we were scrollable that case is safe? And looking at remaining?<br>
&lt;dael> iank_: Coorrect<br>
&lt;dael> florian: How long to get data? I think you're right that if we can do it it's preferable<br>
&lt;dael> iank_: That's why i want to undo previous<br>
&lt;dael> florian: Or at least hold<br>
&lt;dholbert> q+<br>
&lt;dael> iank_: If something is scrollable and we add inline-end padding that's fine. Should revert that. we're prepared to try and we can report back. We're doing this slowly and watching metrics<br>
&lt;dael> iank_: I think still might be possible to do it universally. one trick we might need to do<br>
&lt;astearns> ack dholbert<br>
&lt;dael> dholbert: The bit about if things are already scrollable makes me slightly uneasy. Are you saying whether or not we include inline padding depends on if we're overflowing and what happens to content changes where we wouldn't be<br>
&lt;astearns> +1 to concern if we can only do this for already-scrollable things<br>
&lt;dael> iank_: Today Chrome calc both overflow areas and return one or the other. With these 2 overflow areas can compare to padding rect and see this is already scrollable so we could return slightly larger one.<br>
&lt;dael> iank_: If it became dynamic and it didn't have overflow we would stp including inline end padding<br>
&lt;dael> dholbert: And if it would if you inlcude inline end and wouldn't if you didn't? Or if you weren't in that scenario and content is deleted do we suddenly not include the inline padding?<br>
&lt;dael> iank_: Correct<br>
&lt;dael> florian: Prop we resolve on this, leave rest, and you tell us when you know? Or leave whole undefined?<br>
&lt;dael> iank_: Prob easiest to leave undefined at the moment with an explanation. I think might be able to do universal but I need more use counters<br>
&lt;dael> florian: I suspect it's worth waiting for if it's a reasonable timeframe. It's a better behavior<br>
&lt;dael> iank_: Yeah. I need to add use counters to detect for this library to see if we break<br>
&lt;fantasai> I'm ok with leaving this specific case -- inline-end padding within block container scroller -- to be undefined for now<br>
&lt;dael> florian: Do we need to be concerned about different compat concerns for other browsers?<br>
&lt;dael> iank_: Not for inline. I would have been more concerned about block<br>
&lt;dael> iank_: Example timeframe for the data is 3-6 months<br>
&lt;dael> astearns: Is that reasonable timeframe?<br>
&lt;dael> florian: I guess. Was hoping for CR shorter<br>
&lt;dael> iank_: Issue has been open for 5 years<br>
&lt;dael> astearns: And we have reverted resolutions in the past too<br>
&lt;dael> astearns: My understanding is that we are gaining consensus on undo previous resolution and leave the issue open until more data<br>
&lt;dael> fantasai: Happy to leave undefined but I don't think needs to block CR<br>
&lt;dael> astearns: Undefined in draft?<br>
&lt;dael> florian: It's an issue. We'll mark as issue and undefined<br>
&lt;dael> astearns: Prop: Undo previous resolution. Explicitly mark as undefined in the draft for now<br>
&lt;dael> astearns: Obj?<br>
&lt;dael> RESOLVED: Undo previous resolution. Explicitly mark as undefined in the draft for now<br>
&lt;fantasai> s/mark/mark inline-end padding of block container scrollers/<br>
&lt;dael> iank_: What I'm going to do next is change behavior to include inline end padding if it was scrollable and I'll add another use counter for the case I was more worried about. I'll report back in a couple months<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-893052191 using your GitHub account


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

Received on Wednesday, 4 August 2021 23:57:26 UTC