Cover Block: Allow Opacity Option For Gradients/Colors

[justintadlock]

Currently, if you add a Cover block, the overlay opacity option only appears if you add a background image. If you use a solid color or gradient only, you get no opacity control. Of course, the original intention of the opacity option was for letting the user choose how much of the image bleeds through. So, it makes sense that it doesn't show up.

However, there are use cases where users might want to have a gradient/color that is transparent, particularly when a Cover block is nested within another block (like another Cover).

One of the patterns I've been working on uses a Cover nested inside of a Cover. The inside Cover uses a transparent color overlay now (with a framed border block style). It looks like this:

If I add a gradient color (no image) to the inner Cover, it looks like the following (no bleed through of the outer Cover):

What I want to achieve is the following, which would require control over the opacity:

It is possible to achieve this using rgba() for gradient presets, but we're talking adding 9 extra gradients for each existing gradient (to handle 0.1 - 0.9 transparency). And, that, of course, would be insane. :)

[ramonjd]

Might the G2 color control help when it's been migrated?

Seems like it's a good case. Not sure how far away it is. Here's the component integration tracking issue: #28399

[justintadlock]

That would require the end-user to edit the opacity of every color-stop of a theme-supplied gradient or still runs into the issue of themes creating extra gradient presets for multiple opacity levels.

A simple and already-existing UI element for controlling the opacity feels like a friendlier solution.

[ramonjd]

A simple and already-existing UI element for controlling the opacity feels like a friendlier solution.

Agree. It would be neat to be able to set the opacity of the overlay regardless of the content, e.g., image/video/color.

It's straightforward to add the opacity classes to the block container:

But the opacity value, of course, also affects the container's children. 👎

So there might be a couple of options:

Make the overlay element a sibling of the cover block's inner content so we can control its opacity independently

This would involve changing the markup, and therefore creating a deprecation. So something like this:

<div class="wp-block-cover alignfull">
    <div class="wp-block-cover__inner-container">
        <p class="has-text-align-center has-white-color has-text-color has-large-font-size">
            Test opacity controls
        </p>
    </div>
    <div class="wp-block-cover__overlay has-background-dim-70 has-background-color has-dark-gray-background-color has-background-dim">
    	// This is absolutely positioned and stacked lower than .wp-block-cover__inner-container
    </div>
</div>

It would allow us to set the opacity of anything in .wp-block-cover__overlay, but it's a pretty radical change, so not sure about that.

Use rgba background colors on the containing block

Targeting overlay background colors only, we could stop using color palette classes, e.g., .has-dark-gray-background-color and always apply an rgba style to the block container.

I'm not sure, but I suppose we could grab the hex value from the color picker and convert to rgba before applying the dimRatio as the alpha value?

<div class="wp-block-cover alignfull has-background-dim-70 has-background-color has-background-dim" style="background-color: rgba(40, 48, 61, 0.5);">
    <div class="wp-block-cover__inner-container">
	    <p class="has-text-align-center has-white-color has-text-color has-large-font-size">
	        Test opacity controls
        </p>
    </div>
</div>

Any other options that might suit?

[justintadlock]

We already add a <span> when a gradient is in use, at least when there is media:

<span aria-hidden="true" class="wp-block-cover__gradient-background has-slug-gradient-background"></span>

It shouldn't be a stretch to just use that same technique without media.

Honestly, it'd probably be better for us to go with consistent markup across the board going forward. The different markup based on whether there's an image, a fixed image, etc. makes for bloated CSS accounting for the various scenarios.

[glendaviesnz]

We already add a <span> when a gradient is in use, at least when there is media:

@justintadlock I have experimented with this approach at #35065 - seems to work well in theory - I just need to do some investigation in terms of what it means in terms of deprecations/migrations