- From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
- Date: Fri, 22 Apr 2022 19:26:51 +0000
- To: public-css-archive@w3.org
Okay, so there's no way to rescue continuity here with the existing behavior we've put in the spec. Given two flex items, each with a `flex-basis: 0;` and 100px of min-content contribution: * `flex-grow`s of .1 and .9 give desired fractions of 1000px and ~111px, so we'll choose 1000px and get final sizes of 100px and 900px * `flex-grow`s of .01 and .99 give desired fractions of 1e4px and ~101px, so we choose 1e4 and get final sizes of 100px and 9900px * etc, resulting in a limit behavior at (0, 1) of the first item being 100px and the second item being infinity px, even tho the clearly desired behavior there is the first item being frozen (staying at its flex-basis of 0px) and the second getting to grow to 100px. The only way to rescue continuity is indeed to care about individual values <1; multiplying the (flex base size - contribution size) by the fraction first. (Or equivalently, floor the factor at 1 when calculating the desired flex fraction, which is what the original spec text did.) Since this would return us to the original spec text, I suspect *that's* why we wrote it that way originally; we must have been looking at growing cases rather than shrinking cases. So there are two options: 1. Return to the original spec text, which correctly handles growth but doesn't shrink as much as it could. 2. Use the individual-flooring behavior for growth, and the sum-flooring behavior for shrink. The issue, ultimately, is that the same goal - make at least one element reach its contribution size, and every other element be its contribution size or larger, given a single consistent fraction size - is produced asymmetrically for grow and shrink. In grow, you have to select the *largest* fraction to satisfy the goal, so the elements with a smaller desired fraction overshoot their contribution size; in shrink you have to select the *smallest* fraction, so the elements with a larger desired fraction stop *before* they get smaller than their contribution size. Both cases get an infinite blow-up for zeros and near-zeros, but that gets discarded in the shrink case but *honored* in the grow case. It might very well make sense to have these two cases require slightly different algos, then. -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/7189#issuecomment-1106796437 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 22 April 2022 19:26:52 UTC