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

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

From: Kang-Hao (Kenny) Lu <kennyluck@csail.mit.edu>
Date: Wed, 04 Jul 2012 06:04:06 +0800
Message-ID: <4FF36C56.8070905@csail.mit.edu>
To: WWW Style <www-style@w3.org>
== 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.


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

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


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

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


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


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


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


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


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


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


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



Cheers,
Kenny
Received on Tuesday, 3 July 2012 22:04:36 GMT

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