Background Image block support follow-up tasks

[andrewserong]

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.7

• Background image: add support for relative theme path URLs in template and pattern files #62254
• Background image: should it integrate with background-image theme mod? #60939
• Setting background-image overrides background gradient #60401 - WIP WIP Experiment: combine gradient and background image into background-image #60739
• Add support for background-attachment - Background: add background attachment to top level styles #61382
• Global styles: block background UI controls  #60100
• Gradient backgrounds should be set with background-image instead of background #32787 - Get the block support to work with gradient backgrounds in a logical way. See related comment: Global styles: add background image to top-level theme.json styles #59354 (comment)

Completed for WP 6.6

• Background images: add defaults for background size #62046
• Global styles: add option to remove site-wide theme background image #61998
• Background image tool: Improvements, bugfixes, find alternative to "fixed" #61928
• Add support for theme relative url paths for site-wide background images
  • Add/background image theme source #61401 (experiment)
  • Background image: add support for relative theme path URLs in top-level theme.json styles #61271
• Ensure that the site editor and frontend body min-height values match when a background is selected. Global styles: force root min-height of 100% for backgrounds #59809
• Move background default values logic to block supports Background block supports: move block support defaults to gutenberg_render_background_support and revert gutenberg_get_background_support_styles #59889 and Background block supports: move size defaults to hooks and block.json #60008
• Global styles: background UI controls #59454
• Global styles: add background to global styles changes output #60229
• Global styles: background UI control labels #60264
• Background image: use media upload flow  #60687
• Background image: tools panel shouldn't show reset button for inherited values #61304
• Background images: remove required "file" prop #61387
  • Background images: remove lingering "file" prop #61469
• Background image: size controls should show when an image is set #61388
• Background image: explicitly set background repeat value in user styles #61526
• Global styles: Group "Background image" in "Layout" section #61494

Completed for WP 6.5

• Add contain, fixed size and repeat controls: Background image: Add backgroundSize and repeat features #57005
• Background image support: add background position controls #58592
• Group block: When background image is set, has-background CSS class is missing #56261
• Background image: Add has-background classname when background image is applied #57495
• Background image block support: Add tests for size and repeat output #57474
• Background Image block support: Add reset menu item #54341
• Improve background image control #54439
• Background Image control: use consistent button, ensure descriptive text accounts for no image selected #54711
• Background image: Add backgroundSize and repeat features #57005

---

Unprioritized tasks

• Site Export: ensure that the export endpoint uses Gutenberg theme classes #61561
• Propose adding stylesheet_uri and template_uri field to themes endpoint (Trac ticket, Core PR)
• Theme.json: create a consistent syntax for relative paths #61804
• User global styles: should we save relative paths to the database for uploaded assets? #61809
• For global styles and custom background images (uploaded to wp-content) save relative paths in the database.
• [WIP] Background image: refactor controls #60151
• Improve performance by allowing support for optimized image size output Background image block support: optimize image output #59113
• Add support for background images via URL rather than just via media library
• Add option to use Featured Image
• Enable Duotone support (this will likely require outputting an img element)
• Enable video background (this will also likely require outputting child elements in rendered markup)
• Explore potentially allowing aspect ratio support, as requested for the Cover block: Add aspect ratio selector to Cover Block #54032
• Explore an option for opacity or overlay of the background image
• Background image block support: optimize image output #59113
• Background Image Block Support - Add ability to define which orientation the sizing should adhere to #62219

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"
• Improve experience for adding values from an empty state
• 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)

[Ren2049]

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

[annezazu]

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!

[andrewserong]

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).

[eduardozulian]

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!

[andrewserong]

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.

[webzunft]

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?

[andrewserong]

@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.

[webzunft]

@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.

[joemcgill]

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.

Related:

• Cover Block with parallax effect does not use responsive friendly srcset attribute #35290
• Cover Block: Add Background Image Size Selector #19223

[mikemcalister]

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!

[andrewserong]

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 👍

[andrewserong]

