Cannot apply wide or full widths to nested blocks with theme.json applied #33374

pattyok · 2021-07-12T23:17:37Z

Description

Trying out theme.json. When it is activated, the option to set wide/full width on a block placed inside a group disappears. This happens whether theme.json has any content in it or not. If remove theme.json, the option re-appears. I am working with my own custom theme, but I was able to reproduce with the TwentyTwentyOne theme as well.

Step-by-step reproduction instructions

Set the theme to twenty-twenty one
Add a group block, add a media-text, columns, group or cover block inside the group
Notice the ability to set the width of each of those blocks to wide, full or normal
Add a theme.json file to the theme (it doesnt seem to matter what is inside this theme file)

Expected behaviour

I still should be able to set the width of a block when it is nested.

Actual behaviour

I can't set the width of a block when it is nested. The align-wide and align-full options are not shown in the toolbar.

Screenshots or screen recording (optional)

Code snippet (optional)

This is the theme.json I am using - though editing it way down does not seem to make a difference.
https://gist.github.com/pattyok/0e7726a15c59ba8d183d2d1427728b48.js

WordPress information

WordPress version: 5.8-RC2
Gutenberg version: 11.0.0
Are all plugins except Gutenberg deactivated? Yes
Are you using a default theme (e.g. Twenty Twenty-One)? Yes

Device information

Device: Desktop
Operating system: maxOS 11.3
Browser: Chrome

getdave · 2021-07-20T10:56:41Z

I was able to replicate this. Problem is that this returns an empty array when we have an empty theme.json.

gutenberg/packages/block-editor/src/hooks/align.js

