RE: [css3-flexbox] anonymous flexbox children

Great, thanks.

On the distinction of inline-block vs. replaced inline-block, I believe at the f2f where we came up with that resolution we have decided to only promote replaced inline blocks to flex items, but not regular inline blocks. I can't recall what was the reason (and my preference was also to accept all inline blocks) but it is a change and we should confirm that f2f review.

Alex

-----Original Message-----
From: Tab Atkins Jr. [mailto:jackalmage@gmail.com] 
Sent: Wednesday, February 23, 2011 3:47 PM
To: Alex Mogilevsky
Cc: www-style list
Subject: Re: [css3-flexbox] anonymous flexbox children

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

> n # 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"

Yes, that's covered.  All inline-block elements are considered flexbox children, actually, as they're inline-level boxes, not inline.


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

I need to rephrase that whole section, actually, because it suffers from the same element/box confusion that the table-fixup algorithm does.


> 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"?

"flexbox items" sounds good.  I'll go with that.

~TJ

Received on Thursday, 24 February 2011 00:13:21 UTC