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

pattyok commented 3 years ago

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 commented 3 years ago

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

https://github.com/WordPress/gutenberg/blob/fc243d2e9814058db1620a6c6cb0429ddac0853b/packages/block-editor/src/hooks/align.js#L174-L175

getdave commented 3 years ago

@pattyok Try adding the following to your theme.json

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

That should restore those alignment controls.

pattyok commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

youknowriad commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 https://github.com/WordPress/gutenberg/issues/33374#issuecomment-890023576, or unsubscribe https://github.com/notifications/unsubscribe-auth/AASODOCJMOYBC6MUOXDJX4TT2LKDFANCNFSM5AHZPRXQ .

youknowriad commented 3 years ago

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 commented 2 years ago

@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 commented 2 years ago

@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 commented 2 years ago

@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 commented 2 years ago

@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 commented 2 years ago

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 https://github.com/WordPress/gutenberg/issues/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 https://github.com/WordPress/gutenberg/issues/33374#issuecomment-968928762, 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 commented 2 years ago

@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 commented 2 years ago

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.

bethalessi commented 2 years ago

@youknowriad I added that to "supports" in block.json and the layout toggle appears, but the innerblocks still don't have wide/full alignment controls. Am I missing something? Is my code in the wrong place?

"supports": { "__experimentalLayout": { "contentSize": "800px", "wideSize": "1000px", "inherit": true } },

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.

I hear you, but this is a theme for a client with directions from me on how to use their custom blocks. Making the experience easy for my clients to add blocks without thinking about styling/layout is my goal, so I'm looking for control in order to do that. Thank you!

Alexius08 commented 2 years ago

I could also confirm this. I was making a custom block that uses InnerBlocks, and I wanted the root block's alignment setting to be applied to all blocks inside it. For both the Twenty Twenty and Twenty Twenty-One themes, the bug described above happens unless the inner blocks themselves have those settings (which can't always be guaranteed) and I pass to them the value set in the root block . Twenty Nineteen doesn't have this problem, however.

NicoHood commented 2 years ago

Are there any updates on this? I came here from the astra theme bug report. I am really confused why those layout options are not available anymore, and I have no idea how to get them back, without modifying the theme itself.

Will this be reverted any time soon?

pattyok commented 2 years ago

Another example of why this decision to allow full or wide blocks should be left up to the theme editors and not set in core.

markhowellsmead commented 2 years ago

I'm also experiencing this issue with 5.9 when using a columns block within an InnerBlocks element. The nested columns block doesn't receive the 'data-align' ('wide') attribute in the editor or the control to allow choosing wide/full. However, the code output on the website is correctly assigned the alignwide class.

(Code abbreviated for readability.)