Lines 174 to 175 in fc243d2

    
           const validAlignments = useAvailableAlignments( 
        
           	blockAllowedAlignments

getdave · 2021-07-20T11:17:02Z

@pattyok Try adding the following to your theme.json

{
    "version": 1,
    "settings": {
        "layout": {
            "contentSize": "840px",
            "wideSize": "1100px"
        }
    }
}

That should restore those alignment controls.

pattyok · 2021-07-20T14:44:41Z

Yes, those settings are in there, and the problem still exists. Note that this is only an issue for nested blocks.

Here is a better link to my theme.json. https://gist.github.com/pattyok/0e7726a15c59ba8d183d2d1427728b48

thetwopct · 2021-07-28T08:11:08Z

I guess this is related/the same, but for me add_theme_support( 'align-wide' ) is ignored once theme.json is present.

If I remove layout{} from theme.json or do not specify content or wide sizes within layout{} then add_theme_support( 'align-wide' ) in my theme functions is ignored and blocks do not support wide and full alignment.

I would expect add_theme_support( 'align-wide' ) to still work if layout{} is not present.

youknowriad · 2021-07-30T09:25:08Z

Hi There!

Thanks for opening the issue, this is an intended behavior, the logic is simple. If you define "widths" (content and wide) widths for your canvas, there's nothing that tells that these widths apply to the nested blocks of any container because that container can be smaller (think a column, a small group block, a buttons block...) meaning we can't just blindly allow nested blocks of these containers to have wide/full alignments, you first have to define the "layout" of their container blocks. So for the group block, this is supported you can, go to the sidebar controls (inspector controls) of your group block and define the widths for the inner blocks of that particular container, you can also inherit the same definition as the global layout config (there's a toggle there). Once you define a layout for a given container, its children will have the possibility to be full/wide aligned.

In other words, wide/full alignments config are container specific and should have always been, this release fixes it with an opt-in mechanism (theme.json) to avoid breaking existing themes.

pattyok · 2021-07-30T15:39:08Z

Oh wow. I feel like it made a lot more sense before. The language you are using in the interface is completely foreign to me, and after looking at it with this information, I am still having a difficult time grasping how the words match the concept, though I am pretty well-versed on the block environment...

It seems like you are putting a big burden on the user to set the layout of the group every time they put one on the page.

I just want to have a full width background. Inside that background I want to be able to set whether the content inside is also full width, wide or narrow. I would like these widths to be consistent across the site so I do not want to offer the option of setting widths within the interface. I most often use a calculated width for the wide-width so I prefer to just set the class and use css to set that.

What exactly is the problem of being able to set full, wide or none on the inner content of a group? Shouldn't that be the default and then one can have the option to override it and not the other way around?

youknowriad · 2021-07-30T15:51:08Z

What exactly is the problem of being able to set full, wide or none on the inner content of a group?

The problem is that a block can not break out of its container, if its container is not wide enough, putting it "full width" only means "full width" inside of its container.

pattyok · 2021-07-30T15:54:56Z

But as a theme editor I can set what full-width inside of wide width means...

youknowriad · 2021-07-30T15:57:19Z

But as a theme editor I can set what full-width inside of wide width means...

It doesn't matter if you set it, if there's a div between your block and the place where the width is defined (the post content container for instance), your style won't apply properly. Theme authors struggled a lot with this previously, a lot of themes have broken styles and alignments in some situations because of this. Can you give an example of how you'd define that width?

pattyok · 2021-07-30T16:06:22Z

Can you give an example of how you'd define that width?

That part is fixed. They've removed the inner content container. So now you can simply use
.alignwide > .alignfull { width: 100%;}

youknowriad · 2021-07-30T16:10:45Z

I'm not sure I follow the CSS you just shared, let me give you an example: Say you have an image block inside a group block inside a column block with a width of 50% and I apply "wide" or "full" on the image block what should happen?

youknowriad · 2021-07-30T16:14:13Z

Let me continue my reasoning:

In the example above, the full/wide doesn't make sense in the previous behavior, in some themes it breaks the layout entirely, in others it doesn't do anything because the column is limited to 50%.
in the new behavior which I think is more correct, you don't have "wide/full" alignments options there unless the group block in the column says, the wide area for my inner blocks is "80%" or "say 500px" while the content area is "60%" (just random numbers). This opens the possibilities for two column layouts with different "wide/full" widths for each column for instance. Or in a home page, you could have different sections one after the other, one of them narrower than the other... Basically, it's not a one size fits all.

pattyok · 2021-07-30T16:31:35Z

I understand what you are saying. But I think that offering the one-sized fits all solution first with the option to override is preferable to forcing the user to have to set the widths every time they put a thing on the page.

When I deliver a theme for a client I put things in place to guide them towards consistency this does not allow for that.

pattyok · 2021-07-30T16:47:33Z

To further clarify - why can't you allow me to set wide and full on an inner block and also allow you to override what wide and fulll mean in a specific instance?

youknowriad · 2021-07-30T16:51:51Z

Because it's impossible to consistently style wide/full alignments properly by ignoring intermediate container divs. You end up with broken alignments/layout depending on the use-case.

pattyok · 2021-07-30T17:14:46Z

I disagree that it's impossible but also that should be left to the theme developer to solve. Not the platform... I do still think some work on the language in the interface would be helpful. 'Inherit default layout' - I still have no idea what that means - I expect it to mean that it would follow what I have set for inner blocks that are alignwide and alignfull. Referencing Inner Blocks within that interface somewhere would be helpful.

…

On Fri, Jul 30, 2021 at 9:52 AM Riad Benguella ***@***.***> wrote: Because it's impossible to consistently style wide/full alignments properly by ignoring intermediate container divs. You end up with broken alignments/layout depending on the use-case. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#33374 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AASODOCJMOYBC6MUOXDJX4TT2LKDFANCNFSM5AHZPRXQ> .

youknowriad · 2021-07-30T17:25:35Z

I disagree that it's impossible but also that should be left to the theme
developer to solve. Not the platform...

With Full Site Editing, it's not the responsibility of the theme to define these structural styles, meaning the platform need to have a precise way to output these styles regardless of the used theme. Themes will be more about design, templates, and block patterns but less about figuring out how to style align left, align right, align center, or full width. these things will come with the platform and the "layout" feature is a step towards it.

I do still think some work on the language in the interface would be
helpful.
Referencing Inner Blocks within that interface somewhere would be helpful.

I completely I agree, I think we have a an issue about that #31950

bethalessi · 2021-11-15T13:49:58Z

@pattyok Did you ever figure out how to handle this? I asked the same question #36465

It sounds like you wanted to create the same thing, a simple custom block: fullwidth background that allows your client to insert innerblocks that have alignment controls.

Did you have to stop using theme.json to do it?

bethalessi · 2021-11-15T17:18:56Z

@youknowriad Does this mean, if I use theme.json, I can't make a custom block that allows innerblocks to have alignment controls? I know the group block allows it, but you have to toggle. I don't want my clients to have to toggle.

I understand that with FSE, with a theme being released to many, that could be an issue. But I need this ability for custom themes for clients.

My example situation

I have a simple "section" custom block. It's just a fullwidth container with padding and a background color. That's it. It allows my client to choose the "section" block, set a background color, and add innerblocks. This way they can group content together with a set style. They don't have to think about layout or padding. No toggling. Just enter content.

If I want to have this ability, should I stop using theme.json, and specify supports using PHP instead?

(I was converting themes to be hybrid. I don't use FSE, but I do like how theme.json handles things. Except for this issue.) Thanks!

bethalessi · 2021-11-15T17:45:03Z

@youknowriad More succinctly: When I make a custom block, is there a way to say I want the innerblocks to have default alignment (and alignment controls) when creating it? Like the layout toggle for the Group block, but baked in.

To be clear, CSS isn't the issue. I can add that. It's purely the ability to give innerblocks alignment controls so the user can still choose wide/full.

mrwweb · 2021-11-15T17:52:11Z

@bethalessi My solution for now has been to set the Group block to use the "Inherit layout" option by default with a block variation:

/* Inherit Layout by Default for Group Block */
wp.blocks.registerBlockVariation(
	'core/group',
	{
		isDefault: true,
		attributes: {
			layout: {
				inherit: true,
			},
		},
	}
);

I'd love to see this become the default behavior in WordPress, since it seems that defaulting to "just work please" rather than "select your widths every time" is a much better experience that significantly reduces the cognitive load on editors

pattyok · 2021-11-15T18:02:54Z

I did give up on theme.json as I felt it wasnt ready for a production site, yet. But of course the same behavior is applied to the group block in the block widgets, with or without theme.json. The odd thing is that you *can* set widths for inner blocks on a column, and at long last we can have a one-column layout(!?!) So I can build what you are talking about with a single column layout. Though I got so used to using the group block for this type of layout, I have taken to building out patterns with the alignwide/alignfull class assigned in the pattern template to the inner blocks as needed.

…

On Mon, Nov 15, 2021 at 5:50 AM Beth Alessi ***@***.***> wrote: @pattyok <https://github.com/pattyok> Did you ever figure out how to handle this? I asked the same question #36465 <#36465> It sounds like you wanted to create the same thing, a simple custom block: fullwidth background that allows your client to insert innerblocks that have alignment controls. Did you have to stop using theme.json to do it? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#33374 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AASODOGKD4T2CR6F5SRCS5DUMEFZFANCNFSM5AHZPRXQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

bethalessi · 2021-11-16T15:23:21Z

@mrwweb Agree! Thank you for that solution. It's an annoying workaround for now, but it got me moving ahead.

@pattyok I hear you. I changed a theme to use theme.json and then discovered this at the end and now I'm in too deep to turn around. ;) Thanks for responding!

youknowriad · 2021-11-16T17:01:52Z

More succinctly: When I make a custom block, is there a way to say I want the innerblocks to have default alignment (and alignment controls) when creating it? Like the layout toggle for the Group block, but baked in.

you can do it by providing a layout to inner blocks, that said, the feature is still experimental at the moment, you should be able to pass __experimentalLayout ={ { contentSize: '800px', wideSize: '1000px' } } to your inner blocks, you can also pass __experimentalLayout ={ { inherit: true } } to your inner blocks as well to inherit whatever layout is defined.

That said, I personally think it's wrong to automatically do it because you don't really know where your "section" or "group" block is going to be used. Maybe it's inside a small column in which case alignments don't really make sense, maybe it's inside the "row" block and alignments don't make sense there either.

eric-michel · 2022-07-18T20:43:43Z

@tellthemachines thanks for the summary of issues. It's really helpful! I have a few thoughts, but first let me just say:

We could explore setting content width by default on blocks with Layout enabled (that is, changing the default on the “Inner blocks use full width” setting in the Layout panel).

I assume you mean the new default would set Inner blocks use full width to off. This would be enough for us to finally be able to adopt theme.json. Our theme is not a block theme and won't be for a very long time. But because of this issue, we're falling further and further behind on features because they are gated behind the use of theme.json. This simple change would allow us to move forward.

Having said that, I think there needs to be a full rethink of content alignments/widths, including in full block themes. Conceptually, I understand the idea: wide and full alignments could be argued to be relative to the container. But that's not how everyday users and editors view them. Just look at the comments through this thread.

Our users look at these alignments like they look at font sizes. Something set to a predefined max width that they can reliably use to create consistent layouts. In our case, standard alignment is a max width of 782px, wide is 1100px, and full is 100% (along with a custom class called alignnarrow which is 580px). This offers our users a flexible and predictable set of options to choose from including blocks within containers.

The idea that wide alignment would be different than 1100px at any point based on type or size of a block's container would be an unintuitive behavior for every user or editor I work with. Just as having the font size Large result in a different font size based on the size or type of container would be unintuitive. They expect blocks to always work the same, whether they're top-level blocks or blocks inside other blocks. This is the message I'm seeing from everyone who works directly with users (all users, but especially less tech-savvy ones) on this board in multiple threads related to this issue.

But, because content widths need to be set for each container in a block theme, and we can’t have “wide” or “full” alignments without a content width set, in block themes those “wide” and “full” controls only appear on children of blocks that have a content width set.

The idea that every container needs to have its content width custom-defined just seems like an answer searching for a problem. Needing to define the content width of every container is too much flexibility to offer as a default. It's nice that it has become an option for the folks who want it, but for people developing basic content, it's just a roadblock. I don't see myself ever using this feature, and would prefer to be able to fully turn it off.

Simply install Twenty Twenty-Two, add a group block that is full width, give it a background color, and add a paragraph within that block. That is one of the most common use-cases for a group block by my users - providing a background color behind a block of content. By default, under the current paradigm, that paragraph is pushed to be the full width of the page. That is a bizarre default choice, and would be incredibly confusing to any of the content managers I support.

I've outlined one possible solution here: #36082 (comment) but there have been many very good suggestions.

I appreciate that you are looking into this and am very hopeful that at least a change in the default to Inner blocks use full width is in the cards for WP 6.1!

tellthemachines · 2022-07-19T08:44:56Z

Thanks for the feedback @eric-michel !

I assume you mean the new default would set Inner blocks use full width to off.

Yes, that's what I mean.

The idea that wide alignment would be different than 1100px at any point based on type or size of a block's container would be an unintuitive behavior for every user or editor I work with.

Agreed! How it works currently, wide alignment is always the same value (say 1100px). But if the container of the wide aligned block is narrower than that value, the block will respect the width of the container, so it will be narrower than 1100px. If the container expands, those 1100px will be respected. I guess it works more as a max-width than a fixed width, which also make sense in the context of smaller screen sizes.

If I understood your comment in #36082 correctly, you propose that we shouldn't display the "wide" alignment option on blocks that are inside containers narrower than the "wide" value. The obstacle to doing that is we have no way of knowing how wide the container is, because not all containers have alignment set. In some containers, it doesn't make sense to have alignment, because their width is responsive.

The classic example of this with Core blocks is a layout using Columns. Say I have a column that takes up 50% of the screen; depending on screen size, that column might need its content width restricted, and it might be able to accommodate a wide width, but on a smaller screen its width might compute to 500px, in which case all its contents will take up its full width. The contents of this column should still have wide and full alignment options, because on large screens they will actually be useful.

The idea that every container needs to have its content width custom-defined just seems like an answer searching for a problem. Needing to define the content width of every container is too much flexibility to offer as a default. It's nice that it has become an option for the folks who want it, but for people developing basic content, it's just a roadblock. I don't see myself ever using this feature, and would prefer to be able to fully turn it off.

That's a good point! We're also discussing how to approach theme controls for user-set content width here.

eric-michel · 2022-07-19T19:39:20Z

@tellthemachines this is a super helpful conversation!

Agreed! How it works currently, wide alignment is always the same value (say 1100px). But if the container of the wide aligned block is narrower than that value, the block will respect the width of the container, so it will be narrower than 1100px. If the container expands, those 1100px will be respected. I guess it works more as a max-width than a fixed width, which also make sense in the context of smaller screen sizes.

I'm glad you mentioned this specifically because I think it drives to the core of where folks differ between supporting the old mechanism (just having all alignment options always available) vs supporting the new paradigm (needing to define alignment options on a container-per-container basis).

We built our theme around the idea of width alignments as a simple definition of max width, not absolute width. This is fortunately supported by the very helpful descriptive text under the alignment controls:

(from Twenty Twenty-Two)

This concept has been super straightforward for our users, and I've never gotten a question about why, for instance, a block set to alignwide inside a standard alignment container does not extend to 1000px and is instead held to 650px. It seems intuitive to them that the size of the container gets the priority there in terms of constraint. This is where I'm coming from when I say that this seems like a solution in search of a problem.

Of course, that's simply my subjective experience, which is absolutely limited. I imagine somewhere this has been a pain point for someone and that has inspired this change. However, so far, most of the comments I've seen from users and folks who support users is that the older paradigm was more intuitive.

The classic example of this with Core blocks is a layout using Columns. Say I have a column that takes up 50% of the screen; depending on screen size, that column might need its content width restricted, and it might be able to accommodate a wide width, but on a smaller screen its width might compute to 500px, in which case all its contents will take up its full width. The contents of this column should still have wide and full alignment options, because on large screens they will actually be useful.

I definitely see what you mean with the example above, but I think that problem could easily be extended to top-level blocks. Ignore containers for a moment, and imagine someone editing a page on their tablet at 900px width. If they add a cover block to the top level of their page, they should still have access to the alignwide option despite their personal screen not being wide enough for it to take effect.

In that vein, I would add to my linked proposal that all alignments that could theoretically be useful at an infinite screen width should be made available. So, in your example above where a columns block is set to alignfull which means its columns can (theoretically) become infinitely large as well, all alignment options would be available inside of them. Just as all alignment options are available at the top level of the editor even on a screen that is too small to use them.

Honestly, I would also be totally fine for all alignment options to always be available, as they are in non-theme.json themes. My proposal was mainly an attempt to try and find a middle ground for folks who were concerned with something like alignwide being selectable in a child block for a standard aligned parent. But again, it's not clear to me how often that is actually causing confusion amongst users. I just know from my personal experience that it isn't a problem for mine.

Simbaclaws · 2022-07-19T20:51:38Z

Question:

How do I add support for these types of layouts within my custom block theme that I am making?

Whenever I set a layout in a single post or single page. That single post or page doesn't have the styles applied it should (max-width for example).
Which class names am I missing to get this to work by default?

Is there any documentation on setting up custom layouts for your block themes?

tellthemachines · 2022-07-20T08:28:44Z

I definitely see what you mean with the example above, but I think that problem could easily be extended to top-level blocks. Ignore containers for a moment, and imagine someone editing a page on their tablet at 900px width. If they add a cover block to the top level of their page, they should still have access to the alignwide option despite their personal screen not being wide enough for it to take effect.

Sure, provided there is already a content width defined on the container (this is the case with the Post Content block in most block themes; that's why we usually have wide and full options available on top-level blocks inside the post editor). If there is no content width defined, all blocks go full width, because that's what HTML does by default. In that case, wide and full options are unnecessary, because all blocks are already full width. Does that make sense?

I'm looking into changing the default on at least some of the blocks with layout enabled (Group, Post Content and Column are the likeliest candidates for now). Let's see how that works, and iterate from there!

Is there any documentation on setting up custom layouts for your block themes?

@Simbaclaws your theme needs to set values for content and wide widths. These docs should help.

eric-michel · 2022-07-20T19:36:09Z

Sure, provided there is already a content width defined on the container (this is the case with the Post Content block in most block themes; that's why we usually have wide and full options available on top-level blocks inside the post editor). If there is no content width defined, all blocks go full width, because that's what HTML does by default. In that case, wide and full options are unnecessary, because all blocks are already full width. Does that make sense?

I've read this a few times and I think I get what you're saying, but am not positive, so I apologize if I end up with an unproductive response!

I think what you're saying is that the Post Content block has a content width (meaning a max-width of its child blocks) set by default via contentSize in theme.json. And thus, its children get that max-width applied, and also have the wide and full alignment options available. But other blocks containers (like group and column) don't have a child max-width defined, so having alignment controls doesn't make sense in that context because all children will be full width, as is HTML's default for block elements.

In that case (assuming I'm interpreting you correctly), I guess what's really confusing to me is the decision to make contentSize the default max-width of only the direct children of the Post Content block, and not the direct children of all container blocks.

I'm coming at this from the perspective of using Gutenberg a lot before theme.json existed, or was widely adopted. Our theme determines a standard max content width, and applies it to all containers: entry_content > * (which I'd say is the equivalent of the Post Content block in this context) along with *[class*=inner-container] > *, .wp-block-column > * etc.

This is also how the Twenty Twenty-One theme does it, which is actually where we got that standard from. Twenty Twenty-One's implementation made sense - it defined a max-width (in the form of the CSS custom prop --responsive--aligndefault-width) and applied it to the children of (almost) all containers, including entry_content, cover, and group blocks (it didn't apply it to column blocks, which in my opinion is an error). This created a simple, predictable standard that allowed rapid content development with the confidence that content would line up nicely, including nested content.

You're saying "If there is no content width defined, all blocks go full width..." but my question is: why is there no content width defined? At some point, the sensible standard set by Twenty Twenty-One (a standard max-content width applied to
all content, including nested content) was abandoned in favor of requiring every container to have its content width custom set. Can contentSize in theme.json just apply to all content, as would seem most intuitive?

From my perspective, the most intuitive solution is to apply contentSize as a max-width to all content in the editor (with a couple notable exceptions, like the columns block should not limit the size of column blocks). If the user wants that content to be larger, they can make it larger by setting it to wide or full alignment. If the problem is that more alignment options are needed, then allow for additional alignment options to be added in theme.json. Custom setting the standard max-width for the children of any given container seems like too much flexibility (although simply being able to turn off the feature would be great).

I realize this is mostly an academic discussion because you said you're exploring changing the defaults of some container blocks which would largely resolve this issue, but I'm actually interested in the answers to these questions because it's entirely possible I'm missing something that makes this shift required (especially related to block themes, since I have not done much with those) and am hoping to learn more.

tellthemachines · 2022-07-21T09:08:56Z

I think what you're saying is that the Post Content block has a content width (meaning a max-width of its child blocks) set by default via contentSize in theme.json. And thus, its children get that max-width applied, and also have the wide and full alignment options available. But other blocks containers (like group and column) don't have a child max-width defined, so having alignment controls doesn't make sense in that context because all children will be full width, as is HTML's default for block elements.

Not quite! Sorry if I was unclear.

Post Content is the same as the other block containers: by default, no content width is defined on it. What happens is that most block theme authors set the Post Content block on their themes to respect the theme content width. That's a two part process:

The theme defines a content width (and usually a wide width too) in its theme.json
The Post Content block in the single template is configured, either via the Layout panel or by directly editing the block attributes in the HTML, to "inherit" the content width.

So when we start building a block theme, or create a new template in the site editor, no block has any content width. I guess the intention is to replicate how unstyled HTML works, and then the theme author configures everything to their liking. This makes sense, to a certain point, when we're building a theme from scratch, but doesn't make as much sense when we're editing content inside the post editor, where we expect a content width to already be defined by the theme.

From my perspective, the most intuitive solution is to apply contentSize as a max-width to all content in the editor (with a couple notable exceptions, like the columns block should not limit the size of column blocks).

Definitely, as long as the theme defines a content width (which most, if not all, themes do 😄 )

I realize this is mostly an academic discussion because you said you're exploring changing the defaults of some container blocks which would largely resolve this issue, but I'm actually interested in the answers to these questions because it's entirely possible I'm missing something that makes this shift required (especially related to block themes, since I have not done much with those) and am hoping to learn more.

Totally understand, it helps to know how these things work under the hood, especially when we use them all the time!

eric-michel · 2022-08-05T17:06:41Z

@tellthemachines thanks for all the really helpful responses! I'm really excited that you'll be swapping the defaults on some blocks to allow them to inherit the site's alignments by default. That will largely solve our problem and allow us to adopt theme.json.

I'm looking into changing the default on at least some of the blocks with layout enabled (Group, Post Content and Column are the likeliest candidates for now). Let's see how that works, and iterate from there!

It would be awesome if you added the cover block to this list as well!

Do you think it's possible that these changes could get implemented, tested, and merged before the feature freeze of WP 6.1? We have a very large site we're looking to develop and launch in the fall, and I would love to be able to use some features currently gated behind theme.json but am concerned our client will be very thrown off by the current state of alignment settings.

Nevermind, I see you already have PRs in process, which is super exciting!

tellthemachines · 2022-08-08T07:38:45Z

It would be awesome if you added the cover block to this list as well!

We won't be able to add the cover block just yet, because it's not using the layout controls. I see there's a PR that's been open for a few months (#37662); it's not a straightforward problem to solve because of how the block is structured (its child blocks are not direct descendants of the wrapper, so the layout styles would have to be applied to an inner container). But we'll get there eventually! It definitely makes sense for Cover to have the same layout controls as other containers.

tellthemachines · 2022-08-22T05:09:05Z

#42763 should have solved the majority of issues mentioned in this thread. Group blocks will now have content width by default, so there won't be any jarring difference in alignment controls for blocks contained in them.

Note that I only applied the change to Group so far; this way we can see how the solution works before changing things for other blocks.

For the Cover block mentioned above, I opened #43140 with details on what we need to have in place so we can use Layout with it.

Thanks for all your input folks!

CreativeDive · 2022-08-28T14:24:44Z

@tellthemachines I can see in Gutenberg 14 RC2 the options "wide" and "full" are now available for nested blocks inside a core/group block. I wonder how we can test this for our custom blocks. "wide" and "full" are still not available for nested blocks inside a custom container block.

Is there a way to activate this experimental feature in the block.json file for our custom blocks?

tellthemachines · 2022-08-28T22:12:54Z

@CreativeDive in your custom container block's block.json, you'll need to add "__experimentalLayout": { "type": "constrained"} inside the "supports" object.

One thing to consider: if the custom block is already being used out in the wild, this will break back compat for existing blocks, because it will set that layout type on them by default. If you wish to preserve back compat for existing blocks, have a look instead at how we handled the Group block in #42763, and let me know if you have any questions!

CreativeDive · 2022-08-29T05:46:32Z

@tellthemachines thank you. Yes, I tried that. But unfortunately that doesn't seem to work.

"supports": {
    "__experimentalLayout": { 
        "type": "constrained"
    }
}

The "Inner blocks respect the width of the content" option is disabled by default as expected, but the "wide" and "full" options are still unavailable for inner blocks.

EDIT: I assume the "wide" and "full" options should be available by now, is that correct?

CreativeDive · 2022-08-29T07:34:16Z

@tellthemachines Unfortunately I only got around to it later and for me there are a few questions and ambiguities.

Layout definition

The layout definition always gives us two input fields:

Content width
Width width

First point, not working properly for me here, if all inner blocks are restricted and don't have the wide option available, then why is the Width width input field showing?

The question is, can this happen? If yes, then Width width field should not be available in this case.

How should it basically work?

My basic understanding on this topic is the following and I think this is what everyone wants:

When a container block specifies that inner blocks should conform to a specified content width, options such as wide and full may not be available.

If a container block does not have a specific content width, wide and full options should be available for inner blocks.

The unavailable wide and full options for inner blocks were an issue

It's more common that within a "full" width block, I want to set an inner block to "wide" so that that block is slightly wider than all the other inner blocks. But that was no longer possible.

It would be important for this to be possible again in principle.

What is the current status now?

In version 14 of Gutenberg something has changed in this regard. But I'm still not sure if I understand it correctly and if it works as it should?

I want the freedom to redefine "full" and "wide" for inner blocks and not be constrained.

EDIT: I just recently switched to using theme.json entirely. Using theme.json is a win in almost every way. The only pain I have with this is that wide and full are no longer available for inner blocks.

CreativeDive · 2022-08-29T11:56:58Z

@tellthemachines I think the different class names to detect layout option in the CSS way can be very helpful:

OFF - Inner blocks respect content width

Default (Nested blocks will fill the width of this container.)

is-layout-flow

ON - Inner blocks respect content width

Layout is on without defined sizes (Nested blocks use theme content width with options for full and wide widths.)

is-layout-constrained

ON - Inner blocks respect content width

Layout is on with defined sizes (Nested blocks use theme content width with options for full and wide widths.)

is-layout-constrained.wp-container-*

EDIT: But with none of these 3 settings, my nested blocks in my custom container block get a wide and full option. Is this a bug in RC2?

CreativeDive · 2022-08-29T12:14:51Z

@tellthemachines it seems there is a bug with the custom content width fields. If I enter a value the fields are displayed two times in the sidebar.

Aug-29-2022.14-12-47.mp4

tellthemachines · 2022-08-29T23:06:09Z

Thanks for the feedback @CreativeDive !

The "Inner blocks respect the width of the content" option is disabled by default as expected, but the "wide" and "full" options are still unavailable for inner blocks.

If the block's layout is set to "constrained", then "Inner blocks respect content width" should be enabled. Is that working for you?

The wide and full options for the inner blocks will only appear if a content width is defined, which can be done by the theme, in the global styles interface or on the block itself.
Check if your theme's theme.json has something like "layout": { "contentSize": "840px", "wideSize": "1100px"} in its settings object. If it doesn't, and you haven't defined content sizes anywhere in the block or the global styles editor, then "wide" and "full" options won't appear for children.

A simple test is adding a value to the custom content width field. If you do that, "wide" and "full" should become available on the children.

@tellthemachines it seems there is a bug with the custom content width fields. If I enter a value the fields are displayed two times in the sidebar.

Yes, I can reproduce that. Definitely a bug 😅 Looking into it now.

CreativeDive · 2022-08-30T06:23:06Z

The wide and full options for the inner blocks will only appear if a content width is defined, which can be done by the theme, in the global styles interface or on the block itself.
Check if your theme's theme.json has something like "layout": { "contentSize": "840px", "wideSize": "1100px"} in its settings object. If it doesn't, and you haven't defined content sizes anywhere in the block or the global styles editor, then "wide" and "full" options won't appear for children.

@tellthemachines thank you, it's very important to know how the things should be working to test if everything is working fine or not.

Now I can get you the full bug report.

Test Case 1: Custom container block

"layout": { "contentSize": "840px", "wideSize": "1100px"} is set in theme.json.
"__experimentalLayout": { "type": "constrained" } is set in the block.json inside the support object.
Add a new block (in that case my custom container block).
----> "Inner blocks respect content width" is NOT enabled by default.
----> Is this a bug ? 🐛

Test Case 2: Custom container block

Same like in test case 1.
But additionally "attributes": { "layout": { "type": "object", "default": { "type": "constrained" } } }, is set in the block.json
Add a new block (in that case my custom container block).
----> "Inner blocks respect content width" is enabled by default.
Copy the block and look inside the block code:
----> The block code does not contain"type":"constrained"
--------> I think that is correct and expected.

Test Case 3: Custom container block

Same like in test case 1.
But additionally "attributes": { "layout": { "type": "object", "default": { "type": "constrained" } } }, is set in the block.json
Add a new block (in that case my custom container block).
----> "Inner blocks respect content width" is enabled by default.
Set a custom content size in the sidebar field.
----> The inner blocks get the width from the content size field
Copy the block and look inside the block code:
----> The block code contains "type":"constrained"
--------> I think that is correct and expected.
Add a core/cover block to the inner block component of this block.
You say when a content size is entered, "wide" and "full" should be available for child blocks. I wish it would be like this.
----> But it does not work! It seems it's a BUG! 🐛 ‼️

I will now test the same with the core/group block to see a comparison.

CreativeDive · 2022-08-30T06:46:04Z

@tellthemachines Here is the same report, but instead I use the core/group block.

Test Case 1: Core group block

"layout": { "contentSize": "840px", "wideSize": "1100px"} is set in theme.json.
"__experimentalLayout": { "type": "constrained" } is set in the block.json inside the support object.
Add a new block (in that case the core/group block).
----> "Inner blocks respect content width" is enabled by default.
--------> I think that is correct and expected.
Copy the block and look inside the block code:
----> The block code contains "type":"constrained"
--------> I think that is correct and expected.
Add a core/cover block to the inner block component of this block.
You say when a content size is entered, "wide" and "full" should be available for child blocks.
----> But, the "wide" and "full" options are available also without set a content size in the sidebar
----> Is this a bug ? 🐛

Test Case 2: Core group block

Same like in test case 1.
Set a custom content size in the sidebar field.
----> The inner blocks get the width from the content size field
You say when a content size is entered, "wide" and "full" should be available for child blocks.
----> The "wide" and "full" options are available.
--------> I think that is correct and expected.

@tellthemachines It's nice that the core/group children's blocks now also have "wide" and "full" available. But it is NOT the case for our custom blocks. But it must be available for inner blocks. This is exactly what I and many others expect. Can you reproduce this?

SIDE NOTE: If my custom container block is nested inside the core/group block, the "wide" and "full" are available. But not inside my custom container block. Is there a limitation and can it be fixed or activated by an additional setting?

CreativeDive · 2022-08-30T12:59:49Z

@tellthemachines Another bug. 🐛

Adding a new custom container block, with the following settings in the block.json:

"attributes": { "layout": { "type": "object", "default": { "type": "constrained" } } },
"__experimentalLayout": { "type": "constrained" }

The block starts with "Inner blocks respect content width" is enabled by default.
--------> I think that is correct and expected.
The block class name in the block editor source code contains is-layout-constrained.
--------> I think that is correct and expected.
Save the post and look at the front end output.
The block class name in the front end source code contains is-layout-flow.
----> It's a BUG! 🐛 ‼️

Only if I manually change the "Inner blocks respect content width" toggle to OFF and back to ON, the expected class name is-layout-constrained appears in the front end block output.

CreativeDive · 2022-08-31T04:30:47Z

@tellthemachines @andrewserong should I create a new issue?

andrewserong · 2022-08-31T07:33:58Z

@CreativeDive, yes please — another issue would be great so that we can look at follow up issues in isolation. Thank you for writing up the bug and test instructions!

skorasaurus added [Type] Bug An existing feature does not function as intended Global Styles Anything related to the broader Global Styles efforts, including Styles Engine and theme.json labels Jul 20, 2021

thetwopct mentioned this issue Jul 28, 2021

Convert theme options to theme.json cncf/cncf.io#449

Closed

crs1138 mentioned this issue Aug 5, 2021

Wide/Full alignment options no longer appear on blocks with Gutenberg 11.2 whilst using theme.json #33876

Closed

3 tasks

mrwweb mentioned this issue Nov 4, 2021

Container Style Element Breaks Expected CSS Selectors #36053

Closed

skorasaurus mentioned this issue Nov 14, 2021

Allow ability to give innerblocks alignment control when using theme.json #36465

Closed

tellthemachines mentioned this issue Jul 28, 2022

Try "constrained" content width as new layout type #42763

Merged

justintadlock mentioned this issue Aug 1, 2022

Clarify issue with how layouts work when using theme.json WordPress/Documentation-Issue-Tracker#392

Closed

andrewserong mentioned this issue Aug 3, 2022

Tracking: extend layout options in Gutenberg #39336

Closed

30 tasks

mrwweb mentioned this issue Aug 16, 2022

Proposal: Standardized block markup, theme.json design tokens, and CSS classes to improve interoperability #38998

Open

tellthemachines closed this as completed in #42763 Aug 22, 2022

tellthemachines mentioned this issue Aug 29, 2022

Fix display of width controls for legacy layouts #43688

Merged

CreativeDive mentioned this issue Aug 31, 2022

Block layout: Wide and Full are not available for custom container blocks if __experimentalLayout: constrained is used #43731

Closed

tellthemachines mentioned this issue Oct 28, 2022

Add constrained/flow layout to Cover block. #45326

Merged

Cannot apply wide or full widths to nested blocks with theme.json applied #33374

Cannot apply wide or full widths to nested blocks with theme.json applied #33374

Comments

pattyok commented Jul 12, 2021

Description

Step-by-step reproduction instructions

Expected behaviour

Actual behaviour

Screenshots or screen recording (optional)

Code snippet (optional)

WordPress information

Device information

getdave commented Jul 20, 2021

getdave commented Jul 20, 2021

pattyok commented Jul 20, 2021

thetwopct commented Jul 28, 2021

youknowriad commented Jul 30, 2021

pattyok commented Jul 30, 2021 • edited

youknowriad commented Jul 30, 2021

pattyok commented Jul 30, 2021

youknowriad commented Jul 30, 2021

pattyok commented Jul 30, 2021

youknowriad commented Jul 30, 2021

youknowriad commented Jul 30, 2021

pattyok commented Jul 30, 2021

pattyok commented Jul 30, 2021

youknowriad commented Jul 30, 2021

pattyok commented Jul 30, 2021 via email

youknowriad commented Jul 30, 2021 • edited

bethalessi commented Nov 15, 2021

bethalessi commented Nov 15, 2021

My example situation

bethalessi commented Nov 15, 2021

mrwweb commented Nov 15, 2021 • edited

pattyok commented Nov 15, 2021 via email

bethalessi commented Nov 16, 2021

youknowriad commented Nov 16, 2021

eric-michel commented Jul 18, 2022

tellthemachines commented Jul 19, 2022

eric-michel commented Jul 19, 2022

Simbaclaws commented Jul 19, 2022

tellthemachines commented Jul 20, 2022

eric-michel commented Jul 20, 2022

tellthemachines commented Jul 21, 2022

eric-michel commented Aug 5, 2022 • edited

tellthemachines commented Aug 8, 2022

tellthemachines commented Aug 22, 2022

CreativeDive commented Aug 28, 2022

tellthemachines commented Aug 28, 2022

CreativeDive commented Aug 29, 2022 • edited

CreativeDive commented Aug 29, 2022 • edited

Layout definition

How should it basically work?

The unavailable wide and full options for inner blocks were an issue

What is the current status now?

CreativeDive commented Aug 29, 2022 • edited

OFF - Inner blocks respect content width

ON - Inner blocks respect content width

ON - Inner blocks respect content width

CreativeDive commented Aug 29, 2022

tellthemachines commented Aug 29, 2022

CreativeDive commented Aug 30, 2022 • edited

Test Case 1: Custom container block

Test Case 2: Custom container block

Test Case 3: Custom container block

CreativeDive commented Aug 30, 2022 • edited

Test Case 1: Core group block

Test Case 2: Core group block

CreativeDive commented Aug 30, 2022 • edited

CreativeDive commented Aug 31, 2022

andrewserong commented Aug 31, 2022

pattyok commented Jul 30, 2021 •

edited

youknowriad commented Jul 30, 2021 •

edited

mrwweb commented Nov 15, 2021 •

edited

eric-michel commented Aug 5, 2022 •

edited

CreativeDive commented Aug 29, 2022 •

edited

CreativeDive commented Aug 29, 2022 •

edited

CreativeDive commented Aug 29, 2022 •

edited

CreativeDive commented Aug 30, 2022 •

edited

CreativeDive commented Aug 30, 2022 •

edited

CreativeDive commented Aug 30, 2022 •

edited