1496740 - Display how much extra room was available on a flex line, how many total fractions, and many the current item used

Status: NEW

(DevTools :: Inspector, enhancement, P2)

Description

[Patrick Brosset <:pbro>]

Once bug 1495717 lands, we'll have a section in the flexbox inspector that explains how an item got its size.

One part in this section is about flexibility. In particular, how much an item grew by.

This is a feature request to improve this part.
In particular, make it display these extra pieces of info:
- how much extra room was available on the line
- how many total fractions did all the items on the line want to occupy
- how many fraction did the current item want

Comment 1

[Patrick Brosset <:pbro>]

Hey Brad, we discussed about this recently. Do you think we could augment the return values from the getAsFlexContainer API so it gives us some information related to this?

Comment 2

[Brad Werth [:bradwerth]]

Putting on pause for now; will review after first prototype reveals need for this type of feature.

Comment 3

[Patrick Brosset <:pbro>]

To elaborate on this, Brad and I discussed yesterday and realized that the current getAsFlexContainer API might already return enough information for us to do this. So we'll need to prototype this and then cycle back on whether we need something more.

Comment 4

[Daniel Holbert [:dholbert]]

(In reply to Patrick Brosset <:pbro> from comment #0)
> In particular, make it display these extra pieces of info:
> - how much extra room was available on the line
> - how many total fractions did all the items on the line want to occupy
> - how many fraction did the current item want

Two special considerations:
 (1) RE "total fractions" and "how many fraction did the current item want" -- for flex-shrink, we actually *scale* the flex factor by the flex basis before we use it (because it's not fair to make tiny items shrink by the same amount as larger items -- the idea is that every item with flex-shrink:1 will shrink by the same *proportion of its own size*.)
So if we're reporting sums and "shares" of flex fractions, then for flex-shrink, we'll really need to be reporting the "scaled" values, which may give us values in the range of >100 (since they're scaled up by flex-basis values, which may be ~100px or more, particularly if they come from content like a paragraph of text).

 (2) These questions ("how much extra room" & "how many total fractions") are tricky questions to answer in general and may not have a single coherent answer that all the flex items would agree on, because we may have to run the flex algorithm's main loop multiple times. (e.g. if a greedy item gets a huge share of the free space & exceeds its own max-width as a result, then we clamp that item & restart the flex layout algorithm with a different amount of free space and a smaller sum-of-flex-values from the remaining items. And in that loop, the same thing could happen with a different item -- it might exceed its own max-width -- and we'd have to restart again without that item & with lower values for free space & sum-of-flex-grow-values.)

We could just report the up-front numbers from the first run of the loop. e.g.:
 - If we give each flexible item its flex-basis, then there's 120px available to distribute.
 - Sum of flex factors is 6 (for example)
 - This item's flex-factor is 2 so it wants 1/3 of the available space.

In cases where we only run the loop once, this is great.  But if we have to clamp an item and restart the loop, then this information may be stale / confusing for all the other items, since their most-meaningful loop will have a different amount of free space and a different sum of flex factors. I'm not sure if it'd be clearer to just report this anyway, vs. report the values for each item for the last loop that it participated in... (The latter would be the clearest thing from the perspective of a given item, but it's a little confusing if you walk across all the items and see potentially-different values for each one.)

Comment 5

[Patrick Brosset <:pbro>]

We decided not to block milestone 2 with this new feature. Let's just block the main flexbox meta bug instead.