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

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

From: Tab Atkins Jr. <jackalmage@gmail.com>
Date: Wed, 26 Jun 2013 13:09:19 -0700
Message-ID: <CAAWBYDA7KMqm3JtiOuHftq=PYWsgsjFVT6pe99p0wDwUuaS=+Q@mail.gmail.com>
To: Alan Stearns <stearns@adobe.com>
Cc: W3C WWW Style <www-style@w3.org>
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
Received on Wednesday, 26 June 2013 20:10:06 UTC

This archive was generated by hypermail 2.3.1 : Monday, 2 May 2016 14:39:12 UTC