Add container block

[talldan]

Now renamed to "Section" (by popular demand)

---

Closes #4900

Description

Adds a basic version of a new Container block. This block supports:

• Align wide & full
• Anchor links
• Background color
• The ability to remove the default paddin

Not included:

• Text color—this could be added, but we thought we'd keep the initial PR small.
• Background images—see the discussion on the issue
• Inner block alignment—again, something that can be addressed in a later PR
• Block appender from the mockups—InnerBlocks doesn't support this out of the box, so it will need some exploration in a separate PR.

Todo

• Should padding match paragraph?
• Confirm the 1px overflow is gone (best tested in FF)?
• Rebase branch
• Should the Block be reusable?
• Should we remove the feature flag?
• Decide on naming Section vs Container - then update all references
• Remove default background in favour of merging changes from Adds Block Appender as placeholder to empty InnerBlocks #14241
• Solve the issue of the movement handles being invisible when the Block is full width.
• Validation error (on reload) when custom background color is applied
• Feature flag the section block.

What to test

If you'd like to test this Block the main features to focus on are:

1. Ability to nest other Blocks within the Section Block.
2. Ability to align the Block itself and all child Blocks (only those which support the alignment settings).

For #2 you can utilise @getdave's Plugin which will auto-generate a series of Section Blocks for you in various alignment combinations.

A good first test scenario might be:

1. Add some standard Blocks
2. Add a Section Block - how did does that process feel?
3. Add Blocks within the Section - does this feel intuative?
4. Experiment with some different alignment settings on the Section itself - does it respond as expected?
5. Try changing the alignment settings of some child Blocks which support alignmnet (eg: cover, columns, image...etc). Do these settings respond as expected? How about when you change the Section Block alignment settings at the same time?
6. Add / remove background colors - is this a seemless process?

As a second pass find some common web layouts and try and recreate these using the Section Block.

How has this been tested?

1. Add a Section block
2. Try adding inner blocks (this container block supports all blocks)
3. Try adding background colors and using different alignments
4. Preview the post

Expected result:
The container Section block should appear as expected

Screenshots

Types of changes

New feature (non-breaking change which adds functionality)

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• My code has proper inline documentation.
• I've included developer documentation if appropriate.

[talldan]

Hey @melchoyce - This is a very stripped down version of the block to start with. Let us know if you think there's anything else that needs to be added to this initial version. 😄

[SchneiderSam]

Ohhhh, that's so great. Thank you so so much for working on it. The solution to work first on a lite version and to extend the piece by piece I find also very good.

[richard-senior]

You guys should consider blocks for all the HTML5 semantic elements (aside, article, main, etc.)
But this is a very good start. I desperately need this! :) Please Pull it super quick :)

[kjellr]

🎉 This is brilliant, Dan. Great progress so far. A couple small notes after giving this a quick test:

First, I'd love to get that new appender in here. But even without it, this seems incredibly useful. It'd be great to reuse some of the thinking around light/dark styles from the Cover PR, as some of the UI elements seem a little hard to see against the default background. Specifically the placeholder color + icon colors in this screenshot:

---

Second, the label for the padding setting was a little confusing:

I'd expect the [On] state to add padding here, and the [Off] state to remove it. Along those lines I'd recommend changing this to:

[ Toggled On ] Use default padding
[ Toggled Off ] Use no padding

(In this case, [On] would be the default)

[melchoyce]

Can you tell me more about the decision to add the padding toggle, and what it does?

Here's the block icon: https://cloudup.com/cY08t7GudsC (need to download it to preview)

[draganescu]

Hi @kjellr,

We've tiptoed a lot around this padding setting :) and indeed to us also it sounded a bit off "to enable a toggle to disable a feature". I think your suggestion is awesome and so I've modified the behaviour to be like so.

Also found that due to the changes the save function was missing the correct classname/attributes for the padding and I've also fixed that.

Now we have this:

[draganescu]

Can you tell me more about the decision to add the padding toggle, and what it does?

Hi @melchoyce ! The padding toggle is the result of the fact that when the section block is in full width mode the content gets stuck to the edges of the viewport and for text, for example, that looks like it is undesirable:

The toggle adds or removes a default of: padding: 1rem 2rem; to the container.

Initially we added the padding setting as a slider that set an inline value for it, but dropped it because we thought it would be hard to be overridden by themes.

Then we figured some sensible defaults would work, and that resulted in a dropdown where you could set a "narrow" or "wide" padding, and I think there were some other approaches but ended up with this toggle.

[melchoyce]

Why not allow the InnerBlocks to decide their own width?

Edit: So, assume default padding, but allow InnerBlocks to be wide or full-width

[talldan]

Why not allow the InnerBlocks to decide their own width?

