Bug 96841 – Vertical writing mode block ignores horizontal children when calculating height

• Component: Layout and Rendering
• Status: NEW

[John Mellor]

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.

[John Mellor]

Possibly related to bug 47238?

[Dave Hyatt]

(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.

[Ahmad Saleem]

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!