Bugzilla

Alternate interpretation: maybe there's an argument to be made that my counterexample#1 doesn't have a cyclic percentage, since the containing block has a definite width.  (I'm not sure I buy that, since we're still asking the flex item for its min-content contribution, which is a measurement that's supposed to be independent of the surroundings, and hence feels like it becomes cyclic if it tries to resolve against the content block size.)  Under this alternate interpretation, https://github.com/w3c/csswg-drafts/issues/5665#issuecomment-797046688 would sort of explain my notes on Chrome's rendering of counterexample #1 .

Nonetheless: Example #4 in the css-sizing-3 spec (right after 5.2.1c) seems to implicitly refute that alternate interpretation. It immediately follows the discussion of cyclic percentages, and it says "For example, an <input> assigned width: calc(50% + 50px) has a min-content contribution of 50px".  This implies that the spec understands the 50% to be cyclic in that scenario, regardless of the containing block's size.  (Chrome agrees that the contribution is 50px in this example but IIUC that's only because input is on Chrome's special IsContentMinimumInlineSizeZero() list, not because it's judging the percentage to be cyclic...)

(Also, this interpretation doesn't explain what Blink is doing on my counterexample#2...  My best guess is that Blink is behaving like the percentage is no-longer cyclic when it gets to the point of resolving the automatic minimum size, since the containing-block has a resolved width at that point.  But then, it seems like the 5.2.1c spec-text about automatic minimum sizes would simply never take effect in the inline axis, which feels odd and inconsistent, particularly if there's another list of semi-replaced elements that behave another way.)

Alternate interpretation: maybe there's an argument to be made that my counterexample#1 doesn't have a cyclic percentage, since the containing block has a definite width.  (I'm not sure I buy that, since we're still asking the flex item for its min-content contribution, which is a measurement that's supposed to be independent of the surroundings, and hence feels like it becomes cyclic if it tries to resolve against the content block size.)  Under this alternate interpretation, https://github.com/w3c/csswg-drafts/issues/5665#issuecomment-797046688 would sort of explain my notes on Chrome's rendering of counterexample #1 .

Nonetheless: Example #4 in the css-sizing-3 spec (right after 5.2.1c) seems to implicitly refute that alternate interpretation. It immediately follows the discussion of cyclic percentages, and it says "For example, an <input> assigned width: calc(50% + 50px) has a min-content contribution of 50px".  This implies that the spec understands the 50% to be cyclic in that scenario, regardless of the containing block's styling.  (Chrome agrees that the contribution is 50px in this example but IIUC that's only because input is on Chrome's special IsContentMinimumInlineSizeZero() list, not because it's judging the percentage to be cyclic...)

(Also, this interpretation doesn't explain what Blink is doing on my counterexample#2...  My best guess is that Blink is behaving like the percentage is no-longer cyclic when it gets to the point of resolving the automatic minimum size, since the containing-block has a resolved width at that point.  But then, it seems like the 5.2.1c spec-text about automatic minimum sizes would simply never take effect in the inline axis, which feels odd and inconsistent, particularly if there's another list of semi-replaced elements that behave another way.)

Alternate interpretation: maybe there's an argument to be made that my counterexample#1 doesn't have a cyclic percentage, since the containing block has a definite width.  (I'm not sure I buy that, since we're still asking the flex item for its min-content contribution, which is a measurement that's supposed to be independent of the surroundings, and hence feels like it becomes cyclic if it tries to resolve against the content block size.)  Under this alternate interpretation, https://github.com/w3c/csswg-drafts/issues/5665#issuecomment-797046688 would sort of explain my notes on Chrome's rendering of counterexample #1 .

Nonetheless: Example #4 in the css-sizing-3 spec (right after 5.2.1c) seems to implicitly refute that alternate interpretation. It immediately follows the discussion of cyclic percentages, and it says "For example, an <input> assigned width: calc(50% + 50px) has a min-content contribution of 50px".  This implies that the spec understands the 50% to be cyclic in that scenario, regardless of the containing block's styling.  (Chrome agrees that the contribution is 50px in this example but IIUC that's only because `<input>` is on Chrome's special IsContentMinimumInlineSizeZero() list, not because Chrome is following 5.2.1c and judging the percentage to be cyclic...)

(Also, this interpretation doesn't explain what Blink is doing on my counterexample#2...  My best guess is that Blink is behaving like the percentage is no-longer cyclic when it gets to the point of resolving the automatic minimum size, since the containing-block has a resolved width at that point.  But then, it seems like the 5.2.1c spec-text about automatic minimum sizes would simply never take effect in the inline axis, which feels odd and inconsistent, particularly if there's another list of semi-replaced elements that behave another way.)