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

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

From: Anton Prowse <prowse@moonhenge.net>
Date: Fri, 06 Jul 2012 09:19:38 +0200
Message-ID: <4FF6918A.9030107@moonhenge.net>
To: WWW Style <www-style@w3.org>
CC: "Kang-Hao (Kenny) Lu" <kennyluck@csail.mit.edu>, fantasai <fantasai.lists@inkedblade.net>
On 04/07/2012 17:55, Kang-Hao (Kenny) Lu wrote:
> (12/07/04 23:25), fantasai wrote:
>> 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 don't see anything that indicates that [10.6.4, 10.6.6 and] 10.6.7 
only apply to block-level elements, so I think Kenny's point is valid.

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

I don't feel that this addresses Kenny's point, although this new text 
is welcome.

> Then which spec/section describes how to calculate the 'height' of a
> flex-level box? I thought the sentence
>
>    # In addition, if the element has any floating descendants whose
>    # bottom margin edge is below the element's bottom content edge, then
>    # the height is increased to include those edges. Only floats that
>    # participate in this block formatting context are taken into
>    # account, e.g., floats inside absolutely positioned descendants or
>    # other floats are not.
>
> in 10.6.7 applies here.

One would imagine that something similar must apply.  I think we do want 
10.6.7 to apply; as Kenny says, we just need to /say/ that it applies, 
i.e. we need to reference 10.6.7 from the flexbox spec.


>>>     # 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.
>
> 17.4 Tables in the visual formatting model
>
>    # The computed values of properties 'position', 'float', 'margin-*',
>    # 'top', 'right', 'bottom', and 'left' on the table element are used
>    # on the table wrapper box and not the table box; all other values of
>    # non-inheritable properties are used on the table box and not the
>    # table wrapper box.

Indeed, CSS21 doesn't provide any default rule for the distribution of 
non-inherited properties between the table box and the table wrapper 
box.  So the flexbox spec (every spec, in fact, until there's a 
css3-table spec) will need to say which new properties are used on the 
wrapper box when specified on the table box.  I don't think there's any 
work to do in the case of an /anonymous/ table box, though, since no new 
properties can be specified on that box in the first place.


>>>     # 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?
>
> I think my exact question is, for a case like
>
> <div style="display: flex">
>    <span>A</span>
>    <span style="position: absolute; order: -1;">B</span>
>    <span style="order: -1">C</span>
> </div>
>
> is the place holder before A or not? Or in other words, does the place
> holder has 'order: -1' or 'order: 0'?
>
> Your s/// seems to suggest 'order: 0' but I think the wording is still a
> bit vague. The hypothetical non-flex normal flow would be "A placeholder
> C" but I think you want "C A placeholder" or "placeholder C A".

Indeed.


Cheers,
Anton Prowse
http://dev.moonhenge.net
Received on Friday, 6 July 2012 07:20:14 GMT

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