[css-sizing-4] Allow specifying only one dimension for intrinsic sizing

[vmpstr]

We have a definition of contain-intrinsic-size which specifies both width and height dimensions of the intrinsic size.

For a case of vertical scrolling, we found that it is a common desire to have the width of an element be as wide as the scroller and the height be dictated by contain-intrinsic-size. This is particularly useful with content-visibility: auto which puts in size containment when the elements scroll off screen.

We've been recommending things like contain-intrinsic-size: 1px 400px; where 400px is the desired height, but it's a bit awkward. It would be nicer and more ergonomic to be able to specify just the height of the intrinsic size.

Is it possible for us to make the contain-intrinsic-size a shorthand for contain-intrinsic-width and contain-intrinsic-height (and possibly block-size and inline-size?) with auto | <length> or something similar

That way, developers would have an option of specifying just one of the two dimensions

/cc @tabatkins @chrishtr

[vmpstr]

To clarify, for block containers:

contain-intrinsic-height: 500px;

would be equivalent to

contain-intrinsic-size: 0 500px; (unless of course there is a contain-intrinsic-width specified).

[chrishtr]

/cc @vincentriemer

[vincentriemer]

I like the idea of having longhand properties, but it does bring up the question of how this works in relation to logical properties.

While I don't see it in the spec, contain-intrinsic-size could theoretically map to block-size and inline-size without changing its name but with the shorthand properties there'd have to be both width/height and inline-size/block-size variants.

[vmpstr]

I think the spec talks about physical dimensions (width / height) as being the two components of contain-intrinsic-size. At the very least it would have to specify one or the other, so that different implementations can agree.

But you bring up a valid point that if this becomes a shorthand, then we really would want 4 new properties: 2 for physical dimensions and 2 for logical dimensions.

[css-meeting-bot]

The CSS Working Group just discussed [css-sizing-4] Allow specifying only one dimension for intrinsic sizing, and agreed to the following:

• RESOLVED: Property takes 4 longhands, logical and physical, which have a normal value

The full IRC log of that discussion

<dael> Topic: [css-sizing-4] Allow specifying only one dimension for intrinsic sizing
<dael> github: https://github.com//issues/5432
<dael> vmpstr: Added contain-intrinsic-size property. Takes 2 values. Can take 1 to apply to width and height. Got feedback it can be confusing if dev only wants to spec in 1 direction
<dael> vmpstr: Proposal is to make c-i-s be a shorthand for additional values like c-i-with and c-i-height
<dael> florian: Which would have normal value
<dael> vmpstr: Yes. ANd b/c only during size containment it falls back to what hte size would be
<dael> vmpstr: Other is do we add width, height, and block sizes
<dael> florian: I'd go logical only. Or maybe all 4
<dael> vmpstr: Don't have preference. Feel like fewer is better
<dael> florian: I wouldn't do pshycial only
<dael> fantasai: Reason why physical is to be consistent with size property we end up having. Main reason we dont' have size property is naming conflict.
<Rossen_> q?
<dael> fantasai: Anticipation is size would be physical. That's why ended up making physical
<dael> florian: Sure. It's a mess so let's stick with the mess. Concept is reasonable and easy
<dael> vmpstr: Logical, physical or all
<dael> florian: I think what fantasai said overrides. We're in physical land
<dael> vmpstr: Both?
<dael> Rossen_: I think both
<dael> fantasai: There's a size property with all. If we have c-i-s with a longhand it should presumably have all
<dael> vmpstr: Makes sense. That's the proposal
<dael> heycam: Confused from comment in issue if you say c-i-s 500px shouldn't it be like none
<dael> vmpstr: Only takes effect during size containment
<dael> florian: I think it should be normal or none. Intrinsic size can be non-0.
<dael> vmpstr: I was giving when it would be 0. Should be defautl intrinisic width with a specified intrinsic height
<dael> florian: I'd go with normal. None seems to override. Normal seems to be do whatever you'd do if we didn't spec this
<dael> heycam: Is there a distinction where you might want to say there is no intrinsic size?
<dael> florian: If you want none you can say 0
<dael> heycam: But is that different?
<dael> fantasai: I think if there's overflow scroll it's different.
<dael> florian: I think we can resolve on normal and come back to if there's a use case for none
<dael> heycam: Sounds good
<dael> Rossen_: Sounds like we've arrived at resolution. heycam are you happy now?
<dael> heycam: okay
<dael> florian: Prop: Property takes 4 longhands, logical and physical, which have a normal value
<dael> Rossen_: Objections?
<dael> RESOLVED: Property takes 4 longhands, logical and physical, which have a normal value