I really like that this removes the need to have media + text or a group, alternatively some other complicated confusion of blocks - to get this result.

Very cool! Just a note on this regarding the concept of responsivity, I have a page building plugin that does something similar and I have had quite a few users complain about background image placement, specifically on mobile.

White-text over a dark-part of an image is readable, but on mobile, everything can be different, and often white text ends up over a white-area of the image. I think this type of thing also requires responsive controls, similar to what is proposed here:
#20244

We could even add support for multiple background images to allow for stacked layouts.

Allowing the background to be resized by dragging is great! I'd also like to see this eventually integrate with any of the grids we've been exploring – dragging and snapping to a grid.

In a comment from @paaljoachim #14483 (comment) he mentions...

I do believe we need to think of a new way to in general create a new resize component. Which can be used in multiple Blocks where resizing would help the layout of multiple elements.
We might even need to look into creating a new resize component issue to be used for multiple blocks. I believe this is a discussion we should have in design.

I think that's a good idea!

Hi all, I’m sharing a design proposal by @javierarce and myself that would enable background editing functionality for the Cover block. This would add image editing functionalities to the Cover block so that users don’t need to resort to outside tools, and improve the editing tools available for the Image block. This concept was originally shared on the Make Wordpress blog, where you can read the proposal in more detail (including the issues that we identified with current image management tools).

Overview

We’ve broken down this proposal into three walkthroughs that help explain our proposal. These prototypes are self-guided, just open each of them and advance to the next slide clicking each screen. A series of notes will explain each concept.

One idea that spans across this proposal is the introduction of a secondary toolbar that looks distinctively different from the default toolbar in order to make it clear when the user has entered and exited the editing state. These new toolbars would present a title indicating that the user is now inside a different mode, the set of options for the functionality, and links to apply and discard the changes.

Editing/cropping tools for the Cover block

The introduction of a secondary toolbar could be a clean way of introducing inline editing tools to the Cover block.
With this proposal, we tried to reimagine how resize handles and inline editing tools could work together to create the background editing functionality we'd like to achieve.

View walkthrough

Fill modes

The ability to switch between different display modes such as Fill, Fit, Tiled, or Crop would be a great addition to the Cover block secondary toolbar.

View walkthrough

Editing/cropping tools for the Image block

Here’s a walkthough of how these same changes could be applied to the Image block's existing editing context.

View walkthrough

Nice! It's inspiring we are considering better focus and awareness signals of where you are and what you are doing.
There's however a bit of an unbalance in this approach where fill modes seem squeezed, and the focus is on the location sign, not on the actions?

Also consider that the snackbars used in the prototype can clash with the inspector, or even with the current notification snackbar.

Thanks @pablohoneyhoney!

There's however a bit of an unbalance in this approach where fill modes seem squeezed, and the focus is on the location sign, not on the actions?

Another possibility we explored is the idea of splitting the toolbar into two different sections. This could be a clear way to differieniate the editing context without adding visual weight with the dark color. We did have some questions about feasibility so decided that color was probably a more simple differentiator. Does this split approach seem worth looking into further?

Also consider that the snackbars used in the prototype can clash with the inspector, or even with the current notification snackbar.

I should have clarified that we just added these snackbar notes to help guide people through the prototype but those wouldn't actually be visible in the editor :)