Group Block - Add inner container

[justintadlock]

The Group block should have a .wp-block-group__inner-container. This would be consistent with the .wp-block-cover__inner-container for the Cover block.

This is particularly important if theme authors want to do something like have a full-width group but keep the content contained. At the moment, I'm having to do this:

.wp-block-cover > * {
	// Reset everything to content width.
}

With no inner container and the specific design I'm working on, I'm also having to reset my inner wide and full aligns by targeting:

.alignfull .alignwide,
.alignfull .alignfull,
.alignwide .alignwide,
.alignwide .alignfull {
	// Reset align margins and width.
}

I haven't even tested or figured out how I'm going to handle left/right alignment yet.

With an inner container, I could literally cut all that back to target one selector and a couple of lines of CSS.

[sitesandsuch]

I just add another Group Block inside the Group Block if I need an extra container. I think this is in line with the simplicity of this block?

[justintadlock]

I just add another Group Block inside the Group Block if I need an extra container. I think this is in line with the simplicity of this block?

I don't think this would make for a good user experience. I can't imagine asking users to nest group blocks within group blocks, which is not intuitive at all.

It'd also only address the first issue outlined above.

[tmdesigned]

I experienced this same issue a couple of weeks ago ('section' block at the time) and did the nested block solution @sitesandsuch mentioned. It is indeed awkward and I almost didn't do it because of how hard it will be for the client to understand it. There is almost no way to explain the need for it to an end-user without explaining CSS; i.e. it's not really intuitively obvious why they need to have a "group within a group".

[aristath]

+1 from me here, I have the same issue as @justintadlock

[youknowriad]

This was discussed heavily and was decided that it's not the best path forward. Related discussions #14234

[justintadlock]

I read through that entire discussion and didn't see a final decision or any way to address the current problem as outlined in this ticket. I understand there are some larger implications about inner block alignment, which would be cool to have in the future. However, there's a real-world use case that needs to be addressed today.

We're talking about an extremely common layout here that is, in many cases, the actual block that will make Gutenberg useful for far more users than it is now. And, its HTML output is fundamentally useless in some theme designs.

I'm just talking about adding a simple <div> here, which can be left unstyled by themes that don't need it.

[kjellr]

I think there's some miscommunication around the intent of this. #14234 was specifically about letting users choose the width of an interior container. By adopting the approach outlined in #13964 (comment), we sort of sidestepped that issue. Blocks in a full-width group block now use the same width/spacing as their counterparts that live outside of the group block. This is expected and requires no additional controls.

The core of the proposal in this ticket is more about ease of implementation for theme developers. Here's a simplified scenario (loosely inspired by my adventures in getting the Twenty Nineteen patch working):

