Repository navigation
[css-sizing-4] Allow specifying only one dimension for intrinsic sizing #5432
Description
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
Activity
vmpstr commentedon Aug 14, 2020
To clarify, for block containers:
contain-intrinsic-height: 500px;would be equivalent to
contain-intrinsic-size: 0 500px;(unless of course there is acontain-intrinsic-widthspecified).chrishtr commentedon Aug 14, 2020
/cc @vincentriemer
vincentriemer commentedon Aug 14, 2020
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-sizecould theoretically map toblock-sizeandinline-sizewithout changing its name but with the shorthand properties there'd have to be bothwidth/heightandinline-size/block-sizevariants.vmpstr commentedon Aug 18, 2020
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 commentedon Dec 3, 2020
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 valueThe 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
[css-sizing-4] Define the contain-intrinsic-* longhands. #5432