- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Thu, 26 Jan 2012 17:42:58 -0800
- To: Alex Mogilevsky <alexmog@microsoft.com>
- Cc: www-style list <www-style@w3.org>
On Thu, Jan 26, 2012 at 5:36 PM, Alex Mogilevsky <alexmog@microsoft.com> wrote: > ± From: Tab Atkins Jr. [mailto:jackalmage@gmail.com] > ± Sent: Wednesday, January 25, 2012 3:14 PM > ± > ± For clarity, I have currently specified that table-fixup occurs > ± *before* flexbox does its thing, but block-in-inline fixup occurs *after*. > ± This appears to be consistent with how these two fixup steps occur in > ± block layout, based on the limited testing I've done so far. > ± > ± What other kinds of box-tree fixup might occur? We removed "display:run- > ± in" from 2.1, so I don't need to worry about that (yet), but I will > ± someday. What about Ruby? Anything else? > > Ruby should work like tables. I am really not sure about run-in. > > I don't think either should be mentioned (normatively) though, or it would create dependency on other drafts. IMO table is good enough for guidance. > > Actually why not move the note on table fixup to definition of flex item? That's where it is important. Sure. > BTW I hope you don't imply that 'flex-order' can affect how anonymous items are wrapped. Nope, flex-order is part of the layout algorithm, which happens *way* after flexbox items are generated. ~TJ
Received on Friday, 27 January 2012 01:43:58 UTC