96841 2012-09-14 16:51:22 -0700 Vertical writing mode block ignores horizontal children when calculating height 2023-02-17 07:29:26 -0800 1 1 1 Unclassified WebKit Layout and Rendering 528+ (Nightly build) Unspecified Unspecified NEW P2 Normal --- 46123 96557 1 johnme webkit-unassigned ahmad.saleem792 hyatt jchaffraix karlcow mitz tony oldest_to_newest 721252 0 164250 johnme 2012-09-14 16:51:22 -0700 Created attachment 164250 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. 721253 1 johnme 2012-09-14 16:53:04 -0700 Possibly related to bug 47238? 850510 2 hyatt 2013-03-07 15:02:49 -0800 (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. 1934618 3 ahmad.saleem792 2023-02-17 07:29:17 -0800 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! 164250 2012-09-14 16:51:22 -0700 2012-09-14 16:51:22 -0700 Testcase vert-containing-horiz.html text/html 550 johnme PCFET0NUWVBFIGh0bWw+CjxodG1sPgo8aGVhZD4KCjxzdHlsZT4KLm91dGVyIHsKICAgIGJvcmRl cjogNXB4IHNvbGlkIHJlZDsKfQouaW5uZXIgewogICAgYm9yZGVyOiA1cHggc29saWQgZ3JlZW47 Cn0KCi52IHsKICAgIC13ZWJraXQtd3JpdGluZy1tb2RlOiB2ZXJ0aWNhbC1scjsKfQouaCB7CiAg ICAtd2Via2l0LXdyaXRpbmctbW9kZTogaG9yaXpvbnRhbC10YjsKfQoKLnYtZXhwZWN0ZWQgewog ICAgZGlzcGxheTogaW5saW5lLWJsb2NrOwp9Cjwvc3R5bGU+Cgo8L2hlYWQ+Cjxib2R5PgoKPGgy PkFjdHVhbCByZW5kZXJpbmc6PC9oMj4KCjxkaXYgY2xhc3M9Im91dGVyIHYiPgogICAgPGRpdiBj bGFzcz0iaW5uZXIgaCI+aG9yaXpvbnRhbC10YiBpbnNpZGUgdmVydGljYWwtbHI8L2Rpdj4KPC9k aXY+Cgo8aDI+RXhwZWN0ZWQgcmVuZGVyaW5nOjwvaDI+Cgo8ZGl2IGNsYXNzPSJvdXRlciB2LWV4 cGVjdGVkIj4KICAgIDxkaXYgY2xhc3M9ImlubmVyIj5ob3Jpem9udGFsLXRiIGluc2lkZSB2ZXJ0 aWNhbC1scjwvZGl2Pgo8L2Rpdj4KCjwvYm9keT4KPC9odG1sPg==