Background Image block support follow-up tasks

Related to #16479, following on from #14744.

Now that the background image block support has been introduced in #53934, this issue captures some ideas for follow-up tasks and features.

Prioritized tasks for WP 6.8 and beyond

Prioritized tasks for WP 6.7

Completed for WP 6.6

Completed for WP 6.5

Unprioritized tasks

Background position improvements

Allow non-percent-based units (e.g. rem, em, etc)
Allow values that are relative to a particular side (see 3-value and 4-value syntax on MDN) to allow for example "4em from top"
Consolidate controls with those in the Cover block
Look into preventing the controls from displaying until a background image is set (e.g. by moving the size, etc controls into a popover)

Image embeds are vital for prototyping within the block editor (before comitting them to the media library).

Pulling from the FSE Outreach Program's Final Touches call for testing, I wondered if the focal point option would eventually be added in as well:

Color adjustments are fine, but having the same background adjustments available as the cover block would be great. Focus point, at least.

& more here:

Here it would be great with similar controls that exist in the Cover block such a focus and color overlay and opacity.

& more here:

The task was fairly straight forward, although I agree with most of the responders here that an image editing toolbar, like the Cover block has, would make a better handle.

Happy to open a separate issue if that's easier!

I wondered if the focal point option would eventually be added in as well:

Oh, yes! It'd be good to have that as an option, too. I've added it to the list in this tracking issue — no need to create a separate issue for it just yet, I think this is a good place to gather together the ideas for now.

Color overlay and opacity.

Color overlay is possibly a little out of scope for the Group block, as it's well handled by the Cover block and would require additional markup to achieve. The main differences between what we can do for the Group vs Cover blocks at the moment is whether the additional styling rules can be applied to a simple outer wrapper (Group block) vs requiring an additional inner wrapper (Cover block).

@andrewserong

I'm +1 a few of the recommendations here. Here's the list I gathered based on stuff we offer for the Cover Block, all of them already shared:

Focal point picker
Overlay opacity
Set as a fixed background
Set as repeated background (great for small images that would work as a background pattern)
Image filters/Duotone support

@andrewserong I believe you're also aware of Automattic/wp-calypso#82284 but I wanted to move it here just to confirm if the lack of padding on the group block is currently expected or if we should indeed offer a default padding if there is a background image/color.

Thank you!

@eduardozulian

Thanks for adding that feedback here @eduardozulian!

I wanted to move it here just to confirm if the lack of padding on the group block is currently expected

Lack of padding on the Group block is expected. The Cover block is a more opinionated block when it comes to adding a background image, and so padding is formally a part of that block's background image implementation. The Group blocks are more general purpose blocks so it's up to the user (or pattern) to add padding when required. There are currently no plans to add padding by default when a user selects a background image.

I see that the generated inline style escapes the quotation marks within url(). E.g.,

style="background-image:url('https://example.com/wp-content/uploads/2023/10/img-scaled.jpg');background-size:cover;"

I don’t see this being a standard in core. If it isn’t, could this be changed to using unescaped quotes?

@webzunft

@webzunft I believe the escaping occurs due to how the attribute is output in server rendering as the HTML Tag Processor internally calls esc_attr when updating an HTML attribute. Is the presence of escaped quotes causing any visual issues on the site frontend for you? The inline styles are only injected at render time, and aren't saved in post content, so it should be possible to make tweaks to how the styles are output in the future.

@andrewserong

@andrewserong thanks for your reply. The browser (Chrome) correctly renders the output, so no problem there. I have a plugin that changes HTML in the frontend to inject some information (image captions), which broke with these escaped quotes, but nothing I can’t adjust on my end.

I'm currently looking at image optimizations for various blocks in the editor, and wanted to raise the issue here of needing to allow the browser to optimize loading the most appropriate image for the user. For blocks that render images as img elements, WordPress will automatically add srcset and sizes attributes, and possible add loading="lazy" or fetchpriority="high" to optimize resource loading. Coming up with a way of applying resource optimizations to background images would be an important performance improvement.

Color overlay is possibly a little out of scope for the Group block, as it's well handled by the Cover block and would require additional markup to achieve.

Not sure if you meant opacity here as well. I'm genuinely curious what the use case is for the group block with a background image but no way to control the overlay?

Groups have content, usually text,and most background images will make text illegible without some way of reducing the brightness. I've created hundreds of patterns, and I can't think of a single use case where I didn't use opacity when using a background image on the cover block.

Unfortunately, background images and the ability to control opacity and background color are inextricably tied together. If we're adding it to groups, for consistency and usability, it has to come with these controls to make it practically usable. It will be an ongoing battle with users for sure!

Not sure if you meant opacity here as well. I'm genuinely curious what the use case is for the group block with a background image but no way to control the overlay?

Great question. In my experience there are heaps!

A good example of use cases for background images that don't require overlay colors are ones that already include transparency within them, or images that folks have selected for their particular content (i.e. I know I'm going to write something with white text, so I'll pick a nice subdued dark image as my background). For examples of some good transparent background images, I've been playing with those at https://www.transparenttextures.com/ and https://www.toptal.com/designers/subtlepatterns/. Many of those sorts of background images require being able to set the image to repeat, which is being worked on over in #57005.