Edit: So, assume default padding, but allow InnerBlocks to be wide or full-width

@melchoyce I definitely agree the padding option is not ideal, we struggled to find a good solution off the bat, so went with something simple so that we could at least make a draft PR and get some feedback.

The main issue is that by default blocks are 100% wide so that they're responsive. When the container is set to full-width the inner blocks expand to take up that space. A lot of the inner blocks don't have their own alignment options (e.g. paragraph) and there's also no option to set them back to their normal width within Gutenberg. Also, from the editor's point of view we don't know what that normal width is, as the theme defines it.

The container from the stackable plugin tries to solve this providing a second set of alignment (full-width, left, center, right) options:

We could go with something like that. I think it'd be great to have a different icon set for this, and also to provide that 'normal' option, which themes could provide a style for.

Another option is to nest a container block within a container block and have the inner container provide that option, but I don't think that'd be as user-friendly.

[talldan]

It'd be great to reuse some of the thinking around light/dark styles from the Cover PR, as some of the UI elements seem a little hard to see against the default background.

@kjellr I hadn't seen that PR (#13822), will familiarise myself with it!

[melchoyce]

Another option is to nest a container block within a container block and have the inner container provide that option, but I don't think that'd be as user-friendly.

Yeah, let's avoid having another layer of nesting.

The container from the stackable plugin tries to solve this providing a second set of alignment (full-width, left, center, right) options ... We could go with something like that. I think it'd be great to have a different icon set for this, and also to provide that 'normal' option, which themes could provide a style for.

Let's think about this option more.

In the meantime, what if we excluded the toggle, and always apply the padding? Themes can override if necessary.

[kjellr]

Just wanted to add a note that Twenty Nineteen (presumably along with some other themes) will need a patch in order to properly support wide/full alignments of InnerBlocks. Currently it gets a little weird:

(^ In this screenshot, the image is set to be full-width)

I'm happy to work on that part, once this PR gets a little farther along. 👍

[draganescu]

what if we excluded the toggle, and always apply the padding? Themes can override if necessary.
@melchoyce did just that, no toggle just default padding to the wrapping container.

@kjellr That also happens if the container is full width. Apparently there are some calc() CSS lines that send the inner contents off.

Also, because of the active theme's effects in the editor, when setting these things, e.g. the container full width and an image full width looks bad in edit mode too.

I wonder, if a theme has poor implementation of CSS for some blocks does the user understands this or do they believe that the editor is broken?

E.g.

[melchoyce]

did just that, no toggle just default padding to the wrapping container.

@draganescu Yes, I mean get rid of the toggle that removes padding, and rely on themes to override the default padding the block provides.

[kjellr]

@kjellr That also happens if the container is full width. Apparently there are some calc() CSS lines that send the inner contents off.
Also, because of the active theme's effects in the editor, when setting these things, e.g. the container full width and an image full width looks bad in edit mode too.

Yeah, there are a lot of things that'd need to be sorted out. Twenty Nineteen wasn't really written with this sort of thing in mind, since it didn't exist yet. 😄 It's all fixable though.

I wonder, if a theme has poor implementation of CSS for some blocks does the user understands this or do they believe that the editor is broken?

They definitely believe the editor is broken! But that's our incentive for building this in a way that's as compatible with themes as possible. I'm not sure there's a way around it, but ideally, we don't want themes to have to patch for this functionality.

[kjellr]

Just a quick update from a theme perspective: I spent a little time trying to build proper wide/full child block support for this block into Twenty Nineteen, and the good news is... it wasn't that tough.

The bad news is... it's fairly complicated. The width and amount of negative left positioning for wide + full child blocks needs to be adjusted to include the padding + block margins for the container block. This is fine, and an extension of what the theme has now. The real complication is that this needs to be re-adjusted for each alignment variation (standard, wide, and full) of the container block and for three breakpoints for each one of those variations. 😩

I don't see any real way around this for now, but I'll keep digging.

[kjellr]

I also have a conceptual question: If you're using a container block, it's supposed to "contain" the content inside of it, right? So does it make sense to allow for blocks that can extend beyond the boundaries of the container in the first place?

[draganescu]

So does it make sense to allow for blocks that can extend beyond the boundaries of the container in the first place?

Conceptually not, but look at the creative effect you've got in your demo above :) I see no reason to disallow it if it is possible to implement properly!

[kjellr]

Conceptually not, but look at the creative effect you've got in your demo above :) I see no reason to disallow it if it is possible to implement properly!

Well, I do think it'd be less complicated to implement if they did not break out of the containers. 😄

[SchneiderSam]

I don't know if it fits the conversation, but I think it is also used in practice:

From: https://backlinko.com/google-search-console

