Re: [csswg-drafts] [css-flexbox] Percentage height resolution of children of flex items with indefinite flex basis (#6822)

The CSS Working Group just discussed `[css-flexbox] Percentage height resolution of children of flex items with indefinite flex basis`, and agreed to the following:

* `RESOLVED: Reject the proposed change but clarify the specification; we invite Serifo to comment further if they have objections to this resolution`

<details><summary>The full IRC log of that discussion</summary>
&lt;emeyer> Topic: [css-flexbox] Percentage height resolution of children of flex items with indefinite flex basis<br>
&lt;emeyer> github: https://github.com/w3c/csswg-drafts/issues/6822<br>
&lt;emeyer> dgrogan: This is also an interop issue.  Chrome recently switched from WebKit to Firefox behavior, which we think is what’s specced.  Sergei from Igalia has a good argument for why WebKit might be better and should be specced.<br>
&lt;emeyer> TabAtkins: Elika says she agrees with dgrogan that we should try not to introduce new exceptions unless there’s a strong reason and we can describe it clearly.<br>
&lt;astearns> aethanyc = Ting-Yu Lin<br>
&lt;emeyer> dgrogan: When you have a column flexbox and the item’s flex basis is content, and a child of that item has a percent height do we resolve it in the final pass or do we make the flex item’s height indefinite?<br>
&lt;emeyer> …The spec currently roughly says it’s indefinite.  Proposal from Igalia is to make the child of an item with content flex basis resolve its height.<br>
&lt;emeyer> Rossen: When you say this, are you talking about the measurement of item in the last pass when you would have already computed all of the contributions of flex items?<br>
&lt;emeyer> fantasai: And the child with the percent is a block level box.<br>
&lt;emeyer> Rossen: I’m struggling to figure out why we would resolve the percent height, and mroe importantly how, if we don’t do it anywhere else.<br>
&lt;emeyer> dgrogan: The debate is around when do we resolve that height.  Are we on the same page for that?<br>
&lt;emeyer> dgrogan: The argument is, we already have a bunch of definiteness exceptions, so why not do another?<br>
&lt;emeyer> Rossen: In the contribution pass, you are not resolving percentages.  Which will most likely give the item a height based on its content.  When you go to the last pass, if you resolve the percentage of the block child, it will probably overflow or underflow.  So do we allow that overflow or underflow to satisfy the percentages?<br>
&lt;emeyer> dgrogan: That’s a good restatement.<br>
&lt;emeyer> …I don’t know that I can defend this.<br>
&lt;emeyer> oriol: I haven’t been following this in detail.  I also felt like WebKit is doing something different than the proposal.  I don]t have a strong opinion here.<br>
&lt;emeyer> iank_: I believe WebKit has a bug that it’s resolving during the contribution phase.  So looking at its output is a little complicated for teasing out the intended result.<br>
&lt;emeyer> …I somewhat prefer the Firefox behavior currently.  It’s aligned somewhat with other behaviors.<br>
&lt;emeyer> fremy: If you have the exact same scenario, but the page size is bigger, does that mean the thing won’t get shrunk?<br>
&lt;emeyer> dholbert: I think it would depend on other things, and I think uinrelated to this issue.<br>
&lt;emeyer> Rossen: It’s hard to argue about later stages if the earlier stages are inconsistent.<br>
&lt;emeyer> …I don’t know if we have good progress here.  This should maybe go back to the issue.  it sounds like the current spec [carrier lost]<br>
&lt;emeyer> astearns: It sounds like we’re converging against the original proposal?<br>
&lt;emeyer> iank_: I think Firefox and Blink are correct as per the spec’s definition of definiteness.<br>
&lt;emeyer> dgrogan: Correct.<br>
&lt;dholbert> (agreed)<br>
&lt;emeyer> astearns: Is what’s in the spec at the moment sufficient or does it need to be more clear?<br>
&lt;emeyer> dgrogan: I think there’s a part of the contribution spec that needs to be tightened up.<br>
&lt;emeyer> fantasai: I agree, we need to clarification in the spec.<br>
&lt;emeyer> RESOLVED: Reject the proposed change but clarify the specification; we invite Serifo to comment further if they have objections to this resolution<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6822#issuecomment-1022447206 using your GitHub account


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

Received on Wednesday, 26 January 2022 17:56:15 UTC