- From: Daniel Holbert via GitHub <sysbot+gh@w3.org>
- Date: Mon, 10 Jan 2022 22:37:42 +0000
- To: public-css-archive@w3.org
> That is helpful. I didn't know the goal. Glad that helps! Grounding it in some spec text and making it more concrete, the spec does in fact define it as-such here: https://drafts.csswg.org/css-flexbox-1/#intrinsic-main-sizes "The max-content main size of a flex container is **the smallest size the flex container can take while maintaining the max-content contributions of its flex items, insofar as allowed by the items’ own flexibility** And then the algorithm that follows is attempting to define how to compute that size (perhaps with flaws right now). > > [gut: we should use scaled flex shrink factor] This isn't what I was intending to say in https://github.com/w3c/csswg-drafts/issues/6909#issuecomment-1009378118. Rather, I was just saying that **the suggestion from your initial comment here** (swapping in `flex shrink factor` as a drop-in replacement) is probably not the right fix. > We end up doing nonsensical calculations, as described above. As is, the algorithm is unimplementable. Sounds like we do need *some* fix to how the scaled flex-shrink factor is used, then. -- GitHub Notification of comment by dholbert Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6909#issuecomment-1009416369 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Monday, 10 January 2022 22:37:44 UTC