[css-contain-3] "container width" and "container height" units

[una]

Viewport-relative units (such as vh and vw) are commonly used among UI design for sizing and spacing of elements.

With the new container queries spec, authors will want to use such units as container-height (ch) and container-width (cw) for container-based sizing.

An example is using cw units in srcset similarly to how one would use vw units in srcset. Percentages would not work in that instance, as the value needs to be absolute or relative length.

Edit: ch would not work as a unit name due to the existing ch (character) unit

[dbaron]

The ch unit already exists with a different meaning (short for "character"), so this will at least need a different name.

[jimmyfrasche]

ew and eh

[nigelmegitt]

rw and rh would match the identically named <length> units in TTML2, in the case that the container is the root container region, which makes sense e.g. for playing captions over a video container, where it is normal to render text at a height proportional the height of the video.

[una]

@nigelmegitt I like the idea of using "root" in the name here. Potentially also "root container width" (rcw) and "root container height" (rch) to specify container from root. I also like rw and rh

[chrishtr]

@mirisuzanne

[mirisuzanne]

Yeah, I'm totally in favor of this, and think it would be very useful. My understanding was that container-relative units would have an additional performance cost with every use, making them likely too expensive. I would love to find out that I mis-understood.

There has been some previous discussion of this in other container query threads.

[lilles]

Container units would be as costly as vh/vw for @media query changes, I suppose. Blink marks computed styles for an element with a flag saying that it relies on viewport units and such elements have styles recomputed when the viewport size changes. Same should work for container units/queries.

[fantasai]

Note, we use 'r' as a prefix currently for the root element e.g. in rem and rlh so probably should avoid that as a prefix here.

[css-meeting-bot]

The CSS Working Group just discussed [css-conditional] [css-contain] "container width" and "container height" units.

The full IRC log of that discussion

<astearns> topic: [css-conditional] [css-contain] "container width" and "container height" units
<astearns> github: https://github.com//issues/5888
<dlibby> una: this issue is regarding a new sizing unit
<dlibby> una: one for container width and one for height, how inline vs. block is used
<dlibby> una: could be something useful for ui designed, similar to vw/vh
<dlibby> una: could be related to srcset based on container width, probably want different images based on container size
<florian> q+
<emilio> q+
<jensimmo_> A big +1 from me for CW and CH. Or even just a unit in the inline direction if that's only what's possible. Such a thing will be very useful.
<dlibby> una: would like to get consensus on whether this concept (container-sized units) makes sense
<dlibby> astearns: clarify - these units would key off of container size we discussed before?
<astearns> ack florian
<dlibby> una: yes, could use for widths or similar to other viewport unit usage
<fremy> q?
<dlibby> florian: viewport units are useful, this sounds useful too. perhaps we already have this via percentage
<dlibby> florian: if this is direct parent, then % gives you this - examples where this is not true?
<bkardell_> % doesn't work if it isn't your parent tho
<dlibby> leaverou: font-size is one example
<dlibby> florian: realize there are cases where it doesn't work, but are those real use cases
<astearns> ack emilio
<iank_> re: only your direct parent -> except in quirks mode :P
<dlibby> emilio: this would resolve at computed value time?
<dlibby> una: yes
<dlibby> emilio: the thing with srcset is that it might not quite work - how do they evaluate in media queries?
<dlibby> emilio: assume these would resolve against viewport size. don't want to wait until layout to start loading images, since it's a bit circular
<dlibby> astearns: (this is the next issue)
<leaverou> +1 for adding these units, if they are implementable
<dlibby> emilio: sounds workable as long as we have a strong definition of what a container is
<jensimmo_> q?
<leaverou> perhaps cnw and cnh for names? (since ch is taken)
<dlibby> astearns: other comments/concerns?
<fremy> also +1 from me
<dlibby> jensimmons: big +1, when teaching viewport units people like them but not quite what they want
<dlibby> jensimmons: could really be useful for font-sizing
<dlibby> jensimmons: percent could work for margins, but this seems like something people will get excited for
<dlibby> jensimmons: if we only get inline direction, maybe a minor limitation, but better than today
<dlibby> astearns: could see vw convert to this quickly
<jensimmo_> border thickness is another thing that cannot be done with %
<dlibby> astearns: see enthusiasm and support - resolve to pursue container units along with container queries?
<dlibby> florian: we know we can have 2d containment, we suspect 1d, not sure on block - should this influence which units we want to expose?
<leaverou> also is the container width unit essentially a container inline unit? Does it change with writing mode?
<leaverou> (if so the unit could just be ci and cb)
<fantasai> leaverou, I think we should pick a prefix that can be expanded in the future, so probably a 2-letter prefix
<dlibby> astearns: not quite sure followed previous discussion, though we were going to have a draft with 2d and everything, see what we can get
<leaverou> fantasai: fair point
<dlibby> florian: i think we can do 2d and inline, but not sure if we can do block
<dlibby> florian: or we won't do block yet, at least
<dlibby> iank: highly unlikely to be able to do block only
<dlibby> iank: would like to make sure we have use cases for block direction
<astearns> ack fantasai
<dlibby> jensimmons: border could be interesting. could set it 1/10th of inline, 1/10 of block on rectangular box
<dlibby> fantasai: if we add block or things that may or may not exist need to define if they don't
<dlibby> fantasai: also should have a consistent prefix, 'c' and 'r' are problematic currently
<dlibby> fantasai: pick one we're unlikely to use or use a two letter combo
<dlibby> una: rch sound good
<dlibby> fantasai: we have to be careful as existing letters at the beginning won't work
<dlibby> una: let's bikeshed in the issue
<fantasai> r is particularly problematic since we're using it as a prefix for root
<dlibby> jensimmons: liked leaverou's thought of only allowing inline/block instead of height width
<dlibby> una: i'd like to keep symmetry of vw/vh to this proposal
<dlibby> una: but do like inline/block
<dlibby> fantasai: viewport units have logical units already
<fantasai> (vi and vb)
<dlibby> astearns: let's bikeshed in the issue, get examples of what the CSS really looks like
<dlibby> astearns: any objections to adding units, name tbd
<dholbert> it's also worth thinking / defining what happens when the item & the container have orthogonal writing modes

[astearns]

I got ahead of the bot:

Also should consider 4 names for height/width and inline/block
RESOLVED: add new units to express container dimensions