Re: [css-sizing][css-flexbox] intrinsic min/max-width/height values and percentage children

On 07/30/2015 07:33 PM, Greg Whitworth wrote:
>> Just so that I'm not talking about something entirely different, I created a
>> simple test case: http://jsbin.com/nomopewego/1/edit
>> If I'm correct than you're suggesting that the red box should be able to
> 
> I meant _shouldn't_ here, sorry about that
> 
>> resolve 50% since it doesn't know (when we're calculating the width, what to
>> resolve against).

Yes, I'm suggesting the red box shouldn't be able to resolve its 50%, at
least if our intent is that only "definite-sized" flex items can be used
for percent resolution. (where "definite" means the size can be
established without measuring content)

In your example, the size green box (which the percent is resolved
against) does in theory depend on its contents for its sizing, including
that red box. (via "min-width:auto")  The red box doesn't *actually* end
up impacting its sizing because we aren't running up against the minimum
width -- but here's an example where we do:

  http://jsfiddle.net/gehxu6mr/1/

Here, in Edge & Firefox, the percent-width element ends up establishing
the width of its parent (the flex item), via "min-width:auto" on the
flex item.  And then, we resolve the element's percent width against
that size -- so it ends up being 50% of the width that *it provided*.

So: clearly, the flex item's size isn't "definite" here, because it
depends on its child. (Chrome actually seems to ignore the child's size
when establishing the flex item's size; not sure why. Maybe they have
different min-content measurement behavior for elements with percent
widths.)

>> If that is indeed what you're saying, I don't think resolving the percentages is
>> confusing, I think not supporting them in this instance will be confusing.

I'll grant that, yeah. Authors presumably would expect the percent to be
resolved, intuitively. (But they'd also probably expect it to resolve in
this example:
<div style="display:block">
  ...Some text...
  <div style="height: 50%;background:red">...pct height...</div>
  ...and still more text...
</div>

And yet, CSS 2.1 says it's treated as 'auto' in this case.

>> The
>> fact that you need to do a two pass layout to resolve them doesn't seem to
>> be hindrance at this point, are you receiving bug reports regarding poor perf
>> on flex dependent sites?

Yes, we have received bug reports with poor performance on particular
sometimes-pathological configurations of deeply-nested flex containers.
 We also encountered poor performance with a proof-of-concept experiment
about converting every element in the Firefox UI to be "display:flex".

It's possible that some of the deeply-nested two-pass layout steps can
be optimized away with appropriate precomputation and/or re-use of
cached sizes, though, and Firefox just needs additional optimizations to
take advantage of these opportunities.  So I'm not yet sure how
fundamentally-unavoidable the perf impact/blowup is from this two-pass
layout, at this point.

Received on Thursday, 20 August 2015 21:38:08 UTC