W3C home > Mailing lists > Public > public-css-archive@w3.org > July 2021

Re: [csswg-drafts] [css-writing-modes-4][css-flexbox-1] Orthogonal column flex containers (#4221)

From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
Date: Thu, 29 Jul 2021 23:10:50 +0000
To: public-css-archive@w3.org
Message-ID: <issue_comment.created-889517695-1627600249-sysbot+gh@w3.org>
The CSS Working Group just discussed `Orthogonal column flex containers`, and agreed to the following:

* `RESOLUTION: Specify current behavior (clamp the orthogonal box, not propagate the clamping to block children)`

<details><summary>The full IRC log of that discussion</summary>
&lt;emilio> topic: Orthogonal column flex containers<br>
&lt;TabAtkins> quote from the issue: If you have a column flexbox that is orthogonal to its parent, and whose flex items are parallel (not orthogonal), per spec we pass the parent's infinite available block size to the flexbox's inline size, which then passes to the flex item, giving the flex item an infinite available inline size without the flex item itself being orthogonal.<br>
&lt;emilio> fantasai: so originally if you have a horizontal document with a section with vertical text, and that box is a block container, we apply this implicit height on it so that the line doesn't become super-high<br>
&lt;TabAtkins> &lt;!DOCTYPE html><br>
&lt;TabAtkins> &lt;div style="display: flex; writing-mode: vertical-rl; flex-flow: column; border: 40px double;"><br>
&lt;TabAtkins>  &lt;span>foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo &lt;/span><br>
&lt;TabAtkins>  &lt;span>foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo foo &lt;/span><br>
&lt;TabAtkins> <br>
&lt;TabAtkins> &lt;style><br>
&lt;TabAtkins> span { border: orange solid 40px;; }<br>
&lt;emilio> ... [ok, what TabAtkins just pasted :-)]<br>
&lt;emilio> fantasai: so in flex and grid you have a bunch of items so you don't really have this need to restrict the height of the flex container<br>
&lt;emilio> ... you could just allow it to get tall<br>
&lt;emilio> ... but it's kinda simple when you're setting up the orthogonal flow to apply the restriction without looking at whether its a block<br>
&lt;emilio> ... so the question is do we want to cap the height of the orthogonal box, or the height of orthogonal blocks?<br>
&lt;emilio> ... the other question is whether we do want to change behaviors if we choose the later<br>
&lt;emilio> TabAtkins: at least impls are interoperable on clamping flex containers<br>
&lt;emilio> ... the flex container gets the ICB clamping as is currently spec'd<br>
&lt;emilio> florian: I suspect there's no reason to change, the viewport size is an arbitrary measure<br>
&lt;emilio> ... if we have interop I don't see a huge motivation for changing<br>
&lt;emilio> TabAtkins: that was our thoughts as well<br>
&lt;emilio> ... we should probably spec the interop<br>
&lt;emilio> ... probably some small tweaks in flexbox+writing-modes<br>
&lt;emilio> fantasai: I think mostly writing-modes<br>
&lt;emilio> RESOLUTION: Specify current behavior (clamp the orthogonal box, not propagate the clamping to block children)<br>
&lt;emilio> fantasai: the most common situation where I'd expect this to show up is if you have a vertical-text table (because you can put more content)<br>
&lt;emilio> ... if you have a vertical-wm table in an horizontal document you prevent the table from growing<br>
&lt;emilio> florian: only when max-content > icb height, not min-content right?<br>
&lt;emilio> fantasai: right, is shrink-to-fit on the viewport<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/4221#issuecomment-889517695 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 29 July 2021 23:10:52 UTC

This archive was generated by hypermail 2.4.0 : Tuesday, 5 July 2022 06:42:39 UTC