It's so great you're working on the container block. If you only imagine what you can do with it. Instead of installing plugins to get an alert box, I'll design it myself and save it as a reusable blog. How cool is that?

[getdave]

consider HTML5 semantic elements as the next step.

@afercia I take your point and we can consider those in another PR. It's totally possible for Gutenberg to "upgrade" any Blocks created with the current version of the Block as and when we decide to enhance it so we are covered for that.

In this regard, while I do realize this block has been renamed to "Section" by popular demand, what will happen when a

HTML5 block will be added? What name should be used for a

block if "Section" is already taken by this generic block?

@afercia Thank you. Whilst I appreciate your concern and foresight, it's my understanding that the Gutenberg Blocks are not necessarily expected to map 1:1 with HTML5 elements directly. As a result, I'm doubtful we will ever see any Block that simply implements the <section> tag.

There isn't one naming convention that is going to address all the concerns and viewpoints held by people interested in this Block (and there have been many in this PR 😄). Therefore I'm going to suggest that in the interests of getting a v1 of this Block shipped we move any discussion around the naming of this Block into a dedicated Issue (which I will raise once this Block is merged). That's not to say this discussion isn't very valuable, but in the interests of keeping the thread focused on merging, I feel that's the best course of action. I hope that works for you?

Thanks again for taking the time to feedback.

[afercia]

Sure, let's postpone the naming issue.

it's my understanding that the Gutenberg Blocks are not necessarily expected to map 1:1 with HTML5 elements directly. As a result, I'm doubtful we will ever see any Block that simply implements the <section> tag.

Whether they will be blocks or something else, at some point Gutenberg will need a way to render <section> elements, <article> elements, and the like.

[getdave]

Status

✅ Minimal feature set implemented
✅ Rendering and CSS reviewed and approved by @kjellr and @jasmussen
✅ Tests passing

Now awaiting @youknowriad's confirmatory technical review (incoming).

[gziolo]

I quickly skimmed code. It all looks solid as far as I can tell after 5 minutes. I would be interested to see how developing blocks evolve on the parent with child interaction level after this change lands. It's becoming obvious that whatever can be applied to the section block should be abstracted away so it could be easily applied for other blocks as well.

[youknowriad]

Looks good to me code wise.

What do you think about this in relation to the editor and theme styles @kjellr

• How does it behave in a theme without any gutenberg support?
• Is it "easy" to provide styles for the alignments in themes?

[getdave]

To confirm I will merge this today as soon as @kjellr confirms @youknowriad's points.

[kjellr]

How does it behave in a theme without any gutenberg support?

On a theme with no Gutenberg support at all, the wide/full alignment options for the section block disappear (as well as the wide/full alignments of all children). So that'll work as expected by default.

If a theme has declared Gutenberg support for wide/full, this should generally work well in the editor. Theme authors may need to patch their editor styles to ensure that the exact width of wide-aligned child blocks match up with the width they're using in their theme.

The front end's a little different though: Gutenberg does not provide any front-end styles for wide/full alignment in general, and that has not changed here. In most cases, a theme's existing wide/full styles will not automatically work inside of the section block. Theme authors will need to build styles for wide/full child blocks for the front end. Usually, these will be variations of the themes' existing wide/full styles, but nested inside of a wp-block-section class.

If a theme does something advanced with the wide/full alignments (like Twenty Nineteen does, where it left-aligns them), things will probably be a bit more messy, and will require a more complicated fix.

Regarding the default themes:

• As noted, Twenty Nineteen will need a patch. I'm doing some cleanup on one, and will submit to trac later today. (EDIT: The patch is up now. https://core.trac.wordpress.org/ticket/46750).
• I believe Twenty Thirteen is the only other default theme that supports wide/full. That will need a patch too, but I expect it'll be much simpler than the Twenty Nineteen one. (cc @laurelfulford)

Is it "easy" to provide styles for the alignments in themes?

It varies greatly on how the theme has implemented wide/full. In the Gutenberg starter theme for instance, this only requires 4 new css rules (example here). For Twenty Nineteen, it's many, many more than that.

Once I get Twenty Nineteen patch ready, I'll update our documentation to make note of this. (In general, our documentation around wide/full alignments is very slim).

[youknowriad]

🎉 Awesome work everyone.

[hypest]

👋. I know this PR is already merged but I'm wondering if such a generic div element can be extracted in its own component. It will probably be an opportunity to make the Section block more cross-platform ready by not using html tags directly. WDYT @getdave ?

cc @gziolo , @Tug , @koke

[gziolo]

@hypest, we totally should introduce View component which will work cross-platform. @koke landed a similar component yesterday. See #14361 for reference. It should be a very similar use case.

[strarsis]

The "classic" (left, center, right) alignment options are still missing. 😿