Stabilize border block support keys

[ndiego]

Related to:

• Stabilize Typography Block Supports Keys for WP 6.7 #63001 and
• Tracking: Addressing Design Tooling Consistency #43241

Borrowing from the format of #63001, this issue outlines the tasks needed to stabilize the __experimentalBorder support. Doing so will make it easier for third-party extenders to confidently build custom blocks that provide border support and modify existing blocks with this support.

Note that in order to provide backward compatibility for block plugins out in the wild, fallback support for the existing __experimental prefix should be provided.

Stabilize the following border block support and associated properties:

• __experimentalBorder → border
• __experimentalBorder.color → border.color
• __experimentalBorder.radius → border.radius
• __experimentalBorder.style → border.style
• __experimentalBorder.width → border.width

Tasks

• Update PHP block support code in lib/block-supports/border.php to use the non __experimental prefix, falling back to the __experimental prefix if available.
• Update the JS implementations of the border block supports to point to the non __experimental prefix, falling back to the __experimental prefix if available.
• Update the block.json schema to support the non __experimental prefix
• Update the core blocks' block.json files to use the non __experimental prefixes
• Update the supports documentation to include a section for border support.
• Update the block.json schema to remove the __experimental prefix. Note that the code in WordPress should still support the __experimental prefix, but at this stage, the experimental prefix will be treated as deprecated.

The PR for this stabilization effort should follow the approach used to stabilize the typography supports in #63401.

[hbhalodia]

Hi @ndiego, I would like to work on the issue.

Thank You,

[hbhalodia]

Hi @ndiego, I have created a draft PR - #64330, but I am seeing this PR needs lots of refactoring once the main referenced PR - #63401 is merged and working. This is because we can use a lot of things from the PR so we do not have redundant code issue happening.

Also, there are ongoing discussion happening on the typography supports stabilization, hence I am aiming to wait for the typography support stabilizing to get merged in trunk and then we can pick up the pace on this issue with the PR.

Though, I have once concern about the border supports, as the whole border is defined as experimental and not the inner supports, so if you can look at quickly on the PR if that is the way we can achieve to stabilize the border and have some initial feedbacks on the approach.

Thank You,

[ndiego]

@hbhalodia yes, any PR for this issue should follow the similar approach outlined in #63401. I would also recommend waiting until that PR is successfully merged.

[hbhalodia]

Thanks for the response, we can wait until #63401 PR gets merged.

[hadamlenz]

suspense! I hope it'll be backward compatible