W3C home > Mailing lists > Public > www-style@w3.org > March 2011

Re: [css3-flexbox] anonymous flexbox children

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Mon, 28 Feb 2011 18:24:36 -0800
Message-ID: <AANLkTikC9WUYYqmkHTZ2bh8eJR2N12LfbotvTC1AQXRc@mail.gmail.com>
To: Alex Mogilevsky <alexmog@microsoft.com>
Cc: www-style list <www-style@w3.org>
On Wed, Feb 23, 2011 at 2:51 PM, Alex Mogilevsky <alexmog@microsoft.com> wrote:
> Current definition of "flexbox children" looks like this:
>
> http://dev.w3.org/csswg/css3-flexbox/Overview.new.html#flexbox-children
> # Block-level and atomic inline-level children of the flexbox are referred to as
> # flexbox children in this specification. Inline children are wrapped in anonymous
> # blocks, and these anonymous blocks are also flexbox children.
>
> http://dev.w3.org/csswg/css3-flexbox/Overview.new.html#display-flexbox
> # All children of a flexbox must be block-level or atomic inline-level elements.
> # Contiguous runs of non-replaced inline elements are wrapped in an anonymous
> # block-level box. Out-of-flow elements (such as absolutely positioned elements -
> # floats are also out-of-flow but can't exist as flexbox children) leave behind a
> # "placeholder" in their original source location which is treated like a non-replaced
> # inline element for the purpose of this wrapping. (This can, for example, create
> # an empty flexbox child, if all the children are block-level elements and one is
> # absolutely positioned.) It is recommended that authors avoid putting in elements
> # which are auto-wrapped with anonymous boxes, as the anonymous boxes
> # cannot be targeted and controlled with the various flexbox properties defined
> # in later sections.
>
> I'd like to make sure this includes clarifications that we previously agreed on, specifically
>
> 1) replaced inline-block children of flexbox are considered "flexbox-children" (http://www.w3.org/Style/CSS/Tracker/issues/145). I think the current text covers that, as it refers to "non-replaced inline elements"
>
> 2) block elements contained within inline elements are not "flexbox children" as they are not direct children of flexbox element. To make this clear I suggest adding this:
>
> # Contiguous runs of non-replaced inline elements are wrapped in an anonymous
> # block-level box.
> <INS>
> * Any indirect descendants of flexbox element (including block elements that
> * are contained in inline elements) are not flexbox children.
> </INS>
> # Out-of-flow elements (such as absolutely positioned elements -
> # floats are also out-of-flow but can't exist as flexbox children) leave behind a
> # "placeholder"...
>
> Does it make it more clear?
>
> BTW I find it confusing that the entities that are involved in flexbox layout are called "flexbox children" and child elements of flexbox element are called the same. It makes coming up with these definitions difficult. Can we come up with a separate term for the boxes being arranged by flexbox? Like "flexbox items" (that would be consistent with "grid items" which we currently use in Grid Alignment spec). Or "flexbox child blocks", or "flexbox content boxes"?

In the new ED I'm using "flexbox item".

I've inserted an issue about exactly how to define the flexbox-fixup
algorithm.  Similar to the table-fixup algorithm, it clearly has to
take place over the element-tree, but it creates boxes, which only
exist in the box-tree.

I believe a compromise could work - the algorithm instead creates
anonymous pseudoelements.  Pseudoelems don't mess up Selectors, and
they interact with the rest of box-tree construction in precisely the
way we want.  Being anonymous, they can't be targeted, either, though
we could perhaps introduce a way to target them, probably all at once,
to specify margins/padding/flex on them to match the rest of the
flexbox items.  This could help with using flexbox to display
<figure>, for example, so you don't need to insert a wrapper around
the content just so you can feed it flexbox properties.

~TJ
Received on Tuesday, 1 March 2011 02:25:28 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 17:20:38 GMT