Re: [css-flexbox] Behaviour of percentage heights in column direction

On Sat, Jun 21, 2014 at 7:39 PM, Greg Whitworth <gwhit@microsoft.com> wrote:
>> Absolutely, the IE/FF behaviour is preferable, and I'd prefer every browser to
>> match it. The problem seems to be the that definition of a "definite" size
>> within the spec leaves scope for different implementations to disagree about
>> what is and isn't definite, based on how they go about resolving constraints.
>> By the letter of the law, as laid out in the spec algorithm, it would seem that
>> Chrome is correct in treating these flex items as indefinite, even if we can
>> see they effectively *are* definite.
>>
>> I don't know what the answer is to that. Maybe the algorithm in the spec
>> needs to be changed to reflect whatever FF/IE are doing with respect to
>> determining that certain flex items don't need to have their content
>> measured.
>
> What do you think Tab? I am more than willing to open a Chrome bug for this, I've had three flex interop bugs in the past week from live sites and this seems like one we'll hit sooner rather than later and I would prefer to avoid it.

fantasai and I discussed this this morning.  Based on that discussion,
and the telcon discussion we had last week, we agree with the
conclusions of this thread.  Namely, percentage heights on children of
flex items should be resolveable if the item's 'flex-basis' is
definite; they resolve against the *flexed height* of the flex item
(not its flex-basis directly).

Our tests on Firefox seem to show that it's pretty consistent with
this behavior, and it seems to make sense and not have any circularity
issues.

(There's still the issue of what happens when the item freezes due to
a min-height violation based on its min-content size, but that's a
more general issue than just Flexbox, and we've started a separate
thread on that.)

~TJ and fantasai

Received on Tuesday, 1 July 2014 16:54:40 UTC