Bug 70769 – display:inline-block elements don't correctly handle orthogonal writing-modes

• Component: Layout and Rendering
• Status: NEW

[Ojan Vafai]

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?

[Ojan Vafai]

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

[Ahmad Saleem]

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.