In terms of the user being able to adjust the opacity or overlay of the background image itself from within the editor, I think that's a great idea, it's just not a very simple task to implement within block supports or to enable for the Group block, so for now I think the other block support features are more pressing to implement, as the Cover block can already handle the overlay case.

I'm just one contributor chipping away at this, but in my opinion, I'd go for us building out the remaining features of the background image support that don't require altering markup (as overlay would require injecting an additional element), and to revisit the idea a little further down the track. It would be nice to support opacity/overlay for it eventually, for sure. I've added it as an item to the issue's description 👍

This ticket was featured on today's 6.9 Bug Scrub.

I'd be grateful if you could let me know if there are any tasks that need to be prioritized for the 6.9 release. Thank you!

@t-hamano

I'd be grateful if you could let me know if there are any tasks that need to be prioritized for the 6.9 release.

Thanks @t-hamano

The most important in my opinion are the following:

They are related.

However I don't think folks will have time to work on a solution for this before 6.9 beta unfortunately.

@ramonjd

@ramonjd Thanks for the reply.

Let's punt this issue to 7.0 if anyone doesn't pick up tasks.

This issue was featured on today's 6.9 Bug Scrub. There is no activity on this issue, so let's punt it to 7.0.

I took the liberty of checking a few boxes that appeared to have been addressed. But also, to remove the “needs design" label: firstly this is already on a solid path and I believe it is unblocked on design, especially since the recent reorganisation into Typography and Background panels. But please correct me if I'm wrong, and aspects do need design. I'd appreciate pings on individual PRs, or if there's something larger, we can discuss here.

@jasmussen

Thanks @jasmussen

I also did a small clean up.

I don't know if we'll have the bandwidth to take much of this on this cycle, but here's an assessment of what we could keep open based on the issue description:

Not implemented / could be easy

Gate individual background controls on theme.json settings — the "Allow background-attachment
and other controls to be disabled via theme.json (?)" item. Half-built already?
Editor preview for theme.json url(...) string background image values.
Honour background.__experimentalSkipSerialization in edit mode (PHP already honours it).
Add repeat-x and repeat-y options to background images #62608 repeat-x / repeat-y — design already signed off by jameskoster.

Open PRs

Item	Open PR
Background images via URL rather than media library	#77286 (+151/-39, 2 files, awaiting review since Apr 2026)
Option to use Featured Image	#77412 (+69/-4, 1 file, awaiting review since Apr 2026)
Non-percent units for background position	#77644 (+206/-21, 8 files, awaiting review since Apr 2026)
Opacity/overlay #66019	#71141 (+245/-33, awaiting review since Jan 2026)
Optimized image size output #59113	#75885 (draft) + WordPress/performance#2216
Consolidate controls with Cover block	#77742 is a small first step (+8/-1); the full migration is large

The hard stuff / not planned

Background image: should it integrate with background-image theme mod? #60939 Customizer background-image theme mod integration — unresolved product decision since
Jul 2024
Background image: add support for relative theme path URLs in template and pattern files #62254 (relative theme paths in template/pattern files), Theme.json: create a consistent syntax for relative paths #61804 (consistent relative
path syntax)
User global styles: should we save relative paths to the database for uploaded assets? #61809 (relative paths for uploaded assets)
Background Image Block Support - Add ability to define which orientation the sizing should adhere to #62219 (orientation-based sizing),
3-value/4-value background-position syntax (depends on Background image control: Add unit controls for focal point #77644 landing first)

Nice, thank you for the update. I don't know that any one of those is supremely more urgent than everything else, so my triage was just that. For now I've subscribed to the hard stuff you've mentioned, and will see if I can chime in!

Navigation Menu

Repository navigation

Background Image block support follow-up tasks #54336

Prioritized tasks for WP 6.8 and beyond

Prioritized tasks for WP 6.7

Completed for WP 6.6

Completed for WP 6.5

Unprioritized tasks

Background position improvements

23 remaining items

Not implemented / could be easy

Open PRs

The hard stuff / not planned

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Background Image block support follow-up tasks #54336

Description

Prioritized tasks for WP 6.8 and beyond

Prioritized tasks for WP 6.7

Completed for WP 6.6

Completed for WP 6.5

Unprioritized tasks

Background position improvements

Activity

Ren2049 commented on Sep 12, 2023

annezazu commented on Sep 27, 2023

andrewserong commented on Sep 27, 2023

eduardozulian commented on Oct 13, 2023

andrewserong commented on Oct 15, 2023

webzunft commented on Oct 26, 2023

andrewserong commented on Oct 26, 2023

webzunft commented on Oct 27, 2023

joemcgill commented on Nov 27, 2023

mikemcalister commented on Dec 21, 2023

andrewserong commented on Dec 21, 2023

23 remaining items

t-hamano commented on Sep 29, 2025

ramonjd commented on Sep 30, 2025

t-hamano commented on Sep 30, 2025

t-hamano commented on Oct 13, 2025

jasmussen commented on Aug 26, 2026

ramonjd commented on Aug 26, 2026

Not implemented / could be easy

Open PRs

The hard stuff / not planned

jasmussen commented on Aug 26, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions