- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Fri, 12 Feb 2021 00:26:30 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-conditional] [css-contain] "container width" and "container height" units`. <details><summary>The full IRC log of that discussion</summary> <astearns> topic: [css-conditional] [css-contain] "container width" and "container height" units<br> <astearns> github: https://github.com/w3c/csswg-drafts/issues/5888<br> <dlibby> una: this issue is regarding a new sizing unit<br> <dlibby> una: one for container width and one for height, how inline vs. block is used<br> <dlibby> una: could be something useful for ui designed, similar to vw/vh<br> <dlibby> una: could be related to srcset based on container width, probably want different images based on container size<br> <florian> q+<br> <emilio> q+<br> <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.<br> <dlibby> una: would like to get consensus on whether this concept (container-sized units) makes sense<br> <dlibby> astearns: clarify - these units would key off of container size we discussed before?<br> <astearns> ack florian<br> <dlibby> una: yes, could use for widths or similar to other viewport unit usage<br> <fremy> q?<br> <dlibby> florian: viewport units are useful, this sounds useful too. perhaps we already have this via percentage<br> <dlibby> florian: if this is direct parent, then % gives you this - examples where this is not true?<br> <bkardell_> % doesn't work if it isn't your parent tho<br> <dlibby> leaverou: font-size is one example<br> <dlibby> florian: realize there are cases where it doesn't work, but are those real use cases<br> <astearns> ack emilio<br> <iank_> re: only your direct parent -> except in quirks mode :P<br> <dlibby> emilio: this would resolve at computed value time?<br> <dlibby> una: yes<br> <dlibby> emilio: the thing with srcset is that it might not quite work - how do they evaluate in media queries?<br> <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<br> <dlibby> astearns: (this is the next issue)<br> <leaverou> +1 for adding these units, if they are implementable<br> <dlibby> emilio: sounds workable as long as we have a strong definition of what a container is<br> <jensimmo_> q?<br> <leaverou> perhaps cnw and cnh for names? (since ch is taken)<br> <dlibby> astearns: other comments/concerns?<br> <fremy> also +1 from me<br> <dlibby> jensimmons: big +1, when teaching viewport units people like them but not quite what they want<br> <dlibby> jensimmons: could really be useful for font-sizing<br> <dlibby> jensimmons: percent could work for margins, but this seems like something people will get excited for<br> <dlibby> jensimmons: if we only get inline direction, maybe a minor limitation, but better than today<br> <dlibby> astearns: could see vw convert to this quickly<br> <jensimmo_> border thickness is another thing that cannot be done with %<br> <dlibby> astearns: see enthusiasm and support - resolve to pursue container units along with container queries?<br> <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?<br> <leaverou> also is the container width unit essentially a container inline unit? Does it change with writing mode?<br> <leaverou> (if so the unit could just be ci and cb)<br> <fantasai> leaverou, I think we should pick a prefix that can be expanded in the future, so probably a 2-letter prefix<br> <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<br> <leaverou> fantasai: fair point<br> <dlibby> florian: i think we can do 2d and inline, but not sure if we can do block<br> <dlibby> florian: or we won't do block yet, at least<br> <dlibby> iank: highly unlikely to be able to do block only<br> <dlibby> iank: would like to make sure we have use cases for block direction<br> <astearns> ack fantasai<br> <dlibby> jensimmons: border could be interesting. could set it 1/10th of inline, 1/10 of block on rectangular box<br> <dlibby> fantasai: if we add block or things that may or may not exist need to define if they don't<br> <dlibby> fantasai: also should have a consistent prefix, 'c' and 'r' are problematic currently<br> <dlibby> fantasai: pick one we're unlikely to use or use a two letter combo<br> <dlibby> una: rch sound good<br> <dlibby> fantasai: we have to be careful as existing letters at the beginning won't work<br> <dlibby> una: let's bikeshed in the issue<br> <fantasai> r is particularly problematic since we're using it as a prefix for root<br> <dlibby> jensimmons: liked leaverou's thought of only allowing inline/block instead of height width<br> <dlibby> una: i'd like to keep symmetry of vw/vh to this proposal<br> <dlibby> una: but do like inline/block<br> <dlibby> fantasai: viewport units have logical units already<br> <fantasai> (vi and vb)<br> <dlibby> astearns: let's bikeshed in the issue, get examples of what the CSS really looks like<br> <dlibby> astearns: any objections to adding units, name tbd<br> <dholbert> it's also worth thinking / defining what happens when the item & the container have orthogonal writing modes<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/5888#issuecomment-777886125 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 12 February 2021 00:26:32 UTC