Created attachment 164250 [details] Testcase When a vertical-lr block with height:auto contains a horizontal-tb child, it's computed height ends up being just the height of its child's borders, ignoring the actual content of the child. This seems pretty broken. My reading of http://dev.w3.org/csswg/css3-writing-modes/#orthogonal-flows and http://dev.w3.org/csswg/css3-writing-modes/#orthogonal-auto is that: - max-content is the height of .inner (the green box)* - min-content is the height of .inner (the green box)* - fill-available is infinite since the height of the body is auto, so is ignored - fill-fallback is the height of the initial containing block Hence contentHeight of .outer = min(max-content, max(min-content, fill-fallback)) = height of .inner (the green box) [including .inner's borders and padding]. *: Though it's not clear how orthogonal writing mode interacts with the definitions of min-content and max-content (http://dev.w3.org/csswg/css3-writing-modes/#min-content), where min-content supposes that "all line break opportunities within the box were taken" and max-content supposes that "none of the optional line break opportunities within the box were taken"; indeed that seems somewhat backwards in this situation.
Possibly related to bug 47238?
(In reply to comment #1) > Possibly related to bug 47238? Yes, that's the issue. We have no way of knowing how to compute min-content and max-content when they depend on a child's extent. As far as I can tell, no spec really indicates what to do yet.
Updating the test case to remove -webkit-: JSFiddle - https://jsfiddle.net/ex75nhp2/show Safari 16.3, STP163, WebKit ToT (260442@main) matches Firefox Nightly 112 while Chrome Canary 112 matches "Expected" rendering. Just wanted to share updated testing results. Thanks!