70769 2011-10-24 15:41:14 -0700 display:inline-block elements don't correctly handle orthogonal writing-modes 2023-10-31 18:17:03 -0700 1 1 1 Unclassified WebKit Layout and Rendering 528+ (Nightly build) Unspecified Unspecified NEW P2 Normal --- 70829 1 ojan webkit-unassigned ahmad.saleem792 hyatt mihnea tony oldest_to_newest 489710 0 ojan 2011-10-24 15:41:14 -0700 The fix in http://trac.webkit.org/changeset/97653 only works if the child doesn't have any children. Whoops! Specifically, computeLogicalHeight assumes the child has been laid out already. I'm not 100% sure what the right fix is. If we call child->layoutIfNeeded() before we call computeLogicalHeight(), everything works, but I don't know if calling layout earlier will cause other problems. Dave, what do you think? 490240 1 ojan 2011-10-25 12:31:49 -0700 TL;DR version: This bug is really unlikely to occur in the real world given that it requires orthogonal writing modes and auto-sizing inline-blocks. The current code works non-auto cases, which is good enough. Condensed #webkit discussion: dhyatt: min/max width stuff is just a heuristic basically dhyatt: it can't do layouts dhyatt: so it gets lots of things wrong dhyatt: you just have to accept that it does tony^work: why can't you do layouts? dhyatt: because you can be in layout when you ask the question ojan: but you're laying out the child ojan: you can't be in the child's layout, right? ojan: oh...hm...i guess you could dhyatt: it's also just specifically part of the design that it's a separate algorithm ojan: so, vertical writing mode + inline-block is just forever broken? dhyatt: with auto sizing (which you'd never do when mixing writing modes anyway) ojan: or alternately, vertical flexboxes in an inline-block dhyatt: with non-auto sizing should work fine ojan: i'd imagine for the things you'd use inline-block for, auto-sizing is not that uncommon dhyatt: css is actually (i'm hazy on this would have to check or consult dbaron) wanting the computation of preferred width to not involve layout dhyatt: like it's supposed to be a simplified algorithm dhyatt: since the preferred widths get used by layout algorithms ojan: i agree that's a better design dhyatt: but yeah the downside is that you can't handle many cases dhyatt: your bug is nothing compared to some of the ones already filed ojan: but it seems like a problem if the spec has this bug dhyatt: for nice normal horizontal-tb cases dhyatt: well i don't know if it's made it into any spec dhyatt: technically the way to get this kind of stuff right is to do a layout at an unconstrained size dhyatt: rather than having a separate algorithm dhyatt: but then you get into tough situations with cycles and stuff ojan: do a layout of the child at an unconstrained size you mean? dhyatt: and of course layout is way way way more expensive dhyatt: than our current preferred width computations dhyatt: well, layout of whoever's preferred width you need dhyatt: typically a child dhyatt: anyway, not saying the bug is invalid dhyatt: just saying i'd let it go for now and keep it filed ojan: yeah...i know... dhyatt: since we can't put a layout in that code dhyatt: as long as non-auto works dhyatt: i think having inline-block perpendicular flows is a pretty nonsensical thing to do dhyatt: so i'm not worried much about this edge case dhyatt: i can't imagine anybody ever doing that dhyatt: since it doesn't make any sense really dhyatt: like you don't see anything like that in japanese books dhyatt: you'll see orientation shifts at the block level dhyatt: but not at the piece-of-a-line level like inline-block dhyatt: height = borderAndPaddingHeight is basically setting it to 0 content height dhyatt: which i think is ok dhyatt: basically i think what's checked in is fine for now dhyatt: i know it's annoying to feel like a case is being left broken on purpose dhyatt: but i've had to do that in many many places with perpendicular flows dhyatt: often i just ask myself, "is a book/web site really going to do this?" dhyatt: and usually the answer is no dhyatt: remember that height in preferred width scenarios actually *is* supposed to resolve to 0 in many cases dhyatt: auto is dhyatt: e.g., percentage widths go to 0 for example 1989048 2 ahmad.saleem792 2023-10-31 18:17:03 -0700 Following bug is referred in this blink commit and with following test case (changed into JSFiddle): https://jsfiddle.net/g15nmcf3/show Blink Commit: https://chromium.googlesource.com/chromium/blink/+/deee83808ed40a6c500c9e1b616b95477c7b2325 Blink Commit title: Fix shrink-to-fit when children's writing-mode is orthogonal "css3/flexbox/flex-flow-margins-auto-size.html that currently expects to fail passes with this patch: http://wkb.ug/70769" ^ mentioned in the commit message.