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

(12/07/10 5:32), fantasai wrote:
> On 07/04/2012 08:55 AM, 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'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.
>>
>> 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.
> 
> It does, because a flex item (that is block-inside) is a block container
> that establishes a block formatting context. Therefore section 10.6.7
> applies. Unfortunately CSS2.1 isn't super well-written here. :/ But it's
> not a bug in Flexbox, it's a problem with how CSS2.1 is written.

Yes, my major issue has been the "in certain cases" precondition there,
as I described above. I don't particularly care which spec to fix to
address this issue, besides that I think one of these should be fixed.
If we want to fix this in css3-flexbox, we can as well just add a
sentence, talking about a 'display: block' flex item, and link to 10.6.7.

> A flex item that's not block-inside will have its height calculated
> according to different rules, e.g. a table-inside flex item will have
> its height calculated according to the rules for table heights, not
> according to Chapter 10.

Indeed.

>> The flex layout algorithm has
>>
>>    # 6 Resolve the flexible lengths of all the flex items to find their
>>    # used main size, and determine their hypothetical cross size from
>>    # this main size.
>>
>> . Is this "determine their hypothetical cross size from this main size"
>> something that's not yet defined?
> 
> Would s/from/assuming/ solve the confusion here?

There's no confusion on this from my side (though this wording change is
welcome too, I guess). I was just countering the "flex items aren't
block-level elements, so those sections don't apply" statement and
saying that if they don't apply, this particular step is insufficient to
determine the 'height' of a 'display: block' flex item.

However, now I read this step, in a vertical flex container, how do you
determine the hypothetical cross size ('width') of a flex item from it's
main size ('height')?

>>>> 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.
> 
> Ah, I see where the confusion is. If a table element exists (i.e. it is not
> generated due to anonymous box generation), the table wrapper box is not
> an anonymous box. It is the principal box of the table element. The table
> element generates two boxes, neither of which is anonymous because both are
> associated with an element. (I believe the spec used to say that the table
> wrapper box was an anonymous box, but that's been fixed since the 2010
> edition.)

I apologize again for quoting a paragraph that's only tangentially
relevant/irrelevant to my comment. No, there's indeed no anonymous flex
items here. I am just talking about a table wrapper box's non-inherited
properties, which by default don't get the values that are supposed to
be set on a flex item, so the spec needs to say it.


Cheers,
Kenny

Received on Tuesday, 10 July 2012 00:16:34 UTC