Open Bug 1496463 Opened 6 years ago Updated 2 years ago

DevTools flexbox inspector might want to be clearer about border/padding contributing to "Final width" (but not "Content width")

Categories

(DevTools :: Inspector, defect, P3)

defect

Tracking

(Not tracked)

People

(Reporter: dholbert, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(6 files)

Attached file testcase 1 (deleted) —
Right now, for flex items that have padding and/or border (for example, default-styled <button> elements), the flexbox item inspector information is a bit confusing. It shows all properties at their defaults (assuming they are), which means there's no reason to grow/shrink, and then it shows e.g. Content width: 31.5px ... Final width: 61.5px This makes it look like we flexed the button and grew its size. And this is confusing, because flex-grow is 0. Really, we didn't flex the button -- it's just got some default padding + border which contribute to its size as a flex item. We should probably surface this better to avoid giving the impression that flexing/growing is happening when really it's not.
Thoughts: - Maybe we should add a line for the "main-axis border+padding"? That would add a bit of clutter, but if we hide some of the properties that are at their defaults (which IIRC was a proposal at some point), then this wouldn't be so bad. ...or: - Maybe we should add a label somewhere (tooltip, ?-icon, etc) that indicates that Final Size includes border and padding?
Priority: -- → P3
This is a great point! I think it would be worth having some indication of these box model attributes in the item sizing diagrams as well. I'll try some things.
Attached image screenshot after bug 1495717's patch (deleted) —
Thanks! For what it's worth, I retested with Patrick's latest patch from bug 1495717, and this is kind-of better, I think? As of that patch, we seem to report a "final size" that does *not* include border+padding. So whereas my previous screenshot showed a final size of 61.5px, this screenshot shows a final size of 31.5px (not including border/padding). Pro: That means "base size" and "final size" are the same, which makes it clear that there's no flexing going on. Con: It means some of the space may be harder for the user to account for, if they're looking at the button and noticing that it's (visually) nearly twice as wide as we say it is. Not sure what's best here, but I just wanted to get that soon-to-be-updated on your radar before you prototype too much. :)
Attachment #9016420 - Attachment mime type: text/plain → image/png
Attached image mini-map with padding (deleted) —
Thanks for the additional info - If I understand this correctly, I think I'd want to see padding added in there, since I would see the final size as being the item size. Here's a basic initial idea of how including padding could look. Will discuss more in Slack.
I think showing padding in the minimap is probably useful, though I do find it a little confusing in that mini-map... it makes it harder to tell whether or not any growing actually happened. (At first glance, it looks like there was growing, because there's a "grow" bar and because "final" and "basis" aren't the same. But on closer inspection, it looks like the only difference between "final" and "basis" is *exactly* the padding, which means really there wasn't any growth. I think we need to be sure it's easy to visualize the delta between the flex-base-size (of the content-box) & the final-size of the content-box, and then show border/padding separately from that difference.
Attached image Grow with padding (deleted) —
Just to bring the Slack conversation back into this bug, here's my idea for showing growth (magenta) with there being padding (purple)
Attached image shrink with padding (deleted) —
And here is shrink with padding
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: