W3C home > Mailing lists > Public > www-style@w3.org > January 2012

Re: [css3-flexbox] What types of box-tree fixup can occur?

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Thu, 26 Jan 2012 17:42:58 -0800
Message-ID: <CAAWBYDBfuVJewv7hDUuJU0tO7+pFAHXjHkhU2Ywmb0=gA1zjvw@mail.gmail.com>
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.


> 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.

Received on Friday, 27 January 2012 01:43:58 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:10 UTC