Streamline the width control on flex layouts

[jameskoster]

Here's the current UI:

A couple of things stand out:

1. The segmented control is a bit heavy considering the labels may not be familiar.
2. Generally, help text describes the control as a whole, but here it describes the selected value which makes for an awkward discoverability flow.
3. The footprint of the control doubles in size for fixed width. It would be nice to fit everything into a single row or even half a row considering the Height control.

Let's explore some design options that address these points.

[jasmussen]

Here's a quick stab (Figma) at a design that compresses this. It's based on your existing work, Jay, just a slight remix:

• It includes height, which might not need these values immediately, but is nevertheless good to keep in mind. By being a half-column control, it allows width and height to both exist side by side, but if we start with just width, the width input could be a full-column control until such a time as we can revisit "Height".
• The fit/fill/hug control becomes a dropdown inside the input. This dropdown affords both compression for the main control, but also additional space to describe the not necessarily intuitive behavior of each dropdown menu item.
• The unit control could similarly become a custom popover, to afford a toggle at the bottom. If untoggled, it would match flex-shrink: 0;

[tellthemachines]

Thanks for thinking this out @jasmussen !

Could the "allow shrinking" toggle conceivably fit within the "fit, fill, fixed" dropdown? Maybe just under the "fixed" option and becoming visible only once it's selected?

I ask because adding it in the unit section would force us to create a new component (the unit control value selector only renders a set of values, nothing else) and trying to integrate a toggle in a select control raises questions regarding the semantics (is it going to become a dropdown menu with the select and the toggle? If so, its opening button can no longer be a value from the select; it should be something static) which will are likely to cause some a11y grief. Whereas if we were to put the toggle in the other dropdown, we would essentially be reusing a pattern that already occurs in the post visibility section (when "Password protected" is selected).

Another question: do we want to be able to simultaneously set fixed width and height for flex items? The difficulty I anticipate here is that the secondary axis won't behave consistently with the main one regarding fit/fill behaviour or the default responsivity of a fixed size:

• For Row children, their height is by default the full height of the container (leaving aside wrapping for the moment); this means their height wouldn't start off as "fit" unless we tweaked it by adding an "align-self: start". But this might interfere with future alignment settings on the parent Row block, which we haven't implemented yet. We could potentially start them off as "fill"; would that be confusing?
• For Stack children we have the same behaviour regarding fit/fill plus the problem of fixed width values becoming unresponsive, because they're not aligned with the main flex axis.

[jasmussen]

Good thoughts. Yes, I think there are some options to still explore to thread the needle. Hopefully as we are now able to use the feature in trunk, it can help inform the incoming iterations.

[jameskoster]

Worth also noting that some configuration options are only relevant conditionally. For example setting blocks within a Stack to fill height will only make sense if the Stack itself has a !fit height.

I don't know if the controls need to entertain all of these conditions and disable options where appropriate, or if we should do something like Figma where updating one value will tangentially update others when necessary in order to make the original selection work.

---

Going back to the design, I wonder if it might be helpful to include some on-canvas indicators of what each option will do? E.g. hovering the fill option:

[jasmussen]

Could that arrow be spot-color blue? But yes, in-canvas visualizations would be an excellent enhancement to these.