Stabilize the Experimental block supports property

[karthick-murugan]

What?

Split from #64314

Why?

The __experimentalDefaultControls property developers can choose which settings are displayed by default in the Editor for each block support. The __experimental prefix removed and now make it easier for third-party developers to confidently use this defaultControls property. Also, falling back to the __experimental prefix if available.

__experimentalDefaultControls → defaultControls

I have added the supports for those hooks:

Color
Typography
Spacing
Border
Now both are workable __experimentalDefaultControls & defaultControls

How?

This PR adds support for __experimentalDefaultControls & defaultControls in the blocks.

Testing Instructions

Testing Instructions for Keyboard

1. Open block.json file or area.
2. If you have already used for block support __experimentalDefaultControls instead of we can use it defaultControls only.
3. Block support default controls now managing by using this defaultControls property

Note: Here we need to update the WP core blocks' block.json files to use the non __experimental prefixes.

Screenshots or screencast

REC-20241118162707.mp4

[github-actions]

Warning: Type of PR label mismatch

To merge this PR, it requires exactly 1 label indicating the type of PR. Other labels are optional and not being checked here.

• Type-related labels to choose from: [Type] Automated Testing, [Type] Breaking Change, [Type] Bug, [Type] Build Tooling, [Type] Code Quality, [Type] Copy, [Type] Developer Documentation, [Type] Enhancement, [Type] Experimental, [Type] Feature, [Type] New API, [Type] Task, [Type] Technical Prototype, [Type] Performance, [Type] Project Management, [Type] Regression, [Type] Security, [Type] WP Core Ticket, Backport from WordPress Core, Gutenberg Plugin.
• Labels found: .

Read more about Type labels in Gutenberg. Don't worry if you don't have the required permissions to add labels; the PR reviewer should be able to help with the task.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: karthick-murugan <[email protected]>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[aaronrobertshaw]

Thanks for putting this PR together @karthick-murugan 🙇

I'm not sure the approach aligns with the overall stabilization of block supports pioneered by the recent typography stabilization. The soon to land border support stabilization also extends #64301's approach to borders.

In that vein, I already had a draft PR, #67018, up that refactors the approach further to cover stabilizing __experimentalDefaultControls and __experimentalSkipSerialization.

The delay in finalizing that draft PR, was due to the __experimentalSkipSerialization being hardcoded in checks within core. I have a workaround for this in place but I needed extra time to complete further testing and write up more unit tests.

Would you be opposed to closing this PR in favour of #67018 and making the stabilization of these shared support flags consistent with other support stabilizations?

[karthick-murugan]

Thanks for putting this PR together @karthick-murugan 🙇

I'm not sure the approach aligns with the overall stabilization of block supports pioneered by the recent typography stabilization. The soon to land border support stabilization also extends #64301's approach to borders.

In that vein, I already had a draft PR, #67018, up that refactors the approach further to cover stabilizing __experimentalDefaultControls and __experimentalSkipSerialization.

The delay in finalizing that draft PR, was due to the __experimentalSkipSerialization being hardcoded in checks within core. I have a workaround for this in place but I needed extra time to complete further testing and write up more unit tests.

Would you be opposed to closing this PR in favour of #67018 and making the stabilization of these shared support flags consistent with other support stabilizations?

Thanks @aaronrobertshaw for the detailed overview. I am closing this PR.