Size Change: +32 B (0%)

Total Size: 1.05 MB

_{compressed-size-action}

This fixes the issue in the patterns I flagged, so thanks!

Themes that add additional CSS for link colors need to make sure that user-provided styles are respected in every situation.

Link color is still an experimental feature, so changing the behavior is to be expected, right? Or is this something that will need to be documented?

I did manage to find one more edge case, where a nested link color is overridden by a link color on the parent container, but only on the frontend.

Editor	Front end

The group block has a white link color, but that individual paragraph uses a bright orange. In the editor, the <style>… is output before the block it applies to, but on the front end, the styles are output after the block. So the white link rule comes "after" the orange rule, and overrides it.

In the editor…

/* Before the group `div` */
.wp-elements-613a1a9b8f7d4 a {
    color: var(--wp--preset--color--white);
}
/* Before the `p` */
.wp-elements-613a1a9b8f45f a {
    color: #cf6100;
}

Link is orange ✅

On the front end…

/* After the `p` */
.wp-elements-613a1a9b8f45f a {
    color: #cf6100;
}
/* After the group `div` */
.wp-elements-613a1a9b8f7d4 a {
    color: var(--wp--preset--color--white);
}

Link is white ❌

Nice one @ryelle ! Pushed a fix at 8d38f00

Link color is still an experimental feature, so changing the behavior is to be expected, right? Or is this something that will need to be documented?

It needs to be documented. For themes that use the theme.json is not experimental.

Now it works in all the scenarios I could think of 👍🏻

ok, this PR may work at a practical level. Theoretically, this could break in some situations #34689 (comment)

What I don't like about this is that themes will need to fix some CSS and that they need to take care of not overriding user-provided styles. However, the current situation is also not ideal as blocks that use the a element are affected (button and cover, for example).

I'm going to let this sit for a few days in case we can come with an alternative that fixes the issues and doesn't have the drawbacks. If we don't, I'll update the tests and merge this.

cc @jorgefilipecosta @jasmussen in case you have thoughts.

What I don't like about this is that themes will need to fix some CSS and that they need to take care of not overriding user-provided styles. However, the current situation is also not ideal as blocks that use the a element are affected (button and cover, for example).

Themes will always be able to break things, whether for good or for bad. In this case, the removal of !important's feels worth any followup we might have to do. Thanks for the PR.

Thanks so much for your work on this @oandregal !
I agree with the comments re: leaning towards removing the !important if it's possible.

I'm guessing this applies to some of the comments about specific theme issues:
I noticed that when testing this PR with Twenty Twenty-One, in the editor, paragraph and group link color overrides weren't reflected, but they displayed properly when rendered on the front-end.

Thanks all for the help. I'm going to fix the tests for this one and will merge it.

@oandregal FYI I tried to build a block theme over the weekend and ran into this !important issue several times. I'm very glad it will be removed.

Rebased to get #34776 in (a potential fix for a failing e2e test)

Devnote

To review/clarify/check when time comes to publish it:

We've made some changes to the link color feature that affect its specificity and helped to fix some issues with links within container blocks:

• We've lowered the specificity of the link color rule in the block-library package. The selector is now :where(p.has-text-color:not(.has-link-color)) a, which resolves to 001 specificity.
• By doing so, we could lower the global styles specifitiy as well by no longer making it !important (only affects themes with theme.json). The global link uses the a selector and the link property within blocks uses <block-selector> a. By loading after the block-styles stylesheet, they'll have higher priority.
• When users select a color for the link, two things happen: the block wrapper gets assigned the class has-link-color and a new .wp-element-ID class. The styles for the link color are generated dynamically using the .wp-element-ID a selector, which is 011 specificity.

Given these changes, the theme needs to make sure its styles play well with user choices.