Code block: Add support for padding, color & border styles

[pbking]

This is needed to resolve WordPress/theme-experiments#94 to support TwentyTwentyOne-blocks theme.

Description

• Added spacing.padding support option to core/code block's block.json to signal support of customizing the padding values of the block allowing themes and users to customize the padding values of CODE blocks.

• Added color supports options to core/code block's JSON to allow support of customizing color values in theme.json and by users.

• Added border supports options to core/code blocks's JSON to allow theme.json support for customizing that block's border

• Updated documentation to reflect that the CODE block includes padding controls.

• Added style.border controls to CODE block's block.json to signal support of border settings

• Added style.color to CODE block's block.json to signal support of color settings

How has this been tested?

• Adding the following JSON to the TT1-blocks' theme.json file (as demonstrated here):

		"core/code": {
			"typography": {
				"fontSize": "var(--wp--preset--font-size--extra-small)"
			},
			"spacing": {
				"padding": {
					"top": "var(--wp--custom--spacing--unit)",
					"bottom": "var(--wp--custom--spacing--unit)",
					"left": "var(--wp--custom--spacing--unit)",
					"right": "var(--wp--custom--spacing--unit)"
				}
			},
			"border": {
				"radius": "0px",
				"color": "var(--wp--preset--color--dark-gray)",
				"style": "solid",
				"width": "1.5px"
			}
	
		}

Resulting in a wp-block-code class that includes the padding variables as expected

• Add and select a CODE block in the block editor
  • note that the SPACING panel has been added to the interface
• Using the SPACING panel modify the padding values for the CODE block and save the page/post.
  • observe the rendered page and observe that the border properties defined in the interface are set on the block's style attribute.

<pre class="wp-block-code" style="padding-bottom:20px;padding-left:20px;padding-right:20px;padding-top:20px"><code>This is a code block.
&lt;div fancy="true"&gt;
{ super: "duper" } </code></pre>

Types of changes

New feature

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.

[scruffian]

I notice that the theme.scss contains default padding values. Do we have a way to set these without CSS?

[scruffian]

When I set the border radius to 0, it picks up the 4px border radius from the CSS. I think this is why we need to have these default values move to the JSON when they are default.

I opened an issue for this: #27796

[pbking]

Looked at another way, the value of '0' (in this context especially) doesn't mean "unset" even though that is what is implied. Another way to address this would be to have this radius control differentiate between '0' and 'unset/reset'

[scruffian]

There is a lot more discussion on this on #27579

[aristath]

Should the code block even have these controls?
twentytwentyone has some pretty opinionated styles, and not all of them should be exposed to users. Some things should still be in the theme's stylesheets...
We need to have a balance between functionality and noise, if we add all available options to all blocks it becomes too noisy and harder to use 🤔

[MaggieCabrera]

We need to have a balance between functionality and noise, if we add all available options to all blocks it becomes too noisy and harder to use 🤔

I agree that not all blocks need all options available to the user, but why not to the theme developer? If we are building tools that let the theme dev control the block in such a way by using theme.json, why are we not giving them the tools just because we may not want the end-user to have access to them as well?

[aristath]

My apologies, I thought that the plan was to eventually expose all these things to the user. Are these only dev-facing with no plans to expose the related controls to users?

[MaggieCabrera]

My apologies, I thought that the plan was to eventually expose all these things to the user. Are these only dev-facing with no plans to expose the related controls to users?

Sorry I think I came up a bit strong there. This PR does surface the options to the users, I just wanted to express that it shouldn't have to be that way every single time, and this case in particular is a good example where the user shouldn't see the controls but the themer should have the ability to modify them on the theme.json file

[scruffian]

Yeah the problem is that at the moment making it possible to modify these things in the theme.json also enables the user controls. This needs to be decoupled.

[carolinan]

I suggest exposing text color, background, and font family.
Because I think it is common for themes to set a font family for code blocks that is different from a regular paragraph, and
some users may want to change that font.

Being able to set colors can make a code block stand out more, and this can be combined with the inline text color for highlighting parts of a code.

[aristath]

and font family.

Code blocks should normally use a code/monospace font-family. If the user is able to select a normal serif/sans-serif font-family, then it will simply be used as a paragraph block with weird styling... It is semantically a code block so it should use a code font-family. I fear that if we add too many options there (including font-family) it will be abused for its appearance instead of its semantic value.

[pbking]

and font family.

It is semantically a code block so it should (anything could go here and I would disagree)

If I as a User, or I as a Theme Author want to style code blocks to be in comic-sans or cursive I'm not sure why that should be something dictated by Gutenberg. It can still be semantic, expressing "code" using whatever stylistic opinion.

If I can't do that (or the like) via configuration then we chase that into CSS. Is it our understanding then that those decisions SHOULD be expressed in CSS instead of configuration? (If it doesn't align with Gutenberg opinion then CSS is the avenue?)

[carolinan]

For example, this is an image of a system font stack and "monospace", for me these fonts are too similar and I can't distinguish the code.

Especially when the code is inline (which is why I only now noticed that the <code> does not wrap the last letter in palette).

Same fonts but with a code block:

[aristath]

If I can't do that (or the like) via configuration then we chase that into CSS. Is it our understanding then that those decisions SHOULD be expressed in CSS instead of configuration? (If it doesn't align with Gutenberg opinion then CSS is the avenue?)

They should be expressed in the config file and in CSS, but not necessarily exposed to users in a prominent fashion like in a paragraph block or a heading...

From the MDN docs:

The HTML <pre> element represents preformatted text which is to be presented exactly as written in the HTML file. The text is typically rendered using a non-proportional ("monospace") font. Whitespace inside this element is displayed as written.

If a designer wants to use comic-sans then they can write CSS to do that, but in that case the code block no longer represents "code" visually.
The fact that we can do something doesn't mean we should, and we should at least try not to make it easy for end-users who don't necessarily understand the semantic value of a code block to break the expected behavior of the web.

[mkaz]

This PR looks still to be valid, ignoring the font-family discussion which is not included in this PR in the first place, so that can be tabled and discussed elsewhere.

@pbking If you can rebase and update, we can move this forward with the border, spacing, and color additions.

[pbking]

Rebased as requested.

[mkaz]

This tests well and looks good. 👍

I added top-bottom margin support that is another useful feature to give additional space around a code block.