We rewrote the entire section, because even we found it pretty inscrutable! It's definitely still under review and open to edits, so please let us know what you find bad or wrong.

The text implies that max-height can affect percentage resolution of the height (if it is something like min-content), but does not specifically say so

It should now be much clearer that it does do so.

It seems to imply also that min-content will never prevent percentage resolution of children, but I am not sure that my reading is correct and would appreciate clarification

Did you mean 'min-width/height' here? If so, then yes, it never prevents resolution of child percentages, if they could resolve otherwise (ignoring the min-size property). This should also be much clearer now.

(Flexbox and Grid explicitly say that "min-*: auto" doesn't prevent percentage resolution; it doesn't seem any more difficult to apply that to all the intrinsic keywords, we think. Please let us know if we're wrong!)

It would be nice to clarify that while max-content can prevent percentage resolution of children/descendants, it never affects the value the percentage gets resolved against (that value is always the specified height). OR, if I misunderstood, it would be good to explicitly say so.

Again, assuming you mean 'max-width/height'. 'max-height' can indeed prevent percentage resolution. As currently written, 'max-width' does not, and it does affect what size the percentage resolves against. Should either of these be different?

Thanks, this is much better. It addresses my previous comments. But I think the rewrite does not address the case where the percentage in question is specified for a min- or max-size property. For example:
"When calculating the containing block’s size, the percentage behaves as auto."
auto is not valid for max and is probably not the intention for min, here.

As a sidenote:
"Similarly, percentage margins and padding behave as zero in such cyclic cases when calculating the containing block’s size"
I believe this is incompatible with Gecko's current implementation (from memory -- I did not retest)

OK, so, afaict: width/min-width/max-width values containing a percentage are treated as the property's initial value for the purpose of calculating the min/max-size contributions. Afterwards, they resolve. E.g. in width (or min/max-width): calc(300px + 40%) we ignore the 300px as well as the percentage while calculating its size contribution.

This needs edits and testcases.

(Wrt sidenote, IIRC Gecko agreed to change their behavior. See #347.)

OK, submitted WPT tests in web-platform-tests/wpt#9418 for this issue. We still need a WG resolution to add prose for this, and also, I'd really like someone to look this all over because I'm not 100% confident I'm triggering the right cases / understanding the results correctly. :(

Proposed edits would be, append to the first paragraph of https://drafts.csswg.org/css-sizing-3/#intrinsic-contribution

If the box is non-replaced, then the value of any sizing property specified on it as an expression containing a percentage is treated for the purpose of calculating the box’s intrinsic size contribution only as that property’s initial value. For example, given a box with ''width: calc(20px + 50%)'', its max-content contribution is calculated as if its 'width' were ''width/auto''. The percentage is honored as usual, however, during the actual sizing of the box itself.

Suggestions on wording improvement welcome...

Note: Testcases can be run live here: https://lists.w3.org/Archives/Public/www-archive/2018Feb/0000.html

The Working Group just discussed Percentage sizing section is kind of vague.

I think the text is reasonable, but I think assuming that browsers implemented the same thing for all properties is being a bit too hopeful here.

web-platform-tests/wpt#9418 (comment) points out that there is no interop for margin at least, and that no browser follows the current spec. I am not sure it's worth changing the spec text just for that case, but we might want to add a test for that and file bugs, and maybe ask people to review that particular test in particular.

We might also start wondering about other similar uses like flex-basis or grid-gap, etc... It would be nice to have a test case for all of them to see if we have interop on them

@FremyCompany Margin is not a sizing property. https://drafts.csswg.org/css-sizing-3/#sizing-property

@fantasai The text definitely looks fine then.

However, we still need some text to explain the behavior of padding/margin/flex-basis and other properties, right? If yes, I would be fine reusing the same logic if we have rough interop (or, like in the margin case, no interop at all anyway).

One thing that's ambiguous in the text is whether "containing a percentage" means syntactically containing a percentage or mathematically containing a percentage -- that is, whether expressions like calc(50px + 0%) contain a percentage. In Gecko I think they do, although I'm not 100% sure.

I'd also note that the proposed text doesn't match Gecko behavior for margins and padding, where we currently account for percentages in a way that's not quite correct but pretty close, and the obvious change to stop doing that would causes us to treat only the percentage component of a calc() as 0. So please do test that this matches the behavior of other implementations for margin and padding (i.e., that they don't use the non-percent components). If that's not the case, then we likely need different behavior for width/height (and min-* and max-*) versus margin/padding.

OK, based on @fantasai's comments in the telecon, sizing property needs to be hyperlinked to the definition; I wasn't aware it was a term.

The Working Group just discussed [css-sizing] Percentage sizing section is kind of vague, and agreed to the following resolutions:

• RESOLVED: Accept the edit in https://github.com/w3c/csswg-drafts/issues/1132#issuecomment-363623845 with a clarification and a hyperlinked term.