Yes. It says “percentages resolve to zero”, not “expressions involving percentages resolve to zero”. :)

I'm not sure the spec needs any fixing here, would you mind if I just close this invalid?

Here's the corresponding example in block layout:

<style>
span { display:inline-block; width:50px; height:10px; background:lime }
</style>
<div style="display:inline-block; border:1px solid;">
  <span style="margin-right:calc(10px + 20%)"></span><span></span>
</div>

In Chome - the width of the <div> is 100px and the right margin for the <span> is 30px, i.e. (10px + 0.2*100px). What you're suggesting is that the width should be 110px and the margin should be 10px + 0.2*110px. So are you saying that the block's intrinsic size here is wrong in Chrome?

(Firefox is still back-computing percentages in these cases, but we're removing that to comply with the recent CSSWG resolution.)

BTW, Edge and Safari have the same output than Chrome for the example above. The <div> has a width of 100px.

Well, if I change the above example to use padding instead of margin, like so:

<style>
span { display:inline-block; width:50px; height:10px; background:lime }
</style>
<div style="display:inline-block; border:1px solid;">
  <span style="padding-right:calc(10px + 20%)"></span><span></span>
</div>

then the <div> has a width of 110px in Chrome (and the padding ends up being 32px).
It seems weird to me that padding and margin percentages are resolved differently.

From the author's side, I would definitely expect calc(10px + 20%) to always equal at least 10px, for margin or padding or anything else.

I also would very much prefer that contents inside a shrink-to-fit container don't end up adding extra spacing after the container has been fit, unless the percentages sum up to greater than 100%.

Based on those objectives, I see two acceptable approaches. Either:

• calculate the container width using an algebra equation:

  • 100%*width = ∑(fixed widths) + ∑(percentage widths)*width
  • (100% - ∑(percentage widths) ) * width = ∑(fixed widths)
  • width = ∑(fixed widths) / (100% - ∑(percentage widths) )
  • AKA, for Mats' example, the width would be 110px/80% = 137.5px

• Or, treat the reference for percentage widths as 0, calculate out the rest of the expression, and stick with it even after the container width is resolved. Less ideal, but simpler.

That said, the consistent behavior for all browsers I've tested for

• width defined as a percentage + absolute length in shrink-to-fit containers is to treat the entire calc expression as zero when determining the parent container's width, but then evaluate the calc for the children normally after the parent width is set (so the child elements now overflow the too-small parent).

• height defined as a percentage + absolute length in contexts where percentage height isn't defined (because of a fit-to-contents auto-height parent container) is to treat the entire calc expression as unresolvable, setting the height to auto.

I'm not sure where/if either of those behaviors are defined (CSS sizing says to refer to the individual layout modules for how to resolve percentages, and doesn't mention calc).

If height and width were consistent with each other, I'd argue that padding & margin should match the same behavior, too. But they aren't. They're a mess. So I refer again to my suggested solutions above, and wonder if there would be any compat issue with making width in a shrink-to-fit container behave similarly. (The algebra isn't that complicated, really…)

This is related to #1132, as mentioned in today's telecon.

(I've filed a Chromium bug about calc() margins here)

Agenda+ to discuss zeroing out the percentage vs. zeroing out the entire expression, for margins/padding/gaps. The argument in favor of zeroing out the entire expression is that this is what seems to be implemented; the argument in favor of zeroing out the percentage is that it is more meaningful. (For the sizing properties (#1132), we fall back the entire expression to the initial value, but in that case the initial value is meaningful: it contributes the size of the content, which is usually a more important factor in sizing than the non-percentage parts of a calc expression. For margins and padding, however, the initial value is zero: zeroing out the percentage and scavenging the rest of the expression would be more meaningful.)

The Working Group just discussed calc() with percentages in margins/padding, and agreed to the following resolutions:

• RESOLVED: zero out percentages on non-sizing use of calc

OK, we've got edits in for zeroing out percentages in both margins/padding (in Sizing) and for gaps (in Alignment). Please re-open if the text is insufficiently clear, but otherwise I think we're closed out here.