[css-writing-modes-4] Apply ICB clamping on the orthogonal flow, not the closest block container descendant, matching implementations. #4221

fantasai · fantasai · commit de44f988b329 · 2021-08-10T17:04:50.000-07:00
diff --git a/css-writing-modes-4/Overview.bs b/css-writing-modes-4/Overview.bs
@@ -2253,28 +2253,40 @@ Auto-sizing Block Containers in Orthogonal Flows</h4>
 Auto-sizing Other Orthogonal Flow Roots</h4>
 
   <p>In order to limit the length of lines,
-  block containers have special auto-sizing behavior (defined <a href="#auto-multicol">above</a>)
+  block containers have special auto-sizing behavior
+  that triggers [=multi-column layout=]
   when their <a>available inline space</a> is infinite
   (which typically occurs when they establish an <a>orthogonal flow</a>).
 
-  <p>Other layout models simply lay out into the infinite <a>available inline space</a>
-  at their <a>max-content size</a>.
-  However, they pass through the infinite <a>available inline space</a>
-  to block containers they contain,
-  possibly triggering that special auto-sizing behavior on those block containers
-  even though they do not themselves establish an <a>orthogonal flow</a>.
+  <p>For calculating the [=automatic inline size=] for other [=display types=]
+  when the available inline space is infinite,
+  if the box is [=block level=]
+  or the formatting context otherwise calculates
+  an [=automatic inline size=] using its [=max-content=] size,
+  use the same formula used for the [=block containers’=] 'column-width'
+  (see <a href="#auto-multicol">above</a>)
+  in place of that [=max-content size=]:
+  <code>min(<var>max-content</var>, max(<var>min-content</var>, <var>constraint</var>))</code>.
 
   <div class="example">
     <p>For example,
-      a table or <a>flex container</a> establishing an <a>orthogonal flow</a>
-      is laid out into its given <a>available space</a>.
-      If its <a>available inline space</a> is infinite,
-      this effectively lays the box out at its <a>max-content size</a>.
-      However, any of its table cells or <a>flex items</a> that are <a>block containers</a>
-      are laid out assuming infinite <a>available inline space</a>
-      and so behave accordingly.
+    a table or <a>flex container</a> establishing an <a>orthogonal flow</a>
+    is laid out into its given <a>available space</a>.
+    However, if its <a>available inline space</a> is infinite
+    (as it when placed into a [=block formatting context=]),
+    then assuming no intervening [=scroll container=],
+    this effectively lays the box out at its <a>max-content size</a>,
+    clamped by the [=initial containing block=]’s size,
+    ensuring that its [=inline size=] still fits within the viewport or page area.
   </div>
 
+  Note: If the [=automatic inline size=] is a [=fit-content=] size
+  (for example, in a [=grid item=])
+  this can apply multiple maximum constraints on the [=max-content=] size.
+
+  Note: <strong>This can result in T-shaped documents</strong>
+  if the orthogonal content is too long to fit within its containing block.
+
 <h4 id="orthogonal-pagination">
 Fragmenting Orthogonal Flows</h4>
 
@@ -2812,6 +2824,12 @@ Changes since the <a href="https://www.w3.org/TR/2019/CR-css-writing-modes-4-201
 2019 CSS Writing Modes Module Level 4 Candidate Recommendation</a></h3>
 
   <ul>
+    <li>Changed the automatic sizing of orthogonal flows that are not [=block containers=]
+      to apply the [=initial containing block=] size as a constraint on the flow itself
+      like [=block containers=] do,
+      rather than passing through an infinite available size
+      to be clamped by descendant [=block containers=].
+      (<a href="https://github.com/w3c/csswg-drafts/issues/4221">Issue 4221</a>)
     <li>Specified that a ''display: none'' <{body}> element does not influence the [=principal writing mode=].
       (<a href="https://github.com/w3c/csswg-drafts/issues/3779">Issue 3779</a>)
     <li>Updated “Applies to” line for 'text-combine-upright' to mention text