Today, entry-content essentially acts as a group block: all other blocks live inside of it. To ensure that blocks inside of entry-content appear as intended, many themes (most themes except for the Gutenberg Starter Theme I'd guess.) use some sort of max-width or margin/padding on entry-content.

When the Group block becomes full width, that becomes the block container, instead of entry-content. Since we want inner blocks in this case to share the same sizing/position as their counterparts outside of the Group block, we'd want to apply the same max-width/margin/padding that entry-content uses to a full-width Group block. However... this generally isn't possible, because unlike entry-content, it's important for a full-width block to take up 100% of the width of the page: If someone sets a background image/color for a full width group block, that needs to take up the entire width. So to get this working, theme developers need to write a second set of block styles to target inner blocks.

It's much easier to just show an example. Here's a simplified implementation of wide/full blocks today:

https://codepen.io/kjellr/pen/WWKEqN

Here's today's scenario, where there's no container div inside of the Group block. It works ok, but it requires some brand new styles + thinking to get the inner blocks to appear as intended (L28-35 in the stylesheet):

https://codepen.io/kjellr/pen/QPBgJV

Contrast that to a scenario where there is a separate container div inside of the Group block. In this case, no new styles are needed. The width + margin rules from entry-content are applied to the container too, and everything else "just works" with no further code changes:

https://codepen.io/kjellr/pen/vMaZeK

In general, I think this could be super-helpful. If themes didn't want/need to use this container, they could just leave it unstyled and it shouldn't interfere.

Interested in thoughts from @jasmussen on this too.

[kjellr]

I'll also note that this is the time to make this change, if we're going to: before a ton of themes have built in styles to support this block yet.

[jasmussen]

This is a really complicated issue.

One of the things we want to ponder is: what if in the future you could edit your whole page in the editor? Header, any sidebars you have, a footer, multiple content areas visible and editable (if you so choose), in one editor. While you would probably start with a template provided by the theme, consider a simple blank page which features a Header area, a Post Content area, and a Footer area. What would be the role of alignments in this interface? If I inserted a navigation block in the Header area, I would assume that this block spanned the full width of the header area by default, without having to press a "full wide" button first. I would assume that the theme would control the appearance and some of the rules surrounding the layout of this block. What would happen if I inserted a group block in this header area, what would happen? Would it even have any wide alignments available? How about blocks inside this group block?

Right now the group block is heavily optimized towards the use case described in #13964 (comment). I acknowledge that use case, I think it's real, but both in the name of simplifying things for the them author (as I understand is the point of this ticket, right?) but also for the user, it's worth asking the question: why should blocks inside the groupbehave differently to every other block that has nesting support? I.e. by being centered, they do behave differently from other nesting containers, and you can't currently create a paragraph that spans the whole width inside a full-wide group.

Some questions worth asking ourselves:

• What would be the simplest solution, technically, to let themes decide for the user whether contents should be in a centered column or not?
• Is there a seamless way we can give control to the user on this? If a user doesn't want blocks to be in a centered column inside the full-wide group, how would they accomplish this without CSS?
• At some point, a user is going to want a background color behind their full-wide columns block, and they'll nest it inside a Group to do that. Is it expected behavior that the user has to press the "full wide" alignment button inside the full-wide group?

Would it make sense for the group block to feature a toolbar button, or a sidebar switch, to toggle "center blocks inside"? What would it default to? Would this toggle simply toggle the classname Kjell suggests? What other solutions could we think about?

[justintadlock]

What would be the simplest solution, technically, to let themes decide for the user whether contents should be in a centered column or not?

An inner <div class="wp-block-group__inner-container">.

If there is no inner container, theme authors will take the implementation out of our hands. Themes are already using the solution that I posted above or something similar.

Is there a seamless way we can give control to the user on this? If a user doesn't want blocks to be in a centered column inside the full-wide group, how would they accomplish this without CSS?

Ideally, a user could have some control over the alignment of all inner blocks. There are two ways of doing this:

• Allow the inner container to have wide-width controls.
• Allow all blocks to have wide-width controls (many already do).

At some point, a user is going to want a background color behind their full-wide columns block, and they'll nest it inside a Group to do that. Is it expected behavior that the user has to press the "full wide" alignment button inside the full-wide group?

Yes, if there are no controls for the inner container.

Would it make sense for the group block to feature a toolbar button, or a sidebar switch, to toggle "center blocks inside"?
What would it default to?

That would provide a much more robust user experience.

I'd set it to centered by default. The default group alignment is not wide/full by default. I'd be all right with any alignment if the option is there.

---

I do think it's important to get the inner container for now. All these other ideas, while important to think about, can marinate and be iterated upon in future releases if necessary.

[kjellr]

Thanks as always for the thoughts, @jasmussen, and for the followup, @justintadlock.

One thing to keep in mind: The discussion in this thread seems to easily shift towards the question of whether child blocks of the Group block should be centered like top-level blocks, or if they should take up the full-width of their container at all times (or whether users should have a toggle or something to decide that).

I'm happy to have us talk more about that, but I also want to be clear that it's a bit tangental to the change suggested in this ticket. Currently, as per #13964 (comment), the recommendation is that themes do center these blocks, but that's currently being done without implementing this extra container div. So the proposed change wouldn't enforce something new — it'll just make it easier to implement the same recommendation we have today. It also won't restrict themes from having all child blocks take up the full-width of the Group block if they really want to, since the interior div won't ship with any styles.

All that said, Joen raised some good questions about the thinking behind this block, so happy to discuss! The most interesting question to me revolves around this bit:

it's worth asking the question: why should blocks inside the group behave differently to every other block that has nesting support?

I'm not sure I've actually thought about the problem that way! When writing #13964 (comment), I came at this from almost the opposite perspective: "Why should blocks inside the group behave differently to every other block outside of the group?"

I view the Group block as a fairly generic container. Unlike a header, footer, Media & Text block, or a Cover Image block, the Group is almost a totally unstyled wrapper around other totally standard blocks. With that in mind, it's currently designed to have interior blocks perform exactly the way they'd perform outside of the Group block. For example, you can't create a top-level paragraph that spans the full-width of a page, so you can't create a paragraph that spans the full page inside of a Group block either.

There's one important difference though: blocks inside of a Group will never break outside of their container. So if you want a true full-width block inside of a Group, you'll have to make the Group full-width first. This is primarily so that the boundaries of a group are clear. If we wanted, I could see us removing all alignment controls from the block itself though, so that it automatically used the width of its widest child... that may actually make more sense with the latest efforts to make "Group" an easy action when you have multiple blocks selected. In that case, you probably want the visual appearance of those blocks to change as little as possible when they become grouped.

I don't know the right answer, but I do think that it's okay for the Group block to focus on keeping the appearance/location/alignment of blocks exactly the same as if they were not grouped (so, centered in the text column in this case), while more opinionated parent blocks can enforce their own width/alignment preferences on child blocks.

[strarsis]

I am still using the section block from Atomic Blocks plugin because it offers two extra wrapper elements, which can be selected and styled.
A theme doesn't only provide the styles, it can also provide scripts and extra markup,
separation of content and theme is still ensured.
These Gutenberg blocks should offer generic primitives which the themes can use.
A group (formerly container) block should group content, how the theme handles this, like wrapping it in extra DIVs or adding SVGs, extra images, etc, should not be something the user has to think about at all.

[jasmussen]

Solid thoughts, Kjell. Given how much thought you've put into this, I'd probably defer to you on the actionable next step on this.

Also a good reminder to keep this on topic, sorry for taking it slightly out of the way. After the next thing, I promise I'll sway back to the path 😅

it's currently designed to have interior blocks perform exactly the way they'd perform outside of the Group block. For example, you can't create a top-level paragraph that spans the full-width of a page, so you can't create a paragraph that spans the full page inside of a Group block either.

I think this is the core of the matter for me. I'm thinking way ahead, and probably too far ahead. But to me, post_content is a block area. It also happens to be the entirety of the editor currently, but I believe that it will feel natural to expand this concept to include additional block areas in the future, including widget areas, headers, footers. But common to all of those areas are that you can insert blocks in them. If the group block suddenly centered content, if inserted inside one of those areas, that would be a weird experience.

But maybe the simple solution to that is implied in your comment: if the theme opts the post_content area into wide alignments, well then the group block inside that area behaves the same way. I.e. a header area would not provide wide alignments at all. Does this make sense?

[kjellr]

I'm thinking way ahead, and probably too far ahead. But to me, post_content is a block area. It also happens to be the entirety of the editor currently, but I believe that it will feel natural to expand this concept to include additional block areas in the future, including widget areas, headers, footers. But common to all of those areas are that you can insert blocks in them. If the group block suddenly centered content, if inserted inside one of those areas, that would be a weird experience.

You really are thinking far ahead! I really appreciate that. 🙌

But maybe the simple solution to that is implied in your comment: if the theme opts the post_content area into wide alignments, well then the group block inside that area behaves the same way. I.e. a header area would not provide wide alignments at all. Does this make sense?

Yes, exactly. 🙂 The "block area" or whatever we call it would determine if it allows wide/full alignments, and then that choice would cascade down to all blocks that live inside of it.

In the meantime, I do think this inner container would be helpful. I'd also love thoughts from @getdave on this when he's around — since I know he dove deep into group block CSS with me.

[kjellr]

It's much easier to just show an example. Here's a simplified implementation of wide/full blocks today:

https://codepen.io/kjellr/pen/WWKEqN

Here's today's scenario, where there's no container div inside of the Group block. It works ok, but it requires some brand new styles + thinking to get the inner blocks to appear as intended (L28-35 in the stylesheet):

https://codepen.io/kjellr/pen/QPBgJV

Contrast that to a scenario where there is a separate container div inside of the Group block. In this case, no new styles are needed. The width + margin rules from entry-content are applied to the container too, and everything else "just works" with no further code changes:

https://codepen.io/kjellr/pen/vMaZeK

Also: I took a minute to expand these examples to cover all Group block alignments (not just the full alignment). This does a great job of demonstrating the simplicity that the container div introduces:

Without Group Block Container DIV
Needs 19 lines of code to implement all child block alignments.
https://codepen.io/kjellr/pen/QPBgJV?editors=0100

With Group Block Container DIV
Needs 6 lines of code to implement all child block alignments.
https://codepen.io/kjellr/pen/eoPQde?editors=1100

[allancole]

Wow, this is a really tricky one but I agree that an inner container is the best way forward for now. It’s seams like the cleanest and most frictionless way to solve this. The last container div example from @kjellr’s comment above seems to solve this nicely.

To go on another future thinking tangent, something @jasmussen pointed out made me think a bit differently about all this.

I believe that it will feel natural to expand this concept to include additional block areas in the future, including widget areas, headers, footers. But common to all of those areas are that you can insert blocks in them. If the group block suddenly centered content, if inserted inside one of those areas, that would be a weird experience.

As a concept, isn’t a widget-area or even a header/footer kind of already a Group Block? Each of these areas are top level sections that can be full, wide or normal width depending on the designer. They also contain simpler Blocks within them like site-title(header), or Categories Block(widget area), or copyright info(footer). I’m having trouble imagining when a user might want to actually put a Group Block in a header or widget area. To me that feels just like nesting a Group Block inside of Group Block which I agree would be a bad experience.

The process of making a full-width section that has centered content and a fixed background-image, could be the same across the header/footer/widget-areas and the Group Block when it exists inside of the .entry-content. There’s just so much in common functionality it seems like they should all just be the same thing structurally.

[jasmussen]

As a concept, isn’t a widget-area or even a header/footer kind of already a Group Block? Each of these areas are top level sections that can be full, wide or normal width depending on the designer.

Yes. I'm mostly thinking of the HTML equivalent. A div inserted is, by default, "full wide" in its natural state. What we have created for the post content container, I would argue, is an "unnatural" state for such containers. We are adding smarts to it because the centered column is a traditional design for blogs, and the wide popout features add some very welcome layout variation to that design.

I’m having trouble imagining when a user might want to actually put a Group Block in a header or widget area.

I disagree, I can see myself wanting a background color behind the "About this blog" section that sits at the top of my sidebar. Or I could see myself adding a background color behind a couple of paragraphs in my header, let's say if I wanted to provide a big and bold notice: "Note, site is about to move hosts in the next week, there might be bumps". Something in that vein.

I hear you — those are edgecases. My only reason in bringing these up is mentioning that we are currently very much optimized towards how blocks behave in a single post-content area, and are very informed by how this layout has been done for many years. But blocks are about to be everywhere, so we need to keep that in mind.

And to be clear, I'm not suggesting that there is necessarily anything wrong with adding an inner container, I completely defer that decision to you, Kjell, and others.

On a sidenote, this was a little detour from the original ticket, apologies for that. I like what Kjell said here, it seems like a good rule of thumb that lets us proceed:

The "block area" or whatever we call it would determine if it allows wide/full alignments, and then that choice would cascade down to all blocks that live inside of it.

[tmdesigned]

It seems to me possible that the group block will widely ship before this change is decided upon and, if approved, added. I can think of some cases where styling the block as it is now will be different once there is an extra div., i.e. .wp-block-cover > * .

If it can't be done immediately, which is asking a lot, what are other possibilities for transitioning smoothly to having the inner div? Could it be opt-in, for instance?

[kjellr]

It seems to me possible that the group block will widely ship before this change is decided upon and, if approved, added.

I think we're ok, @tmdesigned: My understanding is that the Group block won't ship outside of the plugin until WordPress 5.3, which is still a ways out (As of today, 5.2 hasn't landed yet). Also, the core themes do not have approved patches yet for the Group block yet (Those tickets are open, but would need new patches if/when this change happens).

I think we're all generally in agreement that adding this would be fine. The current method of implementing a group block layouts is far too difficult, and I'd like to make it easier before it launches. This seems like a relatively simple way to do that. I'd like to get one last weigh-in from @getdave next week, and as long as he's on board too, we can have someone implement. (If anyone wants to open a PR in the meantime, go for it! 👍)

[kjellr]

(If anyone wants to open a PR in the meantime, go for it! 👍)

Actually, I took care of this myself. If anyone wants to try this out with their themes, take a look at #15210.

[erikjoling]

I hope you don't mind me bumping into your discussion about the group block, but I'm really wondering about the direction of the group block.

I think the first priority of the group block is to group blocks together. In this way it behaves like a "block-area", which is also a collection of blocks. You could call it a pseudo block-area.

But what would be the design options for the group block? Adding a background color? If yes, then shouldn't it also be possible to add a background image? And should it align it's children?

And what about markup? With block-areas we will probably have the possibility to tag them as header, footer or aside. I think it would make sense to be able to tag a group-block in the post-content as aside, section of div (I'm a bit worried about divitis).

But the more options you give it the more it diverts from being a simple grouping block. Maybe every block-area should be able to set the options of the group-block.

[strarsis]

Going one step further: Wouldn't it make sense to give themes hooks and filters for adding wrappers
to any kind of block, not just the Group (formerly Container) block?
It makes sense to add extra wrapper DIVs just alone for extra pseudo-elements.
For example, I would also need an extra DIV for the Cover block.

[strarsis]

@kjellr: The wrapper is nice and allows lots of nice styling. But what if I need a second wrapper?
How can a theme add this extra wrapper on frontend and on the editor (so it looks the same there, too)?

[kjellr]

Hi @strarsis — I'm not entirely sure. Can you share a use case for an additional wrapper in the Group block?

[lkraav]

@kjellr: The wrapper is nice and allows lots of nice styling. But what if I need a second wrapper?
How can a theme add this extra wrapper on frontend and on the editor (so it looks the same there, too)?

#15000 (comment) may have information for filtering arbitrary markup into any block.

blocks.getSaveElement https://github.com/WordPress/gutenberg/blob/master/docs/designers-developers/developers/filters/block-filters.md#blocksgetsaveelement

[strarsis]

@kjellr: In this case more pseudo-elements are needed, also some masking and shows are used that are very hard or even impossible to isolate without using an extra wrapper element.

@lkraav: Using the block.getSaveElement filter would require (after theme activation) to open and save each page in Gutenberg editor (that uses this block) to update the HTML output, right?
Will the HTML modified by blocks.getSaveElement filter also be visible in editor or only in frontend?

[lkraav]

@strarsis good point - I'm currently not aware of whether a PHP filter API is available for blocks or not.

[strarsis]

@lkraav: An intermediate layer would be the best approach IMHO:
The Guten Block stores some minimal HTML and its content (as it does now more or less), the intermediate layer can be used by the theme to further manipulate the HTML (e.g. by wrapping it n times). The intermediate HTML is used in editor and frontend, but generated dynamically from the stored content. When the theme is changed or updated, it would just hook differently into that layer, the Block data stored in database stays nice and clean at any point.

[strarsis]

I found an interesting tutorial for overriding the server-side rendered markup of core Gutenberg blocks:
https://antistatique.net/en/we/blog/2019/01/29/gutenberg-override-core-blocks-rendering

[carasmo]

As of the update to 5.8, this wp-block-group__inner-container is gone and it's messed up EVERY SITE. That's where I put the max width and/or the relative position z-index so it's higher than the psuedo on the parent. UFR!

Update: This happens when there is a theme.json -- even if it's empty, just having this in my theme removes the wp-block-group__inner-container on the front page, but not on other pages.

[AlecRust]

This article explains how to add the container back (may require translation) https://epiph.yt/blog/2021/wordpress-5-8-wp-block-group__inner-container-wieder-hinzufuegen/

Not sure why this pretty important inner container was removed, but I sure would like to not have to use the hack mentioned in that article.

[getdave]

@strarsis @carasmo @AlecRust Thank you for your feedback and for raising this concern. It's much appreciated.

As this issue is closed I would recommend raising a new Issue in order that it will be more likely to be picked up.

The more information you can provide in your bug report then the easier it will be to replicate and resolve. I appreciate it might seem like a simple regression, but having look at the code it looks as though this is tied up with theme support and so it's probably more nuanced than I first believed.

If I can be of any help please let me know. I appreciate you taking the time to contribute 🙇

[getdave]

I took a brief look into this. As I suspected the prescence of this inner container is now predicated on whether the theme supports the new "layout" setting.

gutenberg/packages/block-library/src/group/edit.js

Lines 66 to 73 in 1ba0bff

	{ themeSupportsLayout && <TagName { ...innerBlocksProps } /> }
	{ /* Ideally this is not needed but it's there for backward compatibility reason
	to keep this div for themes that might rely on its presence */ }
	{ ! themeSupportsLayout && (
	<TagName { ...blockProps }>
	<div { ...innerBlocksProps } />
	</TagName>
	) }

For example, the screenshot below shows a Group block inserted (running latest WP and Gutenberg Plugin) using the Twenty Eleven theme. As this does not support "layout" we can see an inner container is rendered:

If you'd like to check whether your current theme supports "layout" you can open the dev tools Console and type:

wp.data.select('core/editor').getEditorSettings()['supportsLayout']

Here is the dev note about the layout feature which might help clear this up for you.

https://make.wordpress.org/core/2021/06/29/on-layout-and-content-width-in-wordpress-5-8/

If there's still a problem or you need to discuss backwards compatibility please do raise an Issue and we'll look into it.

Much appreciated.

cc @youknowriad who worked on the layout feature.

[carasmo]

@getdave -- Thanks for looking into this.

Trac reply stated:

Hello there, this is expected behaviour as mentioned in the last section
of the [https://make.wordpress.org/core/2021/06/25/introducing-theme-json-
in-wordpress-5-8/ related dev note].

So I'm going to use the hack (#15042 (comment)) so I can have theme.json to remove all the stuff I don't want (drop caps, gradients, etc).

[nickfmc]

Ideally, a user could have some control over the alignment of all inner blocks. There are two ways of doing this:

Allow the inner container to have wide-width controls.
Allow all blocks to have wide-width controls (many already do).

I don't understand why WP decides that some blocks.. Paragraph/blockquote/etc don't deserve an alignwide/full option. however a Heading block that is semantically the same as a paragraph gets them?? In my theme setup everything works perfect except for nesting blocks that do not have alignwide options, so I'm telling people to manually add that class to certain blocks? if WP is making the decision on which blocks you can alignwide then it should also be making the decision on how you should style your alignwide/alignfull and standard width blocks. If we just had a function to turn on alignwide and alignfull on all blocks it would give a lot more flexibility to theme developers.

[EmSixTeen]

Can't believe this was actually added. So redundant and nothing but a pain for styling.