Background block support

[glendaviesnz]

This issue outlines a desire to rationalise the background options across blocks and group them together in a Background panel.

As this issue states “Right now it's possible to add video backgrounds, coloured overlays, etc, to the Cover block alone. It'd make sense to extract this and extend it to other container blocks (group and columns, for example) as well as expanding the features”.

A new block support seems like the obvious way to handle this, eg.

"supports": {
	"background" : {
		"image": true,
		"video": true,
		"parallax": true,
		"focalPoint": true,
		… etc,
	}
}

However, those of you familiar with the existing block supports will realise that there is an awkward crossover between the existing ‘colors’ support, which provides a ‘background’ option to which can be assigned color or gradient.

We could add ‘media’ as an option to the existing colors background support, but a video and an image aren’t really a color, and if we have a background support that only includes media options and not color it might be confusing.

There are a few different approaches we could take, eg.

1. Leave background color/gradient where they are in colors, and add the media options in new background support. The Cover block already has the background color and background media appearing in different settings panels.

2. Make both block supports aware of each other such that if the newer backgrounds support is enabled, display the background color options in a new background UI panel combined with the media options instead of with colors. If the newer backgrounds support isn’t enabled, keep the background color/gradient where it is.

3. Completely move the background color/gradient to a new background support.

4. Combine background and colors support/panel under some new name

Does anyone have any thoughts on how to best handle the addition of block support for background media in terms of both the underlying data location and the UI?

@aaronrobertshaw, @andrewserong, @apeatling, @ramonjd, @stacimc, @karmatosed, @oandregal, @kjellr, @youknowriad, @jasmussen, @mtias , @shaunandrews

[jasmussen]

Great thoughts, and the prospects of expanding background support are exciting.

This may be one of those situations that need some visual explorations to help inform the path forward, before the technical structure can be fully described. For example, I could imagine a future where multiple backgrounds can be applied, each added to its own layer in an ItemGroup, each with its own colors, opacities, tiling properties and so on. Such a layered compositing interface might even be able to absorb overlay colors.

It might not be a near term thing, and the idea would need to be validated by mockups. But if the concept proved compelling it could possibly help inform the structure.

[jasmussen]

As a small followup, there's a ticket now, #39427, which details a single background panel with flyouts for more advanced controls. Would love your thoughts.

[oandregal]

Hey, it's great that you thought about how it'd fit overall and how can be expanded. We can create this new support feature by leaving the existing color.background where it is, so it's fewer things to worry about for a start. If there's a desire to move it, we can migrate it later to a new section.

We can use something like __experimentalBackground or __experimentalMedia to communicate that's an ongoing work and can change as we iterate on the UI as well.

[carolinan]

I have been receiving support requests asking how to add a body background image to block themes, without the customizer. A feature where you can select a background image that is applied to the website is missing.
When we use the cover block for the body background, we have to add it to all individual templates.

[paaljoachim]

Thank you for adding this discussion Glen @glendaviesnz !

I am going to add in various issues I found to bring in some perspectives of pieces of the background block puzzle.
As the various issues can bring up aspects which would be good to know about.

Add Youtube or similar video service using an embed URL in the background of the Cover block
#28860

Specify a color palette is to be used for background colors only (or text colors only)
#28146

Btw here is a site I have built a bunch of years ago.
https://galleriklevjer.no/
The content is boxed and starts at the bottom a kind of sticky.
There is a full page background fixed image that loops with other images.

Consider adding the ability to have multiple background images
#38796

Moving background tools for the Cover block from the Block Inspector to the Toolbar + extending background tools to Cover/Group blocks
#28643

Action for setting a Cover to match dimensions of background media
#28387

Allow using featured image as background for a group block
#24660

I will stop it there. As the above is plenty of background related issues.
I searched for background and browsed through a bunch of Gutenberg Github pages.
Perhaps we should create a Background block support tracking issue.

Actually I am going to add in a bug which has to do with the Ipad and Safari. (Adding it in here because of background controls in relation to different devices that we use.) #17718

[andrewserong]

Just a quick thought I had last night about how we might store the attributes for a background support. Wherever it sits in the hierarchy, perhaps instead of a whole background object, we might start with a parent level backgroundImage object — to separate the data stored from the color support?

So, in block.json:

supports: {
	__experimentalBackgroundImage : {
		parallax: true;
		focalPoint: true;
		… etc,
	}
}

Then in the style object:

style: {
	backgroundImage: {
		source: "file",
		url: "https://w.org/my-test-image.jpg",
		size: "150px",
		repeat: "repeat-x"
	},
	color: {
		background: "#000000"
	},
	spacing: {
		padding: "2rem"
	}
}

One potential benefit of starting with a parent level backgroundImage support is that if we wanted to move it further down the track, it might not to be too hard to move from backgroundImage to nesting within a background key if we wanted to consolidate things in further follow-ups?

[andrewserong]

Using this approach, I've made a start on a draft PR (#39243) to explore the viability of a dedicated background image support. I'll continue chipping away at it (it's very early) but happy for any feedback, of course!