Re: [csswg-drafts] [css-sizing-3] Content contribution of min-inline-size:fit-content and max-inline-size:fit-content (#10721)

The CSS Working Group just discussed `[css-sizing-3] Content contribution of min-inline-size:fit-content and max-inline-size:fit-content`, and agreed to the following:

* `RESOLVED: No normative change to spec, but add example like Oriol's and make the implication clearer in the spec.`

<details><summary>The full IRC log of that discussion</summary>
&lt;TabAtkins> oriol: when you're computing intrinsic cocntirubtion of a fit-content element, what should happen?<br>
&lt;TabAtkins> oriol: if you use fit-content on the preferred sizing property, it's clear that for the purpose of computing min-content contribution, you treat it as min-content; for max-content contrib, you treat it as max-content<br>
&lt;TabAtkins> oriol: but if you use this keyword on min or max sizing properties, it's less clear what shoudl happen<br>
&lt;TabAtkins> oriol: what webkit does is it just ignores the keyword, so in a min property it treats as 0, in max it treats it as none<br>
&lt;TabAtkins> oriol: blink used to have the same behavior, but changed to align with firefox<br>
&lt;TabAtkins> oriol: firefox beahvior is, when computing intrinsic contribs, fit-content acts as min-content in min sizing property, and as max-content in a max sizing property<br>
&lt;TabAtkins> oriol: i was implementing in servo and i think there's a better behavior, and i think it's what's actually specified in the spec, and is a bit simpler to implement<br>
&lt;oriol> https://github.com/w3c/csswg-drafts/issues/10721#issuecomment-2414743959<br>
&lt;TabAtkins> oriol: some testcases ^^^<br>
&lt;TabAtkins> oriol: in this testcase, magenta wrapper has a fixed width - first very narrow, then between, then wider<br>
&lt;fantasai> &lt;3 Oriol's examples<br>
&lt;TabAtkins> oriol: element with black border is inline-block, so shrink-to-fit<br>
&lt;TabAtkins> oriol: the inline-block contains one element with `width` to a huge amount, and max-width:fit-content<br>
&lt;TabAtkins> oriol: so webkit ignores the max-width so the width makes it all explode<br>
&lt;TabAtkins> oriol: gecko and blink treat it as max-content, so the inline-block is always sized as max-content<br>
&lt;TabAtkins> oriol: i think the servo column is better. do the smae for the three sizing props<br>
&lt;TabAtkins> oriol: you always treat it as min-content when doing min-content contribution, and similar for max, for all three properties<br>
&lt;TabAtkins> oriol: so if magenta wrapper is narrow you'll use the min-content contribution, if wide you'll use the max-content contribution, and if between it'll be between<br>
&lt;TabAtkins> oriol: i think this is a better match for fit-content, trying to fit into the container<br>
&lt;TabAtkins> oriol: so i propose the spec is right, and servo is right, and other browsers should match<br>
&lt;astearns> ack fantasai<br>
&lt;TabAtkins> fantasai: thanks for the fantastic examples<br>
&lt;TabAtkins> fantasai: as editor, i think Servo's impl is correct. it reflects the author's request<br>
&lt;TabAtkins> fantasai: in 2.1's definition of min/max sizing properties, it says you literally run layout by subbing in the value for 'width' and then clamp appropriately; this matches that behavior as well<br>
&lt;TabAtkins> iank_: I think this is likely fine.<br>
&lt;TabAtkins> iank_: hopefully no compat issues, but on the surface it's not too difficult for us to do<br>
&lt;TabAtkins> astearns: so are we resolving the spec is correct?<br>
&lt;TabAtkins> oriol: yes<br>
&lt;TabAtkins> iank_: it's not obvious to me that the spec is correct, so clarifying would be good for the future<br>
&lt;TabAtkins> oriol: at end of th eissue i posted the quote of the spec that i think is backing the servo behavior, we can clarify or add some examples<br>
&lt;TabAtkins> examples++<br>
&lt;TabAtkins> fantasai: the spec doesn't make a distinction between what fit-content size means based on property, so i don't think it can support an interpretation that it works differentyl in the different properties<br>
&lt;TabAtkins> astearns: so let's make that explicit<br>
&lt;TabAtkins> astearns: so proposed resolution is we add examples like Oriol's and make the implication clear in the spec<br>
&lt;TabAtkins> RESOLVED: No normative change to spec, but add example like Oriol's and make the implication clearer in the spec.<br>
</details>


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


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

Received on Wednesday, 12 March 2025 16:34:29 UTC