<InnerBlocks
    allowedBlocks={…}
    template={[
        [
                'core/columns',
                { columns: 2, align: 'wide' },
                …

NicoHood commented 2 years ago

Is there any workaround or code snippet that I can use to get back this feature without creating a child theme without this new theme.json file?

nickfmc commented 2 years ago

The biggest issue I'm seeing with this change is that it broke the way 3rd party container blocks work. Two big ones Kadence blocks and Toolset both have not added support for the new setup and the update has made the wide alignment options disappear from nested blocks in their systems. Is there documentation on how to support the new "inherit default layout" "Layout controls" when creating a block, so we can pass this information along to plugin developers?

Luehrsen commented 2 years ago

Let me chime in here and report that I stumbled over this today. To be perfectly clear: This is super unintuitive and horrible behaviour.

This is how we are trying to solve this regression at the moment. https://gist.github.com/Luehrsen/c4aad3b33435058c19ea80f5f1c268e8

NicoHood commented 2 years ago

@Luehrsen This works for me, if I have columns inside a group. It does not work, if I have a group inside a cover. That should be fixed as well.

premanshup commented 2 years ago

@Luehrsen I'm facing the same issue as @NicoHood. This is working for the Group block but not for the cover block. I tried passing const haystack = ['core/group', 'core/cover']; but no luck.

eric-michel commented 2 years ago

I recently started experimenting with theme.json in our theme to gain access to some of the features gated behind its use and ran into this same issue.

If the intention of this change is to reduce confusion and improve the editing experience, I think it caused more harm than good. Please let me know if my summaries below are inaccurate, as I may not have a full understanding of the issue. Let's say that we've defined 3 alignments: default sets a max width of 600px, wide sets a max with of 1000px, and full sets a max width of 100%.

In the previous paradigm:

All blocks (parent or child) used default alignment by default, and all blocks that supported wide and full alignment were always able to have those alignments applied.
In some nesting cases, wide and full alignment would not actually provide any difference to the layout, because the container limited the width of the nested item. For instance, setting a columns block to wide alignment when it is inside of a group block set to default alignment would not alter the columns width in any way, because the group block is hard-limiting the columns block to 600px. This is the problem this change was intended to fix.

I can understand why this issue might be a bit confusing, but I also think it's fairly intuitive. If I set a block to wide (1000px) but it's inside a block set to default (600px) I don't expect the child block to be larger than its parent.

In the current paradigm:

All top level blocks behave the same as they did before.
By default, all nested blocks now fully expand to fit their container. This is a very bad standard, at least for our use case. We very frequently use group blocks to add a full width container and provide a background color with standard paragraph content inside. Now all of the paragraph blocks within that container are full width, rather than a reasonably-sized default width. Not only does this look bad from a layout perspective, it violates accessibility standards.
This can be fixed by manually setting each group block to inherit default layout. Now the nested blocks behave as before: defaulting to the sensible 600px max width, and allowing wide and full alignments to be applied. Which now reintroduces the "problem" of the previous paradigm - if you do this with a default-aligned group block, you once again can set a child block to wide alignment with no effect.
Furthermore, columns and cover blocks do not currently have the inherit default layout option. I cannot add a full width cover block with any paragraph blocks as direct children, because I cannot set them to a sensible max width. I instead have to add a group block within the cover block, set it to inherit default layout, and add my content there.

Based on the way we typically use container blocks, we would be using inherit default layout the vast majority of the time, which does nothing to solve the issue of the previous paradigm (the possibility of applying alignments that have no effect) while also adding a step we have to take for every container block we use. There is only downside to this change.

Please let me know if I'm overlooking anything here - it's entirely possible I haven't fully explored the new changes and there are actually better ways to deal with this, or benefits I'm not aware of. I'm open to being convinced if I'm missing something!

nickfmc commented 2 years ago

the ideal solution would have been to detect if a parent block is set to wide, then only show standard and wide on child blocks. and if a parent is set to standard, hide both wide and full. I think this whole problem stems from Automattic originally using a theme site wrapper and then 100vw to allow full width blocks to break out of their container. instead of making the page 100% width and using a .entry-content > *:not(.alignfull) {} setup. Because this makes a very clear difference between 100% and "full width" and using CSS that causes an item to break out of it's parent is going to inherently be confusing when dealing with nested elements.

eric-michel commented 2 years ago

the ideal solution would have been to detect if a parent block is set to wide, then only show standard and wide on child blocks. and if a parent is set to standard, hide both wide and full.

I agree with this. It doesn't solve the possibility of having a block set to wide alignment inside of a column that is narrower than wide alignment allows, but I just really don't really think that's an issue worth addressing. I don't think most folks will think that a group block set to a 1000px wide alignment inside of a 500px wide column will be any wider than 500px.

That, or just revert it to the way it was originally working. Are many folks actually complaining about the way that it works now on non-theme.json sites with wide and full alignment always available even when in a container narrower than those options? We have a lot of clients who are not particularly tech-savvy. Many of them have been confused by various parts of editing via Gutenberg, but I've never heard confusion over the way that wide and full alignment works for nested blocks.

NicoHood commented 2 years ago

I am not sure if I understand correct, but I think some themes also support nested block width settings. Checkout the screenshots here: https://wpastra.com/docs/gutenberg-ui-improvements-with-astra/

Nevertheless, this "feature" should be reverted soon, please!

cbirdsong commented 2 years ago

I just finally dug into how all this works while testing theme.json with our starter theme. Echoing everyone above that this is a major regression in functionality. Here's an actual real world use case for nesting align wide/full items from our last project:

This is a cover block set to align full, containing a columns block (outlined in yellow) and a custom block (outlined in magenta): www easytigerusa com_ (2)

The columns block is align wide so that the edges line up with the edges of the content on the rest of the page: CleanShot 2022-03-11 at 15 03 32

The custom block is align full so that the cards can scroll horizontally off the edges of the window: www easytigerusa com_ (3)

This design would've either been compromised or discarded without being able to nest wide/full alignment inside other blocks.

NicoHood commented 2 years ago

Isn't there any hotfix or workaround (that fully works) that we could use?

Who do we need to ask to have a look at this again and fix it? @youknowriad @aduth @gziolo @ellatrix @jasmussen @jorgefilipecosta ???

eric-michel commented 2 years ago

@NicoHood Unfortunately, right now the only effective solution I've found is to not use theme.json. It's a shame because I'd like to start taking advantage of some of the new features, but it just doesn't seem ready for primetime yet.

nickfmc commented 2 years ago

Isn't there any hotfix or workaround (that fully works) that we could use?

Who do we need to ask to have a look at this again and fix it? @youknowriad @aduth @gziolo @ellatrix @jasmussen @jorgefilipecosta ???

well alignment is just class driven, so the workaround would be theme specific, I've added patterns with classes applied for things that I can't do the same way. So you create the patterns for all the different container/wrapper layouts you think you will need.

NicoHood commented 2 years ago

@nickfmc Thanks! Could you give us an example on how to do that?

nickfmc commented 2 years ago

@nickfmc Thanks! Could you give us an example on how to do that?

well as mentioned it would be theme specific for instance some themes may not have the class of alignwide for certain nested blocks depending how they are setup, but all that the alignment toggle does is standard has no class wide adds alignwide and full adds alignfull so if you just add that class on the advanced tab of the block you might be able to get the effect you would have previously. This is why blocks that were setup before the update didn't and dont break when you update the page because that class is still applied to the block. I like to setup the basic layout and create a block pattern https://richtabor.com/build-block-patterns/ from it.

eric-michel commented 2 years ago

We've had several major versions of WP released without this issue being addressed.

Just a reminder as to how unusable this makes the editor: in the Twenty Twenty-Two theme, adding a group or cover block as full width (a very common use case for those blocks) causes all content within that block to ignore the contentSize property in theme.json and instead extend full width. This includes paragraph blocks, which is a massive accessibility problem.

In the case of the group block, the unintuitive Inherit default layout option has to be manually selected each time a full width group block is added to revert to expected functionality, but in the case of the cover block, no option even exists to fix this without adding additional intermediary blocks to force proper alignment.

Beyond the obvious a11y problems, this is also something that will throw my users for a loop. My goal is to always provide them with an intuitive interface with sensible defaults that reduce friction for content editing. This does the opposite. My users will expect blocks within a full width group block to behave the way blocks behave in the top level of the editor.

This is singlehandedly preventing us from using theme.json in our main parent theme, and gating us out of lots of new Gutenberg features that we'd love to use.

I guess my main question is: is a fix being considered or is this "working as intended" as @youknowriad said?

tellthemachines commented 2 years ago

This is a tough one because it’s not really a bug, but a known side-effect of the implementation, documented in the theme handbook: Additionally, the alignment mechanism for “full” and “wide” blocks works differently with a theme.json present and should be considered.

Apologies in advance as I'm going to repeat some of what's already been stated above, but I want to make sure we're all on the same page!

Current state

The logic is that for a “wide” or “full” alignment to exist, there has to be a content width defined, because something can only be “wide” in relation to a “regular” width, and “full” width is the default state of unstyled HTML.
Classic themes usually define their content width, wide and full alignment styles in the theme stylesheet, making use of the alignment classes added by the controls in the editor. Because this logic is assumed to be taken care of by the theme, the editor always displays the wide/full controls on any blocks that can be full or wide aligned.
Block themes, on the other hand, are expected to define content and wide widths in their theme.json, and then use the Layout panel in the editor to set those widths on individual containers (or set custom widths). With those settings in place, the styles to make them work are applied by core, so the theme doesn’t have to define them in its stylesheet.
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 problems

One problem is that we’re using theme.json to detect if a theme is a block theme or not. So, if a classic theme has a theme.json, for content width/layout/alignment purposes the editor will treat it as a block theme. This is why an Image inside a Group block won’t show “wide” or “full” alignment options: in order for them to appear, we need to go into the Group block’s Layout panel in the sidebar:

and either uncheck “Inner blocks use full width” (used to be "Inherit default layout") or set a custom content width.

The other problem is precisely that content widths need to be set for each block individually. While this can make sense in a site-building context - we probably don't want our Header area to have content width - it might be that we do want content width to be set most of the time.

Potential solutions

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).

Would doing that solve this issue altogether?

Two things that I anticipate won't be solved by changing the default:

We wouldn't be changing anything for existing content; the new default would only apply for newly created blocks.
When a theme.json is detected, we also don't load the classic stylesheet in the post editor, so content with full/wide alignments might look a bit weird in the editor (I tested this by adding theme.json to Twenty Twenty One, and loading a post with both a regular width and a full-width Group block, with full-width Image blocks inside them; the content area loses its margins so everything sticks to the left of the screen.)

Another possibility would be: instead of making the "Layout" behaviour dependent only on the existence of theme.json, make it obey the same conditions as the site editor (I think that one depends on the existence of an index.html file). That way the behaviour wouldn't change at all for classic themes. We'd still have the problem of the classic stylesheet not being loaded in the post editor though.

Would be good to know everyone's thoughts on this!

eric-michel commented 2 years ago

@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: https://github.com/WordPress/gutenberg/issues/36082#issuecomment-1147856508 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 commented 2 years ago

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 commented 2 years ago

@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 commented 2 years ago

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?

WordPress / gutenberg