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?