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

pbking · 2020-12-08T16:11:13Z

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.

As expressed by TT1's CODE block styles: https://github.com/WordPress/twentytwentyone/blob/trunk/assets/sass/05-blocks/code/_style.scss The default padding value of the CODE block is now the default spacing unit. WordPress/gutenberg#27582 is necessary for this enhancement to work.

scruffian · 2020-12-16T00:12:56Z

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

scruffian · 2020-12-18T08:58:50Z

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 · 2020-12-18T21:00:14Z

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 · 2020-12-18T21:01:31Z

There is a lot more discussion on this on #27579

aristath · 2021-02-17T09:33:06Z

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 · 2021-02-17T13:39:31Z

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 · 2021-02-17T13:50:35Z

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 · 2021-02-17T13:52:44Z

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 · 2021-02-17T14:06:00Z

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 · 2021-02-22T06:28:27Z

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 · 2021-02-22T07:00:17Z

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 · 2021-02-22T15:02:05Z

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 · 2021-02-22T17:33:07Z

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 · 2021-02-23T06:42:33Z

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 · 2021-10-14T19:41:31Z

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.

Added support for "padding" controls and styling of CODE block. Added support for "border" styling of CODE block (including color, style, width, radius. Added color support to code block

pbking · 2021-10-25T13:29:28Z

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.

pbking requested review from ajitbohra and talldan as code owners December 8, 2020 16:11

pbking marked this pull request as draft December 8, 2020 16:11

github-actions bot added the First-time Contributor Pull request opened by a first-time contributor to Gutenberg repository label Dec 8, 2020

This was referenced Dec 8, 2020

Migrate CSS for Code block for TT1-block theme WordPress/theme-experiments#113

Merged

Twenty Twenty-One Blocks: Migrate over default block styles as theme.json settings. WordPress/theme-experiments#82

Open

pbking changed the title ~~Enhance CODE block to support customizations of TT1-blocks theme.~~ Enhance CODE block to support padding customizations Dec 8, 2020

pbking force-pushed the enhance/code-block branch from 358ef81 to 8e4767f Compare December 8, 2020 21:08

pbking marked this pull request as ready for review December 8, 2020 21:08

pbking requested review from chrisvanpatten and mkaz as code owners December 8, 2020 21:08

scruffian requested a review from jorgefilipecosta December 9, 2020 14:48

pbking force-pushed the enhance/code-block branch from 8e4767f to 91a63f1 Compare December 15, 2020 17:33

pbking force-pushed the enhance/code-block branch 2 times, most recently from 84cb149 to aeaa472 Compare December 17, 2020 20:41

pbking requested review from spacedmonkey and TimothyBJacobs as code owners December 17, 2020 20:41

pbking changed the title ~~Enhance CODE block to support padding customizations~~ Enhance CODE block to support padding, color & border stylings Dec 17, 2020

pbking marked this pull request as draft December 17, 2020 21:40

scruffian mentioned this pull request Dec 18, 2020

Global Styles: Add support for default styles #27796

Closed

pbking force-pushed the enhance/code-block branch 4 times, most recently from fc7a9b6 to 6a4851a Compare February 16, 2021 16:07

pbking marked this pull request as ready for review February 16, 2021 16:56

talldan removed their request for review February 23, 2021 01:22

danieldudzic mentioned this pull request Feb 25, 2021

TT1 Blocks: Migrate Pullquote block styles WordPress/theme-experiments#225

Merged

Base automatically changed from master to trunk March 1, 2021 15:44

pbking mentioned this pull request Mar 17, 2021

Add CORE/CODE configurable styles to BCB Automattic/themes#3485

Closed

Added support for additional Block Supports to CODE block

01513a2

Added support for "padding" controls and styling of CODE block. Added support for "border" styling of CODE block (including color, style, width, radius. Added color support to code block

pbking force-pushed the enhance/code-block branch from 6a4851a to 01513a2 Compare October 25, 2021 13:28

Add margin controls to spacing

dcdc3f7

mkaz approved these changes Oct 26, 2021

View reviewed changes

scruffian merged commit 9e2974d into WordPress:trunk Oct 26, 2021

scruffian deleted the enhance/code-block branch October 26, 2021 12:59

github-actions bot added this to the Gutenberg 11.9 milestone Oct 26, 2021

andrewserong added [Block] Code Affects the Code Block [Type] Enhancement A suggestion for improvement. labels Nov 4, 2021

andrewserong changed the title ~~Enhance CODE block to support padding, color & border stylings~~ Code block: Add support for padding, color & border styles Nov 5, 2021

t-hamano mentioned this pull request Jul 29, 2024

Tracking: Border Design Tools Consistency #43247

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

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

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

pbking commented Dec 8, 2020 •

edited

Loading

scruffian commented Dec 16, 2020

scruffian commented Dec 18, 2020

pbking commented Dec 18, 2020

scruffian commented Dec 18, 2020

aristath commented Feb 17, 2021

MaggieCabrera commented Feb 17, 2021

aristath commented Feb 17, 2021

MaggieCabrera commented Feb 17, 2021

scruffian commented Feb 17, 2021

carolinan commented Feb 22, 2021

aristath commented Feb 22, 2021

pbking commented Feb 22, 2021

carolinan commented Feb 22, 2021 •

edited

Loading

aristath commented Feb 23, 2021

mkaz commented Oct 14, 2021

pbking commented Oct 25, 2021

mkaz left a comment

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

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

Conversation

pbking commented Dec 8, 2020 • edited Loading

Description

How has this been tested?

Types of changes

Checklist:

scruffian commented Dec 16, 2020

scruffian commented Dec 18, 2020

pbking commented Dec 18, 2020

scruffian commented Dec 18, 2020

aristath commented Feb 17, 2021

MaggieCabrera commented Feb 17, 2021

aristath commented Feb 17, 2021

MaggieCabrera commented Feb 17, 2021

scruffian commented Feb 17, 2021

carolinan commented Feb 22, 2021

aristath commented Feb 22, 2021

pbking commented Feb 22, 2021

carolinan commented Feb 22, 2021 • edited Loading

aristath commented Feb 23, 2021

mkaz commented Oct 14, 2021

pbking commented Oct 25, 2021

mkaz left a comment

Choose a reason for hiding this comment

pbking commented Dec 8, 2020 •

edited

Loading

carolinan commented Feb 22, 2021 •

edited

Loading