[css-sizing] Should `contain-intrinsic-*: from-element` require `contain:size`?

[kojiishi]

The from-element keyword is for "Auto-resize iframes based on content" #1771 based on the resolution in 2021.

When it applies only to <iframe>, which has little with contain:size, should it require contain:size to be effective?

/cc @tabatkins @chrishtr @bfgeek

[Loirooriol]

If anything, isn't from-element kinda bypassing size containment? Should it maybe require the opposite, that there isn't size containment? But then contain-intrinsic-* is probably not the right place for this

[kojiishi]

Logically speaking, there are 4 options:

1. contain-intrinsic-block-size: from-element requires contain: size.
2. contain-intrinsic-block-size: from-element doesn't require contain: size.
3. contain-intrinsic-block-size: from-element requires not contain: size.
4. Make it a separate, new CSS property. It will then need to define the relationship with contain-intrinsic-block-size; i.e., which should win when both are specified.

I don't have a strong preference.

[Loirooriol]

I think it should be 4, and require not having size containment. Depending on the subresource seems antithetic to the nature of size containment.

[kojiishi]

I think it should be 4, and require not having size containment. Depending on the subresource seems antithetic to the nature of size containment.

Thanks for the reply. Do you have opinions on which should win? For example:

iframe.responsive {
  contain: size;
  contain-intrinsic-block-size: 300px;
  new-property-for-responsive-iframe: 400px;
}

Should the intrinsic block size be 300px, or from-element (with default 400px)?

[kojiishi]

Oops, sorry, I missed you wrote "require not having size containment". Using the size containment as the switch works for me.

So the proposal is:

1. The syntax of the property should be: none | <length [0,∞]>.
2. If not contain: size, and if the new property is not none:
   2.1. If the internal layout intrinsic size is known, use it, otherwise the specified <length [0,∞]>.

[Loirooriol]

To explain my opposition to size containment in more detail:

• contain-intrinsic-size only applies to elements with size containment, as implied by the name. I think it would be very confusing to add an exception for this.

• It can seem fine, then, to require the author to use an explicit contain: size, or maybe the UA could trigger size containment automatically on iframes.

• However, when an element has size containment, changes in the descendant elements (if non-replaced) or loaded resource (if replaced) should not affect its intrinsic size, otherwise this optimization wouldn't be possible:

  When the style or contents of a descendant of the containment box is changed, calculating what part of the DOM tree is "dirtied" and might need to be re-laid out can stop at the containment box.

• I guess the spec already tries to address this in https://drafts.csswg.org/css-sizing-4/#internal-layout-intrinsic-size

  When an iframe’s internal document is loaded, if the required meta element is present at the time of the DOMContentLoaded and load events, the iframe’s internal layout intrinsic size’s height is set to the natural height of the embedded document. Subsequent changes to content, styling or layout of the embedded document do not affect the internal layout intrinsic size.

  However,

  • What happens if the iframe navigates to a different embedded document? Can the internal layout intrinsic size survive that? I don't think authors will expect it to survive, but if it changes, then that defeats size containment.
  • What happens while the iframe is loading and the internal layout intrinsic size has not been set yet? Again, if when the internal layout intrinsic size is finally set, this affects the intrinsic size of the iframe, then that defeats size containment.

So I think it's better to use a different property.

About the proposal above I'm not sure if it's very clear that <length [0,∞]> is just a fallback. Another idea could be

iframe-intrinsic-height: auto? <length [0,∞]>

where a length alone just sets the intrinsic height to that amount (the initial value would be 150px). And auto means that we want to take the intrinsic size from the contents, with the length just being the fallback (somewhat analogous to aspect-ratio: auto <ratio>).

I'm also wondering if this will always be a height, or a block size, or what happens when the subdocument is orthogonal, etc.

[kojiishi]

iframe-intrinsic-height: auto? <length [0,∞]>

Requiring auto works fine for me.

I'm also wondering if this will always be a height, or a block size, or what happens when the subdocument is orthogonal, etc.

It should be a block size for the parent document, to prevent leaking writing-mode of the embedded documents.

[kojiishi]

/cc @emilio

[Loirooriol]

OK, if it's iframe-intrinsic-block-size then we can't say that the initial value is 150px, because it needs to be 300px in vertical wm. So that would need another keyword.

Alternatively, why only do this for the block size? It seems to me we could do it in both axes. That wouldn't leak more information of the embedded document, because even with only iframe-intrinsic-block-size, the parent document could load the same URL in 2 different iframes with different writing modes.