Consider new label and copy for Layout controls

[kjellr]

The current Layout control is powerful, but difficult to understand:

In particular, I think the word "layout" may not be descriptive enough — we already deal with a lot of confusion around the difference between templates, template parts, patterns, and reusable blocks... and any one of those could easily be described by someone as a "layout". It may make more sense to specifically refer to these as "widths" in some way, since that's really what you're choosing.

Here's a quick pass at renaming some of these labels:

• I renamed the panel to "Content Widths". I know that has some legacy to it, so it might not quite make sense here. But it's more descriptive than Layout.
• I moved the description up to the top, and expanded it to explain what this panel does. I'm not totally sure about using the words "inner blocks" here, since those seem a little technical.
• I renamed "inherit default layout" to "use theme defaults", so that it's more clear where the default widths come from (do they always come from the theme?)

I still don't think this makes things totally clear, but I figured it's a good enough place to open up a discussion about the way we describe this feature.

[youknowriad]

Just wanted to add that ultimately, we'll be able to switch "layout types" that's why it's called "layout" for instance you should be able to choose a "grid" container or a "flex" container (much like social links or columns) and in these situations "widths" don't make sense any more.

That said, it's still not implemented yet so we could reconsider later. For the help text, I find the proposed one very good.

[jameskoster]

By default, inner blocks will display full-width

Full-width relative to the container, right? I wonder if it's worth highlighting that because "full-width" might be interpreted literally, IE the full-width of the browser window.

Would it also be worth using a label like "Default" instead of "Content" for the first input? If I'm not using the theme default, my first thought is "what default am I using?". "Content" doesn't necessarily transition so well to the template editor either.

I don't think the relationship between the inputs and the child blocks is communicated very well. The icons help, but not all that much. But I'm struggling for ideas there 🤔

[kjellr]

Full-width relative to the container, right? I wonder if it's worth highlighting that because "full-width" might be interpreted literally, IE the full-width of the browser window.

Good point. Maybe something like "By default, inner blocks will take up the full width of their container." ? It's really hard to make this short and concise. 😅

Also, this may be total overkill (and goes well beyond the "labeling" title of this issue), but I wonder if it might help to gradually step into these controls a little bit:

[jameskoster]

Also, this may be total overkill

I don't think so. This concept already feels easier to understand. I like how the initial setting is simplified, and the associated complexity must be actively revealed.

[jameskoster]

I spent a little time playing with this too.

One of the big problems I found is that changes made in the control don't seem to update anything on the canvas, unless values are present in the theme (at least that is my understanding). So I think we should set some default values if possible so that all interactions have some effect on the canvas. This will really help folks understand the purpose of the feature.

By tweaking the language a bit more I also tried to make it a bit clearer that this control only affects the child blocks, which is a behaviour unique to this control.

To elaborate on this relationship I re-used a pattern from the site editor where the ancestor of the selected block has a dotted outline. This helps when applying different alignments to the inner blocks since you are able to visually interpret the relativity.

Anyway, here's what I came up with:

layout.mp4

Figma prototype here.

[kjellr]

So I think we should set some default values if possible so that all interactions have some effect on the canvas. This will really help folks understand the purpose of the feature.

Yeah, I think using some defaults when people enable the custom width settings makes a lot of sense.

Additionally, I like the "inner block layout" framing here.

I'm not totally sure that these components register as clickable either/or options for me outside of a menu context, but I think I've seen them elsewhere in the UI, right?

(I definitely like that each one has a description added to it though.)

[jameskoster]

Yeah I just used the menu item components for the prototype. If this approach makes sense we may need something new.

[erikjoling]

Are the layout controls tied to the block-alignments? Like alignfull, alignwide and default?

So parent containers can define layout widths (full, wide, default) and the children can override these widths through custom values?

[jameskoster]

As I understand it the controls in the layout panel only affect the children of that block. It's basically a toggle, either:

1. Child blocks will always fill the container 100%, or
2. Child blocks will be narrower than the container, but can individually be set as wide width or full width within the context of the container.

For option 2, the values for "narrow" and "wide" widths should come from the theme, or a default value from core. But these can be overridden by the user ad hoc.

It's especially confusing because the "narrow" and "wide" widths can be set in px. So it is possible to set the "narrow" width to a value that is wider than the parent block itself. Oh, and of course containers can be nested, so some mental gymnastics are required to put the pieces together in those situations.

[shaunandrews]

I think this half-baked idea is related to this issue, so I figured I'd share: