Group Block - add support for Background Images

[getdave]

The Group Block recently merged with support for background colors. As a next step, it would be good to add support for background images along with the focal picker.

Describe the solution you'd like

This would upgrade the Group Block with the following:

• Ability to choose a background image as the background
• Ability to pick the focal point for that background image
• Ability to set color overlay (as per cover Block) (thanks to @SchneiderSam )

Considerations

• Would this bring the Block too close to the current cover Block? Or should we encourage users to utilise a cover Block within a section to achieve this?

[SchneiderSam]

Great would be in this move also a color overlay as with the Cover Block.

[youknowriad]

Yeah, I'm not sure about this as this will just be a cover block in the end if we do this.

[SchneiderSam]

As an end user, I understand it this way:

Cover Block: a block to add text to a background image at the beginning of a post. Alternatively it can also be used in the middle of a post as call-to-action.

Section Block: can do anything. Columns, background color, background image, Section in Section, ect... Simply: The LEGO building block for a website.

It would be great to know which block should be used for what. For me the cover block is completely superfluous. The Block section should have all the functions currently available in the cover block.

A section block without the possibility to insert pictures just doesn't make sense. This is a must have!

[youknowriad]

A section block without the possibility to insert pictures just doesn't make sense. This is a must have!

Thanks for sharing your opinion, let's keep the discussion flowing but let's avoid "absolute" statements. "this doesn't make sense, this is a must have".

[SchneiderSam]

Ok. Sorry!

[oxyc]

I would prefer if the cover block (and all blocks with InnerBlock) supported filtering the list of allowed inner blocks. The themes that want to add 3 columns inside a Cover Block could write the styles to support it.

[truchot]

Why not use the cover block if the aim is to have a background image ?

[bbertucc]

@truchot - the cover block doesn't support nested blocks.

Adding to @getdave's feature request: The ability to fix image position and add a background overlay.

My use case:
I want to create a masthead with a header, subtitle and button. Mastheads like these are very common. See Bootstrap's Punny headline.

[truchot]

@truchot - the cover block doesn't support nested blocks.

Yes it does :)

1. You can install Gutenberg as a plugin to get last features
2. Or wait WordPress 5.2 that will be released very soon

[bbertucc]

o perfect @truchot! Didn't catch that in the release notes. It still doesn't support other blocks, like columns.

My question now: Why not get rid of the cover block and just add the same background settings to the group? We can add the extra spacing with a spacing block

[melchoyce]

Mockups:

(Please note that as this is an older mockup, many general UI elements are outdated.)

Some questions:

• We'd be reusing image settings from Cover.
• Instead of overlay color, I'm using opacity, so color and image can remain independent. Does this make sense?
• Should we use the new swap image flow for changing background images and include an image icon in the toolbar, instead of putting it in the sidebar?
• Is there any way to measure color contrast of text over an image?

[SchneiderSam]

Well, I still think that's a great thing. I hardly use the cover block at all. I'm a big fan of these groups and at the moment I'm still solving everything about the function: individual classes. If this is pushed further, it would be a nice thing for the end user! Please carry on!

[getdave]

This wouldn't be that difficult to achieve. Personally, I feel it is a worthy addition to the Group Block, but I know others have reservations.

[afercia]

Discussed during today's accessibility bug scrub, agreed on a couple recommendations:

• Important settings in the sidebar should be avoided: this is part of the long standing issue related to navigation from the content area to the sidebar and back. Noted in many other issues and PRs. All controls that are essential to producing content should be within the block itself. We, as a team, recommend to reconsider and place the most important ones within the block
• re: "Is there any way to measure color contrast of text over an image?". Not that we're aware of. This always require manual checking. An idea could be a short explanatory text to inform users to take care of the contrast.

[melchoyce]

All controls that are essential to producing content should be within the block itself. We, as a team, recommend to reconsider and place the most important ones within the block

Which setting are the a11y team thinking?

[afercia]

We haven't discussed specifically which settings. Personal opinion: all the ones that are needed to "get the job done" :) at the very least: edit / replace / remove image.

[klihelp]

+1

[LyleBennett]

Either being able to nest more blocks (especially columns) in the cover block; or adding background image and overlay to the groups block would be great.

[SchneiderSam]

Either being able to nest more blocks (especially columns) in the cover block; or adding background image and overlay to the groups block would be great.

Absolutely. It would be nice if a decision was made.

[boemedia]

We discussed this in today's design meeting. It seems like there's a need for a background image option in the group block. However, at this point, it starts competing with the cover image block and I think it would be a good idea to have one type of block for both a start of a page post or a section with all forementioned functionality.

[SchneiderSam]

Are there any developments here? I find this function so fundamental and I as an end user somehow get totally mixed up when to use a group block and when to use a cover block. That's kind of confusing.

After posting mtias in #16479 the goal is to add a background function here. Is there a roadmap @getdave or @youknowriad ?

[wwdes]

Imo both group and cover block are a failed concept. This “simplicity” or “less is more” type of interfaces always end up being too niched and opinionated. People come to this repo and make suggestions like these, hoping that the development of the block builder will somehow skew towards some utopian free and flexible site builder, which is not what the devs have in mind. If it were then there should have been a container block with ALL the features and all other blocks would have had lots more features, basically following the 3 C’s holy grail of content and page building. Then they would have implemented an API, like the theme json, where features would have been turned off/on or customized. They could even come up with a default config to keep the interface simple and blog oriented or whatever. Of course this will not happen for lots of reasons.

[jamieschmid]

