Related:

• Tracking: Addressing Design Tooling Consistency #43241
• Tracking: Color Design Tools Consistency #43245

What?

Enabling full color block supports for the calendar block.

Because the gallery block has a hardcoded background color for th and a hardcoded color for tbody and caption, this PR updates the CSS to limit these hardcoded colors where there's no has-text or has-background classes.

⚠⚠⚠ Note: updating the colors with custom values doesn't work reliably.

When selecting a preset color, followed by a custom color, the block doesn't rerender.

I've pinpointed it to the use of useDebounce in the ServerSideRender component.

The debounced function is called, but it doesn't fire. I suspect that it's cancelled too early here.

Maybe there's an equality check that's failing, because if add a _key: Math.random() to the top level of the attributes, or as part of the GET query args via urlQueryArgs it works.

The effect is easier to see if both "color.background" and "color.gradients" block supports are opted into.

Why?

To add the option to provide a background color to gallery blocks.
To create consistency across blocks.

How?

Adding the relevant block supports in block.json

Testing Instructions

1. Load the block editor with a calendar block. Make sure you have some recently published posts.
2. Confirm the colors control panel is there and has a background control.
3. Add background color or gradient, link text and text colors
4. Save and confirm the styles appear on the frontend