Re: [css-flexbox] 'stretch' can shrink flex items - is this intended?

On 6/26/13 1:09 PM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:

>On Wed, Jun 26, 2013 at 11:31 AM, Alan Stearns <stearns@adobe.com> wrote:
>> On 6/20/13 6:16 PM, "Tab Atkins Jr." <jackalmage@gmail.com> wrote:
>>>On Thu, Jun 20, 2013 at 6:06 PM, Alan Stearns <stearns@adobe.com> wrote:
>>>> I'm looking at what happens when a flex item's hypothetical cross size
>>>>is
>>>> larger than the container's definite cross size. There seems to be a
>>>>bit
>>>> of inconsistency (though it's interoperable inconsistency between
>>>>Blink
>>>> and Gecko, at least).
>>>>
>>>> Consider a flex container with max-height of 100px that contains one
>>>>flex
>>>> item (A) with 'height:150px' and another flex item (B) with
>>>>'height:auto'
>>>> but whose hypothetical cross size from step 7 ends up at 150px. You
>>>>can
>>>> see something similar at [2]
>>>>
>>>> If these items are any alignment other than 'stretch' then they are
>>>> consistently 150px tall.
>>>>
>>>> But if the alignment is 'stretch' then A is 150px tall and B is 100px
>>>> tall. The 'stretch' value causes a flex item to shrink.
>>>>
>>>> Step 11 of section 9.4 [1] accounts for this, but is this the correct
>>>> result? If not, we could add an additional caveat such as, "and its
>>>> hypothetical cross size is smaller than the used cross size of its
>>>>flex
>>>> line"
>>>
>>>Yes, it's intentional.
>>>
>>>~TJ
>>
>> Could you go into the scenarios where this is useful? At least in my
>> testing having a child's contents overflow doesn't seem to be a better
>> result than allowing a child to overflow the container.
>>
>> I'm asking because of the auto-height regions in a flex container case.
>>If
>> the result of the regions processing model says that an auto-height
>>region
>> is a particular height, then having something increase that height does
>> not change the named flow fragment that fits into the region. An
>> auto-height region either has the entire remainder of the flow, or the
>> content up to the next region break. Increasing the region height
>>doesn't
>> change either of those fragments.
>>
>> But decreasing the region height could change the fragmentation, and
>>that
>> would cause us to have to re-calculate the fragmentation and heights for
>> the rest of the region chain. If we could guarantee that stretch does
>>not
>> make flex items shrink, then this interaction could be less complicated.
>
>Can you walk through how this would happen?
>
>As far as I can tell, the shrinking occurs before you actually
>determine how much of the region flow should go into the box.
>
>~TJ

See the regions/flexbox thread from today [1]. You and I have different
opinions on what happens when.

When I say that the result of the regions processing model provides an
input to the flex layout algorithm, I mean the *entire* regions processing
model. You're picking out an answer from the middle.

Thanks,

Alan

[1] http://lists.w3.org/Archives/Public/www-style/2013Jun/0623.html

Received on Wednesday, 26 June 2013 20:16:38 UTC