Is this not a feature at all? How else are you supposed to put a background on a container with core blocks? Maybe I'm missing something but the cover block is not a container, it's kind of a superfluous feature block in my opinion that has few uses. A group block is incredibly flexible, limiting it to only color backgrounds makes no sense. I wonder if it's a limitation in how the block is built? Any other ideas on how to get a background on a container using core blocks?

[room34]

@jamieschmid

Is this not a feature at all?

Well… it kind of is; you can put any blocks into the inner container of a Cover, including a Group. But that does still leave some weird issues because the Group is inside the Cover's more restrictive padding rules.

It just seems to me that the Cover block conceptually missed the mark; eliminating it and giving the Group block some of Cover's capabilities (background image + its positioning/sizing features, overlay color) would address this concern.

The problem is a lack of a singular cohesive and comprehensive vision for Gutenberg from the outset, but that kind of Platonic ideal was never possible in reality. Overall I think Gutenberg has shaped up much better than I expected it to early on, but this weird dichotomy between the Cover and Group blocks is definitely a sticking point.

I'm guessing the biggest deterrent to combining them would be that the Cover block is something conceptually easier to understand for novice users, who seem to be a primary intended audience for Gutenberg… even though I do not think Gutenberg is easier for novices to understand.

[paaljoachim]

#49273
#49992

The Site Logo block now has in a recent Gutenberg plugin a Media panel for uploading/adding an image as a site logo.

What about adding the media panel to the Group block. To which clicking Add media opens a drop down of options such as Media Library, Upload, URL etc? To which one would be able to add a background image or video.

[draganescu]

@paaljoachim the site logo is media - an image we decied it has the meaning of Logo. But backgrounds are style, it should be set from the design panel I think?

[porg]

Further use cases

• Background-patterns (repeating image tiles) for Group block (my use case why I came here)
  • In other words: Adding Images as Block background just as Color #49106
  • Or open up a possibility for plugins: Background attribute gets API for 3rd party plugins to allow other background types, e.g. patterns (tiles) #51465
• For template editing: Add body background image to global styles (Customizer feature parity) #38436

Possible way forward?

• I agree that the Cover block is superfluous.
• Dropping it is a though decision to make I guess (legacy!)
• Idea for a feasible compromise: Make the Cover block a block variation of the Group block. That could be the solution to all issues raised:
  1. Efficient Codebase: Image block just a variation of the Group block.
  2. Usability: Beginner users who primarily want a "Cover block" can still so add it it via Block Inserter like a "true block" and still have the reduced UI and interactions and do not need to discover this more hidden as sub-options of the powerful Group block.
  3. Legacy: Deprecated cover blocks in all templates/pages/posts can get auto-transformed to the corresponding Group block variation.
  • When/how would need to be decided.
    • WordPress → Tools > Transform deprecated blocks
    • Or during an update: Admin gets notified prior/after update.
    • In both cases: Link to help page, which tells about the deprecation, and FAQs for a smooth upgrade process.

[Ren2049]

@porg

Sounds good, together with the group renaming option it would give the site editor a huge boost in usability. Is there a possibility to have a dedicated color for the group block, e.g. green, complementing the purple of template parts when it's used as the outer wrapper?

[t-hamano]

Since this issue was first submitted, various features have been added to the Cover block.

• The featured image is available: Makes cover block dynamic and adds featured image binding #39658
• HTML elements can be changed: Cover block: add HTML element selection #46969
• Has lots of block support ( align, anchor, color, spacing, typography, border)
• Supports the flow layout: Add constrained/flow layout to Cover block. #45326
• Has allowedBlocks and templateLock attributes
• Has duotone support: Add duotone block supports #26752
• Can convert from group block: Add transform for group block to cover block. #30890

What would be the ideal approach in light of the latest Gutenberg specifications?

[jasmussen]

What would be the ideal approach in light of the latest Gutenberg specifications?

The primary blocker for bringing background support to the group block has been maturing the inspector controls to afford them. The interface from the Cover block shows that in the current implementation it doesn't scale well:

I think we have a path forward with the recent inspector interface that landed for the Site Logo block:

Essentially here, the media is a single small ItemGroup Item, both before and after adding media. That's just a raw media item with no background property, but the inspector compactness is one to follow, and it would seem like we can add background properties in a flyout menu, similar to how we have flyout menus for color.

[porg]

@jasmussen I concur regarding Inspector controls in particular and also in general that in the Inspector Panel one accumulates way too much time…

… scrolling

• e.g. the inline text hints are always there, also when long learned already, no way to dismiss/collapse them.
• ultra huge controls (contemporary webdesign trend ok for content, but to be used with care with UI elements/widgets)

…clicking the same long pathways again and again due to:

• Panels shall remember their state or else switching between them is a usability nightmare #49268

The Inspector panel UI certainly needs compacting and clever minimalism to get efficient.

[annezazu]

Anyone is welcome to apply to work for Automattic but this definitely isn't the right avenue to discuss. Let's keep it focused on the work at hand. If you'd like to talk about life at Automattic, feel free to ping me on WordPress.org slack (@annezazu there too).

[andrewserong]

I think we have a path forward with the recent inspector interface that landed for the Site Logo block:

I really like the approach used in the Site Logo block. Between that and recent work with the HTML Tag Processor, I think we're likely in a good place to re-explore adding in a background image / media block support now.

I've opened up a draft PR over in #53934 exploring one way to implement it if anyone would like to take a look!

[andrewserong]

Now that the initial version of background image support has landed in #53934, I've opened up a follow-up issue for ideas for enhancements over in #54336. Feel free to add any ideas there! I imagine most enhancements will likely be for releases beyond WP 6.4.