- From: Anton Prowse <prowse@moonhenge.net>
- Date: Sat, 28 Apr 2012 13:19:21 -0400
- To: "www-style list" <www-style@w3.org>
- Cc: "Tab Atkins Jr." <jackalmage@gmail.com>
> On Mon, Apr 23, 2012 at 2:25 AM, Anton Prowse <prowse@moonhenge.net> > wrote: >> On 26/01/2012 00:14, Tab Atkins Jr. wrote: >>> >>> Flexbox has to worry about box-tree fixup so it can properly wrap >>> things in anonymous flexbox items when appropriate, and reorder things >>> via flex-order. I'm currently explicitly handling two types of >>> box-tree fixup - table-fixup and block-in-inline fixup - but I'm not >>> sure if I'm catching everything, or if there are more generic hooks I >>> can use to ensure that flexboxes play nicely with future extensions to >>> CSS. >>> >>> 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. >> >> >> Interesting. Could you elaborate on what you mean about performing >> block-in-inline fixup after block layout does its thing? > > I didn't say that, so I'm confused about what the question is. ^_^ > Rephrase? Then I guess I'm confused by what /you/ were saying :-) I read you as saying: table fixup occurs before flexbox does its thing, but block-in-inline fixup occurs after [flexbox does its thing]. This appears to be consistent with s/flexbox/block layout/. ... which leads to "block-in-inline fixup occurs after block layout does its thing". Could you clarify? (It's not a particularly important point; I just found this aspect of flexbox interesting.) Cheers, Anton Prowse http://dev.moonhenge.net
Received on Saturday, 28 April 2012 17:19:52 UTC