Refine the layer management of the Cover Block

[javierarce]

This issue describes a set of refinements for the Cover Block layer management and some ideas for further improvements that @jasmussen and I have worked on. Our explorations and designs for this issue are also available on this Figma file.

The core idea is to group all the layers (both overlays and media layer) inside a single sidebar section called Background, abstracting the organization of the Cover Block layers on the canvas and simplifying the block sidebar.

On this issue, we’ll share a vision for a potential first implementation and a list of refinements for the future.

Here’s what the layer management could look like:

The sidebar contains a list of items sorted by the position of the layers in the canvas.

Each layer item now includes:

• A preview of its content.
• A text description (Solid, Gradient, Pattern, Image, or Video).
• The percentage of the layer opacity.
• A button to remove the layer (more about removing layers below.)

As with color management, we placed the settings of the media layer inside of a popover. This will reduce the overall number of elements in the sidebar and will allow users to adjust the media properties in a more focused way.

Since the media layer is central to the Cover Block, clicking the minus sign won’t remove the item from the list. Instead, we’ll return the item to its initial empty state.

Adding a photo or a video is also managed from a popover:

Clicking the popover placeholder will open the system file picker, but we could also allow dragging an image as we do with the featured images.

The logic for adding overlays on top of the media layer could work as follows:

When adding layers, we prioritize speed, so instead of giving users the option to choose between a solid, a gradient, or a pattern; clicking the plus symbol will immediately add a solid layer with some opacity (a good default could be 50% black).

Clicking the plus button several times will add new solid layers. Ideally, we’ll insert a random color from the theme color palette (it would be cool to avoid repeating colors, but that logic could be hard to implement). Other more simple options could be: adding the default 50% black solid layer or repeating the last inserted item.

On this initial exploration, we don’t envision allowing users to reorder their layers. However, users will be able to organize them by updating their properties or removing and adding new ones.

Future layer management

Looking at the future of layer management for this and other blocks, we believe it could look like this: 


• Users will be able to drag layers and arrange them in any way they like.
• It will be possible to stack multiple media layers (let’s say, a video layer on the bottom and a transparent PNG on top), giving a lot of flexibility to users.
• Layers will support blend modes (or even duotone filters for images and videos!)

Explorations and designs for this issue are available on this Figma file.

Related discussions and issues:

• Background Tools Make "Background Tools" an easy API and add to Group / Columns #16479
• Background block support Background block support #38119

[jasmussen]

Nice, thanks for sharing. Perhaps the most important improvement is converging background tools into a single panel, with focal point tools available but reduced in prominence.

One challenge is that near term, it's likely going to be tricky to have separate opacity controls on a per-layer basis. When these get removed from each layer and become a single opacity across layers, it splits up the ItemGroup in a less elegant way:

But it might still be a good improvement to start with!

Another thing to ponder is whether we need to show the minuses always visible, or whether it's okay to show these on hover, like so:

In any case, it would be nice to get some more thoughts so we can land on a good strategy to move this forward!

[andrewserong]

This is looking very cool, thanks for sharing the designs! I think a dedicated Background set of controls makes a lot of sense, along with tucking away the image controls in a popover 🎉

I have a couple of questions, thinking about the existing color controls in the cover block, and how we might use these controls in other blocks / a generalised background block support for the Group block and other container blocks (possibly Column?).

• The Cover block also has a color control which doesn't appear in the screenshot (it's only currently displayed in the cover block after selecting an Overlay color, curiously 🤔). The control currently has Text and Background options. I assume we'd still have the Text option here (so we can cascade down text color within the block), but remove Background from that list? If so, I was wondering what then happens with the contrast checker, if it just stays there next to Text?

• When looking at a background image support that could be more generalisable than just the cover block in Add a Background Image Block Support and opt-in for the Group block #39243 (e.g. roll out background images to the Group block), part of the discussion was a simplified background approach that doesn't include an overlay, but just uses CSS values at the parent block container. Would this control also scale to that situation where we've got no ability to add additional layers, but want the user to select between a background color, a gradient, or a background image? (So more of a toggle situation rather than adding an arbitrary level of layers)

I totally understand of course if the goal at first is to see if we can improve the UI just for the cover block to begin with and expand from there. Very exciting work, indeed!

[jasmussen]

The Cover block also has a color control which doesn't appear in the screenshot (it's only currently displayed in the cover block after selecting an Overlay color, curiously 🤔).

Can you expand on this?

I know there's a text/background control that appears if you select the Paragraph inside the cover block. But that's separate from the Cover itself, right?

The control currently has Text and Background options. I assume we'd still have the Text option here (so we can cascade down text color within the block), but remove Background from that list?

This is a stumbling block we will run into in the future, absolutely, thanks for pointing it out. But I think we have some options:

• The fact that this uses the same ItemGroup used for colors, means that it could potentially merge with any other itemgroups. We'd just want to make sure to merge them in the right order so that the visual stacking order of the "layers" remain intact.
• This would be especially useful if we are able to make progress on Patterns as Sectioning Elements #39281, which suggests exactly that cascading ability you mention. Something like a "Selection Colors" panel which surfaces all colors of the children inside.
• Another option would be to separate the "Background" panel from the "Color" panel.

If so, I was wondering what then happens with the contrast checker, if it just stays there next to Text?

As soon as opacity or gradients are used, contrast checkers become unable to validate or confirm sufficient contrast anyway. A potential solution I've seen discussed in context of this, was to output a generic warning message, such as "Be careful with transparency, contrast with text overlays might not be sufficient", something like that.

