added outline support for blocks via theme.json

[MaggieCabrera]

What?

This PR adds support for outline for blocks and elements via theme.json

Why?

This is something themes have to add most of the time using CSS. We should discuss what's the best way to surface this to the UI and which blocks should show the option, but the first step is here to allow themes to set it using theme.json instead of having to write CSS for it.

How?

I implemented this following the lead of #41972

Testing Instructions

I'm testing TT3, with this in theme.json:

"elements": {
	"button": {
		"outline": {
			"offset": "3px",
			"width": "3px",
			"style": "dashed",
			"color": "red"
		},
		":hover": {
			"outline": {
				"offset": "3px",
				"width": "3px",
				"style": "solid",
				"color": "blue"
			}
		}
	}
}

Screenshots or screencast

/cc @WordPress/block-themers

[scruffian]

LGTM

[ajlende]

I think these two arguments are for box model generation (top, right, bottom, left) which outline doesn't have. They should probably be removed here and passed directly to the generateRule function.

@ramonjd am I correct in thinking that? Or does this not matter?

[ramonjd]

Thanks for the ping!

I think these two arguments are for box model generation (top, right, bottom, left) which outline doesn't have.

While they share similar arguments, box model generation should use generateBoxRules rather than generateRule.

Example is margin. Note the margin%s pattern for individual sides:

const margin = {
	name: 'margin',
	generate: ( style: Style, options: StyleOptions ) => {
		return generateBoxRules( style, options, [ 'spacing', 'margin' ], {
			default: 'margin',
			individual: 'margin%s',
		} );
	},
};

So I think this looks okay.

They should probably be removed here and passed directly to the generateRule function.

I don't think it matters in practice, but in theory it might be better to be explicit about the arguments passed to generateRule, rather than set them as defaults.

There is little risk of it I'd say, but it would prevent unexpected path and ruleKey values being pass to the generate functions.

See how typography is set up, e.g., :

const fontSize = {
	name: 'fontSize',
	generate: ( style: Style, options: StyleOptions ) => {
		return generateRule(
			style,
			options,
			[ 'typography', 'fontSize' ],
			'fontSize'
		);
	},
};

[ajlende]

@ramonjd Thanks for sharing!

I was able to do some refactoring to remove the dependence on those two arguments to enforce consistency between all of the styles. Details are in #43594.

If we make the changes to be more like typography there wouldn't be any conflicts with it in this PR.

[ramonjd]

We should discuss what's the best way to surface this to the UI and which blocks should show the option

Let us know when this happens as we'll probably need to support outline in the style engine PHP classes as well. 👍

---

Not related to this PR (also on trunk), but it exposes how core classes are called before the extended Gutenberg classes.

I see this PHP notice in the editor:
Notice: Undefined index: button in /var/www/html/wp-includes/class-wp-theme-json.php on line 1482

The core Theme JSON class is trying to parse element selectors but button doesn't yet exist on the whitelist.

[colorful-tones]

This would be a great addition. I'm not sure I'll have time to test though. Just leaving feedback 😄

[ramonjd]

These changes need an Unreleased change log entry, e.g.,

## New features 

- Adding outline support in the Style Engine JS package [#43526](https://github.com/WordPress/gutenberg/pull/43526)

[oandregal]

Hey, while working on #46579 I realized this PR was not backported to WordPress 6.1. When we land that PR and then backport to WordPress 6.2 everything will be fine, but I wanted to raise in case you think this should be ported for a potential WordPress 6.1.X release.

[MaggieCabrera]

Thanks for letting me know @oandregal ! I don't know how urgent this one would be. I believe TT3 did not implement this but some other themes like Blockbase, Block Canvas... do have it.

I created a backport PR in any case WordPress/wordpress-develop#3788

[MaggieCabrera]

as it was mentioned on my PR, this change would benefit from some unit tests, but I don't think I can get to that before my vacation starts. If adding this is to a point release is time sensitive, I'm happy to wait until we can add those tests.

[hellofromtonya]

Update: The backport (see Core Trac 57354) has been committed into Core with a unit test ✅