Some CSS selectors get applied too often / wrong specifity

[Azragh]

The class .wp-social-link gets applied three times in a row in the compiled CSS which makes it higher specifity.

Step-by-step reproduction instructions

1. Open Dev Tools
2. Inspect Social Link from frontend

Expected behaviour

Should have only one class after .wp-block-social-links

Screenshots or screen recording (optional)

WordPress information

• WordPress version: 5.6.1
• Gutenberg version: 9.9.0 / 9.9.1
• Are all plugins except Gutenberg deactivated? "Yes"
• Are you using a default theme "Yes"

Device information

• Device: "Desktop"
• Operating system: "Windows 10"
• Browser: "Chrome"

[Azragh]

Just found this one:

Looks like a global compiling error or something ..

[tellthemachines]

It's not a compiling error, these are deliberate specificity bumps added for various reasons. See here for the search button and here for the social links.

The search button styles only affect the editor, but the social links are concerning as they affect the front end too. Cc @jasmussen

[jasmussen]

Yes, @tellthemachines is correct, this is intentionally done, though the CSS comments that indicate that it's intentional do not get included in the compiled files, they only exist in the uncompiled SCSS files. Here's a sample:

.wp-block-social-links {
    ...

    // Vertically balance the margin of each icon.
    .wp-social-link {
        // This needs specificity to override some themes.
        &.wp-social-link.wp-social-link {
            margin: auto 8px auto 0;
        }
    }

So why does that margin rule need to be high?

Because many themes output rules in their editor styles such as this one:

 [data-block] { 
    margin-top: var(--global--spacing-vertical); 
    margin-bottom: var(--global--spacing-vertical); 

    [data-block]:first-child { 
        margin-top: 0; 
    } 

    // Needs to be the second-last child to avoid applying this to the appender. 
    [data-block]:nth-last-child(2) { 
        margin-bottom: 0; 
    } 
 } 

This is from TwentyTwentyOne.

The intent of those theme rules is to provide a uniform and harmonious spacing between blocks in the editor. But the problem is, in the block editor everything is a block, every social link is a block. And so the above rules apply a top margin of zero for the first block, and a bottom margin of zero to the last block. That will cause a waterfall effect on blocks in a horizontal container, such as Social Links, Buttons, or Navigation, where the first social link is pushed upwards, and the last social link is pushed downwards.

Because so many themes do this, we saw it necessary to increase the specificity of the margin rule for horizontal blocks.

Longer term, I believe that the specificity can be reduced again, through giving themes tools to handle block spacing in a simpler way through global styles. But until then, I believe the rules remain necessary.

[markhowellsmead]

I would argue that Core CSS shouldn't try to override Theme CSS. This will lead to some problems, for sure, but it's down to the Theme author to fix their overly specific CSS, not the job of Core to override Theme CSS.