part of the discussion was a simplified background approach that doesn't include an overlay, but just uses CSS values at the parent block container. Would this control also scale to that situation where we've got no ability to add additional layers, but want the user to select between a background color, a gradient, or a background image? (So more of a toggle situation rather than adding an arbitrary level of layers)

The ability to add layers is a bit forward-looking, but I've been thinking of this as a userfacing control handling the CSS for multiple backgrounds:

.myclass {
  background: background1, background2, ..., backgroundN;
}

That's just a comma separated list of backgrounds, which could be media, gradients or solid colors. The caveat is: no opacity (unless RGBA is used inside the flyout), hence this possible concession.

In that light, I don't see why a group block couldn't have "layers" as it were, it'd still be a single CSS value.

But to answer more high level, it seems completely fine to start with the panel/itemgroup/flyout simplification, and then explore whether layers, including the locking down of the ability to add more layers, could come later on.

What do you think?

[andrewserong]

I know there's a text/background control that appears if you select the Paragraph inside the cover block. But that's separate from the Cover itself, right?

Ah, apologies, yes! I've been looking at the Group block too long, and was too quick in my testing. The Cover block indeed doesn't have color controls for text. Though, like with the Group block, maybe it'd be good to be able to cascade down a text color / link control. I suppose we'd like both blocks to be great and versatile container blocks that are a foundational part of designs, so having all those controls at your fingertips will be quite useful. And I see there's an open PR (#37783 and earlier #31370) already to add border support to the Cover block.

The fact that this uses the same ItemGroup used for colors, means that it could potentially merge with any other itemgroups. We'd just want to make sure to merge them in the right order so that the visual stacking order of the "layers" remain intact.

That's an interesting idea! Plus, I see in your screenshots you've added some headings under Background — I suppose if we're grouping together the item groups with text color, we'd then need a different parent heading than Background, to semantically group them all together?

Another option would be to separate the "Background" panel from the "Color" panel.

I think this is possibly one of the trickier aspects for consistency across blocks. A separate Background panel makes good sense for Group or Cover blocks where we might want to have all the background and text color / link color options exposed. But for simpler blocks (like paragraph), it might be a bit overkill to have separate Background and Color panels?

I think I quite like your idea of seeing if there can be a single panel with different groupings for Background vs Color, but I wonder what would make most sense as a collective name 🤔

In that light, I don't see why a group block couldn't have "layers" as it were, it'd still be a single CSS value.

Oh, that's awesome! Thanks, I didn't realise you could add multiple backgrounds in the one property like that, very neat. In that case, yes, looks like we could still have the layout concept there 😀

But to answer more high level, it seems completely fine to start with the panel/itemgroup/flyout simplification, and then explore whether layers, including the locking down of the ability to add more layers, could come later on. What do you think?

Yes, I agree — I think since this discussion has brought up lots of different options and considerations, exploring changes to the UI (starting with the Cover block) makes a lot of sense to me, and then iterating from there.

My only concern with changes to the cover block, is when it comes to implementing new features and controls that change the markup. It's already quite a complex block with lots of deprecations, so when we get to implementing more layers, etc, it could be a good opportunity to explore a server-rendered block support (that doesn't update the saved post content in the database), to side-step adding too much extra complexity to that one block (while also opening up the potential for server-rendered values like feature post image). But that's probably more of a consideration for when we have a better idea of how those features should land.

Thanks for all the discussion points!

[jasmussen]

Awesome feedback. I'd love to be pinged on any work on this (and @javierarce too I'm sure), I definitely think we can implement pieces in a very incremental way, such as:

• Moving the image inside an itemgroup item under the first overlay layer, and move focal point management inside a flyout. Subheadings in a "Background" panel if need be.
• Explore whether the Alternative text control needs to live inside that same flyout, or whether it can sit as a separate panel on the top level, when a media item is added (see also Image: Improve the inspector, adopt the unified dimensions panel #38068)

After that, we can explore what merging of itemgroups, or what multiple-background-layer we mean to add on top of this. I think the ItemGroup can be a key interface to explore the boundaries of, especially with an eye towards #39281 which might or might not collapse child properties into a single panel depending on how that moves forward. #39452 also explores how the same ItemGroup can be used for when you want to add multiple filters to a single image, such as both Duotone and Dithering.

[priethor]

Thanks for the exploration, @javierarce .

Just to connect some dots, this design direction would supersede #20837, wouldn't it?

[jasmussen]

Just to connect some dots, this design direction would supersede #20837, wouldn't it?

I still think there's value in surfacing the first overlay as a color option in the block toolbar, as it'll likely be useful in 80% of the cases. If you want any additional layers, it's okay to do that in the inspector. Do you foresee any additional complications between the two?

[javierarce]

@priethor I agree with @jasmussen that, for the general use case where you have a solid layer (or a solid layer plus a media layer), it'll be helpful to have a way to change the main overlay from the toolbar… but if you happen to have more than two colors, it could end up being confusing: which color should the toolbar control? The one closer to the bottom of the stack or the one on top? And things will get messier if we allow ordering layers.

Since removing a feature from users is always a point of friction, I personally wouldn't add the color control in the toolbar of this block.

[paaljoachim]

Just a quick thought...
Should image instead be called media? So that one can add a general media item be it image, audio, video from the media library or through a URL? Example. A background video from Youtube going in a loop inside the Cover block. An audio embed playing in the background from Sound Cloud.

[javierarce]

Should image instead be called media?

I don't think so… at least my idea was to use the type of media as the name for the layer, so if you add a video, then the layer will be called Video.

On my first exploration, I also called the layer Media initially when the layer doesn't have any content.