Show opacity controls even when custom colors are disabled

[coreyworrell]

What problem does this address?

6.0 introduced opacity control for colors. It only appears though if custom colors are enabled. If you disable those and only allow a theme palette, you cannot control the color opacity.

It would be very cool to be able to limit colors while at the same time allowing an opacity of the theme's palette to be used.

What is your proposed solution?

Perhaps move opacity to a separate control inside the Colors panel. Currently setting an opacity changes the color to a custom color. Would be neat to keep the reference to the selected color, but allow opacity. Just like how the Cover block overlay colors works basically.

@annezazu

[annezazu]

@aaronrobertshaw curious if you have any insights or thoughts here :)

[aaronrobertshaw]

Thanks for the ping 👍

This is an interesting idea and would be a nice feature. I'm not sure there is an easy win here though.

Possible issues

The predefined colors in a restricted theme palette could be anything including CSS custom properties. This would make modifying the color value itself via a generic opacity control trickier.

There's be some design challenges to address as well. Primarily, the proliferation of opacity controls. We generally have text, background, and link colors but we could also have hover states, secondary colors such as striped table rows etc. That's a lot of opacity controls if we can't wrap those within existing components.

The Cover block's opacity control is a bespoke solution that is surprisingly complex and prone to causing some backwards compatibility issues as we refine the Cover block. That gives some extra cause for proceeding with caution. Ultimately, I'm not sure how portable the Cover block's approach is.

Options to explore

1. If we have a generic opacity control that is separate to a normal color control, perhaps we could access the computed color value via the color control's swatch, strip any alpha channel value, then apply the new opacity before updating the color attribute.
2. A generic opacity block support would be easy enough to implement but its value might be quite limited if you are applying it at a block level. Our ability to target inner elements/selectors with block support generated styles is limited at the moment (but slowly improving)
3. Add bespoke opacity controls to blocks that might benefit from the idea proposed in this issue.

[coreyworrell]

Would be neat to keep the reference to the selected color

@aaronrobertshaw skipping that part above, I don't think it would be any different than how it currently works. I assume that the existing solution is getting the rendered color (even if authored as a variable) and then converts it to an rgba value when opacity is adjusted? So it could work the same under the hood, just not expose the entire custom color UI, rather just the opacity slider.

[aaronrobertshaw]

Okay, I was distracted by the comment stating the desire for it to be like the Cover block opacity.

Just like how the Cover block overlay colors works basically.

Another option to explore might then be:

4. Rendering restricted ColorPicker control with everything other than the opacity restricted.
   • Add a new flag customOpacity or value for the color.custom flag in theme.json
   • A new ColorOpacityPicker component might be better than the current ColorPicker
   • Once the opacity is changed from the preset color, the new value is treated much the same as a custom color is
   • Once the opacity has been changed the normal preset classes won't be applied to the block

It might also be worth considering what colors we allow this for as transparency has accessibility implications. Enabling the alpha channel on text colors already impacts our contrast checking etc. Not a blocker just something to consider in the bigger picture.

[cbirdsong]

Currently the editor uses an inline style to accomplish this. Here's the same theme color swatch in Twenty Twenty-Two, but with the opacity adjusted on the second paragraph:

<p class="has-primary-background-color has-background">Lorem ipsum dolor sit amet, consectetur adipiscing elit. Eam stabilem appellas. Sed ne, dum huic obsequor, vobis molestus sim. Itaque rursus eadem ratione, qua sum paulo ante usus, haerebitis.</p>

<p class="has-background" style="background-color:#1a444787">Lorem ipsum dolor sit amet, consectetur adipiscing elit. Eam stabilem appellas. Sed ne, dum huic obsequor, vobis molestus sim. Itaque rursus eadem ratione, qua sum paulo ante usus, haerebitis.</p>

Enabling the opacity control with custom colors disabled would also lead to inline styles embedded into content, and I can't think of a way to avoid that[^1] outside of revamping the way the editor handles colors to rely on the split property trick, which would really bloat the CSS generated.

If this option is added I hope it will be not be the default, as one reason we disable custom colors is to avoid polluting our markup with inline styles.

[^1]: Eventually, the relative color syntax in CSS Color Level 5 will be great for this, but it hasn't yet shipped in any browsers.

[aaronrobertshaw]

If this option is added I hope it will be not be the default, as one reason we disable custom colors is to avoid polluting our markup with inline styles.

I wouldn't expect it to be the default either. It's more of a niche use case in my view and would require opt-in.

[coreyworrell]

Yes your option 4 sounds just like what I'd expect to happen. As far as accessibility, are you saying that the contrast checker cannot properly work with alpha values yet? Or are you saying that setting opacity could lead to bad contrast? If the latter, users are already warned about that with a message in the panel right? I don't see any reason to disallow certain colors, as ultimately it's the end-users' choice to have "inaccessible" content.

[aaronrobertshaw]

As far as accessibility, are you saying that the contrast checker cannot properly work with alpha values yet?

There are difficulties in accounting for multiple alpha layers to be able to determine whether minimum contrast levels have actually been attained. As a result, when transparent text is chosen, a generic "Transparent text may be hard to read" message is displayed. Some history can be found in the PR enabling the alpha channel for color block supports.

My point was that it is something to consider when the time comes to allow opacity changes to preset colors and what shape the potential flags in theme.json may take. Is it all or nothing? Or, should we allow more fine grained control such as allowing it for backgrounds but not text etc?

I don't see any reason to disallow certain colors, as ultimately it's the end-users' choice to have "inaccessible" content.

I agree we should respect and allow a user's choice. We also have a responsibility to help guide better decisions, design, and accessibility.