Update: the background size / repeat controls (#57005) are now available on trunk, so we can now use repeating background textures in Group block backgrounds. Here's one example of how it can look with a transparent texture as the background image, and then using background color to expose a color through that texture:

2023-12-22.12.12.49.mp4

There were some good ideas for UI follow-ups (e.g. #57005 (comment)) that I'm hoping to look into in the new year, along with background position controls.

[westonruter]

@andrewserong Unfortunately image-set() only works with pixel density descriptors. It doesn't work with width descriptors like srcset provides. See also A Guide to the Responsive Images Syntax in HTML which recommends instead to use media queries. But this requires injecting a style element, which would have the same problem as injecting img, right?

[andrewserong]

Oh, thanks for the link @westonruter! Injecting a media query could potentially be easier in that the style element could be anywhere on the page, so possibly enqueued a little bit like how block supports like layout attach a classname with a container id to the wrapper element, and then output their styles separately. That way the DOM hierarchy isn't interrupted for the Group block itself 🤔

Definitely worth investigating the options and seeing how they might look. Another potential option could be to give users the control to choose a background image's resolution in the UI (like how the Image block allows users to be explicit about it) — but that has the downside of it not being an automatic optimisation that users don't need to think about.

[westonruter]

@andrewserong Nevertheless, what this media query approach for responsive background images doesn't provide is support for lazy-loading. So yeah, img still is best.

Another potential option could be to give users the control to choose a background image's resolution in the UI (like how the Image block allows users to be explicit about it) — but that has the downside of it not being an automatic optimisation that users don't need to think about.

cf. #19223

[andrewserong]

Thanks for the discussion surrounding performance of the block support @westonruter and @joemcgill! It's a pretty nuanced one, and I think there'll be some trade-offs to figure out or to determine the right path forward. Since this is a tracking issue and there's still more to figure out, I've opened up a separate issue over in #59113 to continue the discussion. I've added a few notes to the issue description, but please add any comments there if I've missed anything we've discussed.

[djcowan]

Apologies for the brevity.
I am finding it very difficult to understand the need for the structure of each core block to be different.
A good example is the core/cover block compared with the core/group block
Both blocks offer image support - but in completey different ways.
I'm not a React specialist but aren't components meant to be combined to create larger UI components? Cards and such?
What has happen to ideas and principals like polyphorphism and D.R.Y?
Reading back a 2019 comment i followed to get here; regarding the difference between blocks is filling me with despair.
"Yeah, I'm not sure about this as this will just be a cover block in the end if we do this." @youknowriad
#14744 (comment)
Which leads me to ask "why?" - isn't this the point?
Now i'm going to leave before I start ranting about the need for separation between content, code and the presentation layer.
PS. We are trying to apply css filter functions to elements that use images. This is how I got here. It can't be done in Wordpress. And this fact frustrates me.

[colorful-tones]

Hi folks,
We are only one week away from the Beta 1 cut-off date for WordPress 6.6. This issue hasn’t seen any movement in a while, so we (the editor triage leads of the 6.6 release) have decided to remove it from the WordPress 6.6 Editor Tasks project board.

[andrewserong]

@colorful-tones this issue is under active work, but the work has been updated in the issue description rather than in separate comments here (CC: @ramonjd). In the issue description, there are two tasks yet to be finished for 6.6 (and one of them is a polishing issue, so it might be able to be worked on during the beta period).

Additionally, there are currently two backport PRs underway for backporting site-wide background images with support for theme relative URLs:

• Background block supports: add support for top-level styles in theme.json wordpress-develop#6482
• Background image: add support for relative theme path URLs in top-level theme.json styles wordpress-develop#6608

Can we re-add this issue to the board, or would it be more helpful adding the specific backports that need to make it in?

There have been quite a few PRs landing for 6.6, but they largely all fall under the umbrella of enabling site wide background images. Hope that helps!

[ramonjd]

Thanks @andrewserong and @colorful-tones!

This issue hasn’t seen any movement in a while

If you look at the description edit history, it's seen quite a lot action 😄

I'll tentatively add the two backport issues PRs to the board since they're the most important. All the major tasks have been completed for 6.6, with a couple of JS-only package updates to come this week.

Thanks!