[Webkit-unassigned] [Bug 70769] display:inline-block elements don't correctly handle orthogonal writing-modes

Tue Oct 25 12:31:49 PDT 2011

https://bugs.webkit.org/show_bug.cgi?id=70769

--- Comment #1 from Ojan Vafai <ojan at chromium.org>  2011-10-25 12:31:49 PST ---
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

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.