Provide color panel for core/post-content

[nerrad]

What problem does this address?

Themes have the ability to define element color styles for the core/post-content block (container), however there are no user level interfaces for modifying those styles. For example, a theme could have something like this in its theme.json:

"core/post-content": {
				"elements": {
					"link": {
						"color": {
							"text": "var(--wp--preset--color--secondary)"
						}
					}
				}
			},

However there is no color panel for modifying the block level styling for this block:

What is your proposed solution?

Enable color supports for the core/post-content block.

[aaronrobertshaw]

While enabling the color supports themselves is straightforward there are a few edge cases around the PostContent block.

From memory, we don't have access to an individual post content block instance's attributes in the post editor and so can't reflect block-specific styles there. For example, a user specifies colors on the PostContent block in the Single template, then switches to the post editor, they won't see their color selections applied.

This comment when we added typography supports illustrates this issue to a degree as well.

After enabling the color supports, any theme.json/global styles applied colors are reflected in both editors.

Finding a neat solution that doesn't increase the disparity between the editors, while meeting user expectations, may be quite tricky.

Would it be acceptable to start out with enabling only the link color for the PostContent block? Would its use be mainly at a global styles level, minimising the issue with the post editor?

[nerrad]

Agreed, it's tricky, however, the disparity already exists for themes that choose to style things using theme.json so it does appear to be something that should be addressed regardless.

I think some of the work in merging the editors might help resolve some of this disparity. I think there has also been some conversation about exposing elements of the Post Content Block in the post editor so that context is available. It seems like a missing piece here.

[aaronrobertshaw]

It seems like a missing piece here.

Exactly. Until we have that, I'd be reluctant to increase the disparity between editors.

[scruffian]

This is the same problem that we have with the navigation block in focus mode (#39286). When the block is focussed we lose the context of the template, and the specific styles applied to that instance of the navigation block. I feel like this is a fair compromise, since you are editing content outside of the context in which it will finally be loaded. cc @getdave for a second opinion.

[scruffian]

In fact, I don't think this is even possible. A single post could be loaded in multiple contexts - for example the single.php, or the home page, or an archive/tag/category page. In each instance it is possible for it to have different styles depending on the color settings given by the context of the template.

[porg]

Tested PR #51326 on gutenberg.run/51326

• which created instance http://c61acnrc.gutenberg.run (destroyed in ca. 23h from now)
• Vanilla WordPress 6.2 with TT3 with default theme style (link color = color variable "secondary" = dark green)
• on Safari 16.5 on macOS 11.7.6 Big Sur

1. ✅ Placed paragraph blocks and images into document root. Formatted some text as links.

   • Changed colors for: Background, Text, Link Default/Hover. All worked.
   WordPress.Gutenberg.PR.51326.-.Color.Controls.for.Post.Content.mp4

2. ✅ Wrapped some paragraph blocks with inline links and/or images into Group blocks

   • Color definitions remained intact.
   WordPress.Gutenberg.PR.51326.-.Color.Controls.for.Post.Content.-.P.A.and.IMG.in.DIV.group.blocks.mp4

3. ❓ We certainly need more extreme examples of encapsulation to test whether this works reliable. Anyone with good stress tests in mind?

[porg]

Usability Feedback on how to set the look & feel for base elements like link text

With a blank mental state (prior reporting #51265) I had expected to set the global look & feel for links in the Inspector sections "Colors → Links" and "Typography → Links". That all this shall take part in "Blocks → Content Type" is not intuitive for newcomers.

• 👉 If it stays that way, then at said locations there should be at least a hint text with a jump link to Blocks → Content Type" to aid discovery.

Some Inspector Panels and how the deal with it

Colors → Links

• ✅ Offers to set the colors for Default and Hover.
• ❌ But only affects certain link types (like links in content aggregation areas)
  • This is conceptually wrong IMHO.
  • Here you should be able to set the global link look & feel, that is how a <a href="/destination">Link</a> looks, which has no class, and no other CSS selector than simply a and a:hover.

Typography → Links

• Offers to set the typography for Default
• ❓ But nothing for the "Hover" state of a link. Feels like a conceptual gap.
  • But yeah, I catch myself now applying old school CSS paradigms, which may not have their place in the modular CSS approach of block themes.

What I realize now in general between "Colors" and "Typography" on the top level of "Styles" is that the pseudo-classes like Hover are only represented in Colors, not typography. Is there an epic-issue which deals with this larger topic of how these state-depending formatting gets manage-able in Gutenberg?

[porg]

• Thanks to all who pushed this forward and implementing this!
• Always good to have one hack less in theme.json or custom CSS!
• Looking forward to 16.5!

[mrfoxtalbot]

We had an example of this issue in the support forums.