W3C home > Mailing lists > Public > www-style@w3.org > June 2013

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

From: Alan Stearns <stearns@adobe.com>
Date: Wed, 26 Jun 2013 13:16:08 -0700
To: "Tab Atkins Jr." <jackalmage@gmail.com>
CC: W3C WWW Style <www-style@w3.org>
Message-ID: <CDF098B6.2CCE4%stearns@adobe.com>
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
>>>> larger than the container's definite cross size. There seems to be a
>>>> of inconsistency (though it's interoperable inconsistency between
>>>> and Gecko, at least).
>>>> Consider a flex container with max-height of 100px that contains one
>>>> item (A) with 'height:150px' and another flex item (B) with
>>>> but whose hypothetical cross size from step 7 ends up at 150px. You
>>>> 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
>>>> line"
>>>Yes, it's intentional.
>> 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.
>> the result of the regions processing model says that an auto-height
>> 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
>> change either of those fragments.
>> But decreasing the region height could change the fragmentation, and
>> 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
>> 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.

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.



[1] http://lists.w3.org/Archives/Public/www-style/2013Jun/0623.html
Received on Wednesday, 26 June 2013 20:16:38 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:31 UTC