Link text does not have its defined color but falsely color from button text

[porg]

Description

• Pure links in paragraphs, like <p>Check out <a href="https://wordpress.org">WordPress</a> as your CMS.<p> falsely are rendered with the color definitions of button text (e.g. dark green), although in the Site Editor the Style for links is set as default (color variable "Contrast" which is black text on white background).

• CSS specificity / selector bug. Either in Style Engine or TT3 theme.

Screenshots

Reproduction

• Use a Vanilla WordPress with the Twenty Twenty Three theme.
• Create a new page or post.
• Create a paragraph
• Type the text: "Check out WordPress as your CMS."
• Select WordPress and link it to https://wordpress.org
• End result HTML:

<p> Check out <a href="https://wordpress.org">WordPress</a> as your CMS.<p>

• The link is just a plain <a> element without any extra classes.
• Nevertheless a CSS selector for buttons seems to interplay here unintentionally:

<style id='wp-block-post-content-inline-css'>
    .wp-block-post-content a:where(:not(.wp-element-button)) {
        color: var(--wp--preset--color--secondary);
    }
</style>

Expected: I expect the link to have the style which is defined at: Styles → Colors → Link (definitions for Default + Hover)

Actual: Somehow the styles from Button take precedence.

Further observations: Even if I make the colors for Default/Hover links something striking like red/pink, this has no effect.

Environment

• WordPress 6.2
• Gutenberg 15.9.1
• Occurs on my install (with plenty of plugins and a child theme of TT3)
• But also on a vanilla WP, which I confirmed, when running gutenberg.run with PR 51011 which concerns link pasting, but otherwise has no changes regarding link styling (the symptom is the same as on my system)
• Safari 16.5 on macOS 11.7.6 Big Sur

[porg]

@carolinan:

• You have a lot of CSS and block theme expertise.
• Could you please look into this?

[porg]

• I had found no other bug prior filing this one.
• The closest I found is Buttons that don't have .wp-element-button class have wrong text color #45213
• On the surface level, from all its ingredients, it looks a bit similar, but due to a lack of expertise I cannot further estimate the relatedness.

[porg]

IMHO removing the "Beta" from the "Site Editor" seems somehow premature, if fundamental things like link color (the link is the core of HTML so to speak) don't work reliably in TT3, which again is the current reference block theme.

[porg]

❗️ IMHO this is a real serious CSS / theme / style-engine bug which should get an expedited investigation

• Because there's really no workaround by means of the Site Editor GUI.
• Not even workarounds that sacrifice something else! None!
• You have no possibility whatsoever to customize the color of the link, the basic element of the WWW. That is a very serious bug for a CMS and theming system.
• See for yourself below.

1. Attempt to customize link text color while using the default theme style in TT3:

• a) Setting theme color → ❌ Ignored
• b) Setting any of the default colors → ❌ Ignored
• c) Define your own color and then assign it → ❌ Also Ignored

Link.Color.definition.with.default.TT3.style.fails.in.paragraph.but.at.least.works.in.comment.section.mp4

2. Attempt to customize link text color while using a particular theme style like "Aubergine" in TT3

• ❌ is ignored not only in paragraphs, but also in links in the comment section
• No chance whatsoever.

Link.Color.definition.completely.ignored.if.particular.style.like.TT3.Aubergine.active.mp4

3. Setting the seeming "offender", the button style, to something else in the hopes to then at least get your desired link text color

• ❌ No success either.

Link.Color.definition.workaround.to.correct.the.seeming.offender.fails.too.mp4

[scruffian]

Twenty Twenty Three contains this in the theme.json:

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

This block of code styles links that are within the Post Content block differently from those within the rest of the site. Unfortunately there is no UI to modify these links yet, which is why you are understandably frustrated that it isn't possible to change the color of these links. It would be great to add these to the Global Styles interface, so I created an issue for that here: #51272

[scruffian]

I think this is expected, albeit confusing behaviour so I'm closing for now. We can track in #51272.

[porg]

Thanks

• For letting me know the reason behind!
• The user feature is necessary without doubt, hence glad that you created the technical foundation ticket for this.

In the meantime…

Is there a workaround?

• I use a TT3 child theme
• And have a functions.php
• with a tt3childtheme_enqueue_block_styles() which runs on init.

