[css3-flexbox] miscellaneous comments on Chapter 4. Flex Items from fantasai on 2012-07-04 (www-style@w3.org from July 2012) (original) (raw)
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.)
- 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 around
the
, the is still the direct child of theflex container, and so becomes the item. -->
There is no longer this behavior because is promoted to a "display: block". Suggestion:
|<!-- flex item: there is no block-in-inline split because 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