Re: [css3-flexbox] miscellaneous comments on Chapter 4. Flex Items

On 07/03/2012 03:04 PM, Kang-Hao (Kenny) Lu wrote:
> == Technical Comments ==
>
>    # A flex item establishes a new formatting context for its contents.
>    # The type of this formatting context is determined by its
>    # ‘display’ value, as usual.
>
> A flex item of 'display: block'  should probably use the 'height'
> calculation in "10.6.7 'Auto' heights for block formatting context
> roots", but 10.6.7 says
>
>    # In certain cases (see, e.g., sections 10.6.4 and 10.6.6 above), the
>    # height of an element that establishes a block formatting context is
>    # computed as follows:
>
> and who knows what "certain cases" means here (10.6.6 doesn't cover
> 'table-cell', for example). It's not clear to me if this is a CSS 2.1
> issue or css3-flexbox issue.

Flex items aren't block-level elements, so those sections don't apply.
I've added
   # However, flex items are flex-level boxes, not block-level boxes;
   # they participate in their container's flex formatting context,
   # not in a block formatting context.
to the section to clarify this.

>    # For example, given two contiguous child elements with
>    # ‘display:table-cell’, an anonymous table wrapper box around them
>    # becomes the flex item.
>
> Since CSS 2.1 by default doesn't propagate non-inherited properties to
> the table wrapper box. It should be mentioned that all properties that
> apply to flex items have this propagation.

Hmm, I thought it was generally stated in 2.1 how anonymous boxes behave.

> (This should be the part of the checklist of a new CSS module. By the
> way, I noticed that the statement saying that properties in this module
> don't apply to ::first-letter and ::first-line is gone.)

Added.

>    # Absolutely positioned children of a flex container are not
>    # themselves flex items, but they leave behind "placeholders" in
>    # their normal position in the box tree.
>
> I am not sure what "normal position in the box tree" means here. Does it
> mean that the 'order' value on the absolutely positioned element would
> be propagated to the placeholder? Is this the only property in
> css3-flexbox that does this propagation for an abs-pos flex item? If so,
> I hope this is clarified.

I went with s/normal/hypothetical normal-flow/. Does that work?

> By the way, for the purpose of the layout algorithm ('order' and such),
> it might or might not be necessary to say that non-inherited properties
> by default have their initial value on the anonymous flex items. CSS 2.1
> says,
>
>    # The properties of anonymous boxes are inherited from the enclosing
>    # non-anonymous box (e.g., in the example just below the subsection
>    # heading "Anonymous block boxes", the one for DIV). Non-inherited
>    # properties have their initial value.
>
> but given that this paragraph is in "9.2.1.1 Anonymous block boxes", I
> am not exactly sure if this applies to anonymous flex items. (I should
> note that there is a duplicated paragraph in "9.2.2.1 Anonymous inline
> boxes".)

It's a general statement about anonymous boxes, just poorly placed.
Not something that's easy to correct, without rewriting that entire
chapter.

> == Editorial Comments ==
> (I am going to be quite picky here, but these are, after all, just
> editorial comments.)
>
> 4. Flex Items
>
> The definition of "flex item" results in a "flex item's" entry in the
> index, which seems redundant.

Fixed.

>    # each child of a flex container becomes a flex item,
>
> I would hope we don't produce box-element duck-typed statements in CSS3
> specs, so this should be either "child box" or "child element". I suggest.
>
>    | each child element (except those described below) of a flex
>    | container becomes a flex item.

I don't know how to fix this to be any more precise than it is,
so I'm going to leave it. ("Element" is incorrect due to anonymous
table boxes.)

> It would be nice to link white space to
> http://www.w3.org/TR/CSS2/syndata.html#whitespace.

That's actually the wrong definition to use. :)
Added a link.

>    #<!-- flex item:
>    #         even though block layout will split the<span>  around
>    #         the<div>, the<span>  is still the direct child of the
>    #         flex container, and so becomes the item. -->
>
> There is no longer this behavior because<span>  is promoted to a
> "display: block". Suggestion:
>
>    |<!-- flex item: there is no block-in-inline split because<span>  is
>    |                 promoted to a 'display: block'.
>
> It would be nice to keep an abs-pos example here.

Added it to the out-of-flow section.

>    # For example, a ‘table-cell’ child of a block container is fixed
>    # up by ...
>
> But we are talking about a 'table-cell' directly inside a flex
> container, which is not a block container by definition. Suggestion:
>
>    | For example, a misparented ‘table-cell’ child is fixed up by ...

Fixed.

> 4.4. Implied Minimum Size of Flex Items
>
>    # To provide a more reasonable default minimum size for flex
>    # containers,
>
> Perhaps I am missing the rationale here, but isn't this s/flex
> containers/flex items/?

Yep!

> "1.2. Module interactions" is missing a description of the new 'auto'
> value here.

Added.

~fantasai

Received on Wednesday, 4 July 2012 15:26:27 UTC