[css-sizing-3] Spec disagrees with reality on how min-content / max-content contribution is computed for elements w/ intrinsic aspect ratio & percent size in opposite dimension

[dholbert]

The current css-sizing-3 text disagrees with reality (interoperable browser behavior) about the min-content contribution of an element with an intrinsic aspect ratio and a percent size in the opposite dimension from the one we're determining contributions to.

The spec section in question: https://drafts.csswg.org/css-sizing-3/#intrinsic-contribution

Consider this testcase:
https://jsfiddle.net/5hx9kw4t/

<style>
.container {
  height: 50px;
  width: -moz-min-content;
  width: -webkit-min-content;
  width: min-content;
  border: 2px solid black;
}
canvas {
  background: pink;
  height: 100%;
}
</style>
<div class="container">
  <!-- This is just emulating a 400x400 image: -->
  <canvas width="400" height="400"></canvas>
</div>

Browsers all[1] agree on the sizing for .container here -- it's 50px wide (because we resolve the height:100% to 50px, and then we multiply that through the 1:1 aspect ratio to produce 50px width). But I don't think the current spec-text matches that reality.

The key question is, what's the <canvas>'s min-content contribution to its container?

• Browsers say it's 50px, as noted above.
• But the spec says it's "the size of the content box of a hypothetical auto-sized float that contains only that box, if that hypothetical float’s containing block is zero-sized." (And then there's some extra text about special cases where percentages resolve to 0, but it doesn't apply in this case since the percent is in the opposite axis of the one we're measuring.)

In this case, the spec's hypothetical float would look like this: https://jsfiddle.net/p0k263yv/
As you can see, this hypothetical float is 400px by 400px. So, css-sizing-3 thinks that the canvas should contribute a min-content width of 400px to its parent in the original testcase here, and that disagrees with reality.

So I think this spec text needs some tweaking to match reality. (Or am I misinterpreting it?)

[1] (Edge doesn't support any spelling of the 'min-content' keyword, so Edge renders the testcase differently from Chrome/Firefox - but you can verify that they agree if you make the container a float or inline-block instead.)

[fantasai]

The spec definitely means “auto-sized in the dimension that we're trying to find the size of”; sizing constraints in the other axis are expected to be transferred through, as they are for floats--that's entirely why we have this redirection through the CSS2.1 float-sizing algorithm (which isn't particularly well-defined, but to which these keywords are expected to correspond). See #794 for where we argued about this point. :) I'll mark Needs Edits so we can make the spec clearer.

[dholbert]

OK - so "auto-sized" and "zero-sized" both refer specifically to the dimension that we're trying to measure, and the hypothetical float's containing block is meant to have the same size as the measured-element's containing block in the other dimension. (or just be the same, modulo the zero-sizing in the measured direction)

Also, I think the hypothetical float needs to have {height|width}:100% in the not-being-measured dimension, in order for percent sizes on the element itself to resolve against the actual containing block size. Like this: https://jsfiddle.net/p9959s27/ If I don't include height:100% on the hypothetical float here, then the float & canvas each end up huge.

With all that, I think the spec matches reality & makes sense.

[fantasai]

OK, committed some changes. Have a look and let me know if that fixes it? :)

[dholbert]

EDIT: sorry, this comment here was focused on the wrong commit/github issue. I've cut-and-pasted this comment over to #2248 (comment)

[dholbert]

I think there's still one thing that needs clarifying. Right now the spec text says:

The max-content size of a box in each axis
is the size it would have if it were
a float given an ''auto'' size in that axis
and whose containing block was infinitely-sized in that axis.

Perhaps: s/and whose containing block was/and if its containing block were/ ?

The current language "if it were a float...whose containing block" sounds like it's referring to a hypothetical (maybe-different) containing block of the hypothetical float, so it's not clear whether there are any size constraints on this hypothetical containing block, in the not-being-measured axis. (And this matters for cases like my jsfiddle link above, when we've got an element with an aspect ratio and a percent size in the opposite axis and a fixed-height containing block.)

I'm hoping that my suggestion ("if it were a float...and if its containing block...") makes it clearer that we're still using the element's own containing block (with one size-tweak) for this hypothetical-float, rather than some other containing block. (Or: maybe you can think of another way of wording this which makes that clearer.)

[tabatkins]

Yeah, your new wording sounds good, so we adopted it. (With "was" used correctly :p)