If so, by what approach/paradigm does this work?

1. "Muting" that core/post-content → link → color → text,
   • a) and then I can set Colors → Link → Default/Hover as intended?
   • b) Which negative effect would that "muting" have?
2. Creating a selector with which I can set a color for Link Default/Hover, but then have to do this by CSS file only, and have no GUI editing possibility?

[scruffian]

@porg the easiest workaround would be to add this to the theme.json file of the child theme:

			"core/post-content": {
				"elements": {
					"link": {
						"color": {
							"text": "[YOUR_COLOR_HERE]"
						}
					}
				}
			},

Hope that helps.

[porg]

Followup question

From a UX designer with understanding of CSS and data structures and serialized formats such as JSON to a certain degree, but not too deep.

Understanding interplay of theme.json of child theme & theme.json of parent theme was impossible to grasp

• When I tried around 04/2023.
• My conceptual/practical struggles:
  • In some case an attribute in child theme.json worked as an override of a particularly targeted attribute (as intended)
  • In other cases instead of adding one additional element (extra color in the child theme) to a 10-element array (color palette of parent theme) it overrode the full array of the parent, and effectively transformed it into a 1-element array.
  • Duplicating theme.json from the parent into the child theme and then modify it, would defeat the purpose of a child theme, as being an incremental addition to the parent theme, which continues to receive updates. It works in the moment, but as soon as the parent theme get's an update, you effectively "block all/most of the attributes" with your duplicated then outdated values.
• Back then there was no good documentation available on this. Good links appreciated!

Concretely for your proposed fix

1. If I create a theme.json containing solely your fix and nothing else (= incremental in nature): Can this work, so that it only overrides exactly this, and leaves everything else (also along the attribute path) intact?
   • As mentioned above, things in that respect did not work as expected to me.
2. You only stated part of the JSON path. What would be the full path (in TT3) that I really only override that particular value?

If such an incremental theme.json override is not (yet) possible

• With what extra CSS can I select such a general element as <a> that I win the "CSS specificity battle" against that unintended selector?

[porg]

@scruffian Tested your PR and reported my results.

• That would be an even better fix than an incremental theme.json in the child theme folder.
• I hope that this makes it into the Gutenberg plugin in a matter of days or weeks, and into the next WordPress in some more weeks or some months.

[porg]

@scruffian As I had feared I failed miserably with my attempt in wp-content/themes/tt3childtheme/theme.json which in its completeness (280 bytes) is:

{
	"$schema": "https://schemas.wp.org/trunk/theme.json",
	"version": 2,

	"styles": {
		"blocks": {
			"core/post-content": {
				"elements": {
					"link": {
						"color": {
							// Value in parent theme.json
							// "text": "var(--wp--preset--color--secondary)" // which is  #345C00

							// My override attempts in this child theme.json
							// "text": "blue"
							// "text": "#0000ff"
							"text": "var(--wp--preset--color--custom-plain-inline-links)"
						}
					}
				}
			},
		}
	}
}

• I had used an almost empty JSON, just replicated the complete data structure path from the parent theme.json counterpart in the child theme.json until the attribute which shall get overriden.
• ❌ It has no effect in the frontend!
• ℹ️ I'm aware that JSON does not permit comments. I used them only here for the purpose of demo/explanation. On my server I used no comments. Nevertheless: No visible effect.

[porg]

• FYI: Overwriting the attribute in the parent theme.json worked instantly, no problems.
• But all WordPress documentation/literature encourages to do customizations in child themes instead of "duplicate'n'modify" an existing theme.
  • But with theme.json in a child theme, additive/incremental mods seem hard or sheerly impossible. Cannot grasp how it's supposed to work.
  • Found no good resources on this so far. And my trial and errors were without luck.

[porg]

To me this incident today (again 6h wasted) was the nail in the coffin of working with a child block theme.

• Exported it as a standalone theme.
• Now overwriting theme.json in place.
• Will not get any TT3 theme updates anymore, but that's neglible in comparison to all the problems which I always had with child block themes, which at the moment are only "beta" software.

[scruffian]

@porg sorry for the frustrations you've been having with this, thank you for your persistence. I have created this demo TT3 child theme which I hope might help: https://github.com/scruffian/themes/tree/trunk/twentytwentythreechild

For me, this theme shows links in post content as red.