[css-sizing][css-contain] Are intrinsic sizing keywords definite with size containment?

[Loirooriol]

https://andreubotella.com/csswg-auto-build/css-sizing-3/#definite

A size that can be determined without performing layout

So if I have something like

<div style="height: auto; contain: size; border: solid">
  <div style="height: 50%; background: cyan;">a</div>
</div>
<br><br>
<div style="height: auto; contain: size; contain-intrinsic-size: 100px; border: solid">
  <div style="height: 50%; background: cyan;">a</div>
</div>

Should the inner elements resolve 50% to 0px and 50px?

Browsers seem to treat the percentage as cyclic so it behaves as auto, i.e. they don't consider the parent's height: auto as definite. But we can determine the size without performing layout.

https://andreubotella.com/csswg-auto-build/css-contain-2/#sizing-as-if-empty

The used width and height of the containment box are determined as if performing a normal layout of the box, except that it is treated as having no content

Does this mean that no content is marked as having a cyclic percentage?

https://andreubotella.com/csswg-auto-build/css-contain-2/#laying-out-in-place

The containment box's content (including any pseudo-elements) must then be laid out into the now fixed-size containment box normally.

Does "fixed-size" mean that it's definite?

[frivoal]

My intuition would be that contain: size should indeed make the size definite, since as you said, it can be determined without layout. Do we want to go with that, or is there a reason to handle this as if there was a cyclic percentage, even though there isn't really a cycle?

[css-meeting-bot]

The CSS Working Group just discussed [css-sizing][css-contain] Are intrinsic sizing keywords definite with size containment?, and agreed to the following:

• RESOLVED: no change to specified behavior

The full IRC log of that discussion

<emeyer> Topic: [css-sizing][css-contain] Are intrinsic sizing keywords definite with size containment?
<emeyer> github: https://github.com//issues/7206
<emeyer> oriol: Normally, when we have an element with height: auto, if there’s a descendant that’s a percentage, it gets set to auto
<TabAtkins> q+
<emeyer> …In a case where a container has size containment and doesn’t depend on descendants, what should happen?
<emeyer> …Implementations treat this as cyclic
<emeyer> …auto height container should resolve to zero, and percentages of content should be zero
<emilio> q+
<emeyer> …if container is height: 100px, descendants at 50% are 50px
<emeyer> TabAtkins: We don’t currently treat a no-contents element being non-cyclic, so I don’t see how contain: size would change that
<emeyer> …I support what implementations are doing
<emeyer> oriol: If there are no content, can you tell whether the height is considered to be definite or not?
<emeyer> TabAtkins: Nothing we’ve written makes the assumption that that’s the case
<emeyer> TabAtkins: You have to perform layout to know the size, even if nothing is actually laid out
<Rossen_> ack TabAtkins
<Rossen_> ack emeyer
<Rossen_> ack emilio
<emeyer> emilio: I think I agree with Tab; it’s easy to back-compute on block axis, but in other places it might not be
<emeyer> …Complex cases tend not to be very interoperable
<emeyer> …It’s not obvious to me you can define the sizes of element without performing layout on the elements
<emeyer> …I’d rather not make this more complicated
<emeyer> Rossen_: Agreed.
<emilio> s/back-compute on block axis/back-compute the size on a block container
<emeyer> …proposed path forward is to resolve as no change; objections?
<emeyer> emilio: I would like the specifications clarified, even if it’s just a note or example
<emeyer> …I don’t thin kthe behavior we want to resolve on is clear form the current specification
<emeyer> …Adding something that clarifies that this case is still cyclic would be preferred
<emilio> +1 to clarify, do we define this block-axis back-computation of percentages properly somewhere?
<emilio> s/emilio:/oriol: :-)
<emeyer> Rossen_: Please add a comment on the issue with proposed addition text
<emeyer> RESOLVED: no change to specified behavior

[Loirooriol]

Maybe add a note in https://drafts.csswg.org/css-sizing-3/#indefinite along these lines:

Note: intrinsic sizing keywords such as max-content are indefinite, even if they can be determined without laying out the children e.g. due to size containment or lack of children.