Add support for border configuration via theme.json

[pbking]

Description

With this change a block can be configured to allow a theme to define
border color, width and style in addition to the already available
radius.

How has this been tested?

To leverage this change a block must first be configured to support this change.
For my test I did this with the CODE block. The details of that can be found here.
Specifically to the block.json file the following was added:

	"supports": {
		"__experimentalBorder": {
			"radius": true,
			"color": true,
			"width": true,
			"style": true
		},

With this change in place I added to a Block-based theme (tt1-blocks) the following to the experimental-theme.json:

	"core/code": {
		"styles": {
			"border": {
				"radius": "0px",
				"color": "blue",
				"style": "dotted",
				"width": "4px"
			}

Which you can see demonstrated here.

When a code block was rendered with that theme the results were as the theme was configured:

I am not aware of what unit- or functional-tests should be added to support this change and so have not done so.

Types of changes

This enhancement allows BLOCKS to add support for border color, style and width. Unless the block adds support for these features then those border attributes remain un-style-able.

This enhancement does NOT allow a USER to make stylistic changes to the border attributes, only by way of a theme.

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• My code has proper inline documentation.
• I've included developer documentation if appropriate.
• I've updated all React Native files affected by any refactorings/renamings in this PR.

[gziolo]

I don't know how the whole system works, but on the surface, it aligns with other config options. Are there any recommendations created that would help reviewers to decide?

[oandregal]

Gave this a try, there's a missing piece for this to work on the site editor as well (it uses a different mechanism than the other editors): essentially, add to the __EXPERIMENTAL_STYLE_PROPERTY at https://github.com/WordPress/gutenberg/blob/master/packages/blocks/src/api/constants.js#L15 the same configuration added to the PHP schema.

With that change, this will technically work. So far, the way we approached this kind of change was that whoever wanted a particular feature (say, borders) had to do the full work ―both infrastructure and UI controls― to distribute the workload among people. I'd like to hear what other people think of fast-tracking the infrastructure work and let UI work for later.

[gziolo]

With that change, this will technically work. So far, the way we approached this kind of change was that whoever wanted a particular feature (say, borders) had to do the full work ―both infrastructure and UI controls― to distribute the workload among people. I'd like to hear what other people think of fast-tracking the infrastructure work and let UI work for later.

I personally find it far more important to let themes and site authors to configure those styling options. In fact, I wouldn't be surprised seeing sites don't expose UI controls to remove clutter in the editor.

[scruffian]

I think we can go ahead and merge this.

[github-actions]

Congratulations on your first merged pull request, @pbking! We'd like to credit you for your contribution in the post announcing the next WordPress release, but we can't find a WordPress.org profile associated with your GitHub account. When you have a moment, visit the following URL and click "link your GitHub account" under "GitHub Username" to link your accounts:

https://profiles.wordpress.org/me/profile/edit/

And if you don't have a WordPress.org account, you can create one on this page:

https://login.wordpress.org/register

Kudos!

[oandregal]

👋 I've noticed this landed without support for the site editor, as suggested here. Prepared a fix at #29618