Gutenberg: Front-end style.css specificity audit

[m-e-h]

I know it's been mentioned but I couldn't find a relevant issue to attach this to. So I've opened this one to give the conversation a home.

Describe the bug
Many selectors in the build/block-library/style.css file are unnecessarily nested and over-qualified.
This makes it difficult for themes and plugins to override and adds weight to the front-end file.

Wasn't sure if a single or multiple PRs would be better so I did a quick run through build/block-library/style.css and created a gist with comments where I think things could improve.
https://gist.github.com/m-e-h/2e3ab2ee68825bd2728edd52be96be95

I'm not super familiar with how the styles got to where they're at so some of my suggestions are probably not possible. I'm also sure there are some areas for optimization that I missed.

Similar
https://github.com/WordPress/gutenberg/issues/1720
https://github.com/WordPress/gutenberg/issues/11677
https://github.com/WordPress/gutenberg/issues/10067
https://github.com/WordPress/gutenberg/pull/11752

[designsimply]

If there are concerns with individual cases around css specificity, we should create specific issues. At the same time, I value the desire to discuss and be on the same page regarding what is needed overall.

Could you perhaps start with a specific example of one thing in a comment here that you find unnecessarily nested and overqualified and explain why? Another idea could be to start by auditing a single block and report your findings separately to see if that approach is more actionable.

[m-e-h]

Let's start with button CSS
Specificity was calculated here https://specificity.keegan.st/

PR https://github.com/WordPress/gutenberg/pull/12005

button

.wp-block-button__link
current specificity: _0,2,0_

.wp-block-button .wp-block-button__link {

_0,1,0_

.wp-block-button__link {

_Is there a reason .wp-block-button_link styles are reliant on .wp-block-button?_

.is-style-squared
current specificity: _0,3,0_

.wp-block-button.is-style-squared .wp-block-button__link {

_0,2,0_

.is-style-squared > .wp-block-button__link {

.has-background
current specificity: _0,2,0_

.wp-block-button__link:not(.has-background) {
    background-color: #32373c;

_0,1,0_

.wp-block-button__link {
    background-color: #32373c;

So currently Twenty-Seventeen needs a 0,2,0 selector to override the button style. So it's using .wp-block-button .wp-block-button__link. Guess what... The default background-color select doesn't work because .has-pale-pink-background-color { is only a 0,1,0.

This should probably be reported for the Twenty-Seventeen theme but that's just a tree in the forest and a symptom of the bigger problem.

text-color
:not(.has-text-color) and .is-style-outline is the same as above. I'd actually recommend color styles be added to .wp-block-button and let the .wp-block-button__link inherit them.

current specificity: _0,4,0_

.wp-block-button.is-style-outline .wp-block-button__link:not(.has-text-color)

_0,1,0_

.wp-block-button {
    color: #fff;
}

_0,1,0_

.is-style-outline {
    color: #32373c;
}

_0,1,0_

.wp-block-button__link {
    color: inherit;
}

[m-e-h]

cover

wp-block-cover-text*
current specificity: **_0,3,0_

.wp-block-cover-image.has-left-content .wp-block-cover-text {
    text-align: left;

_0,2,0_

.has-left-content .wp-block-cover-text {
    text-align: left;

Or even better, is there a situation where this would have undesirable results?
_0,1,0_

.has-left-content {
    text-align: left;
}

.wp-block-cover-text {
    text-align: inherit
}

.wp-block-cover-image a
current specificity: _0,2,1_ (_0,3,1_ with the :psuedo)

.wp-block-cover-image .wp-block-cover-image-text a,
.wp-block-cover-image .wp-block-cover-image-text a:active,
.wp-block-cover-image .wp-block-cover-image-text a:focus,
.wp-block-cover-image .wp-block-cover-image-text a:hover,
.wp-block-cover-image .wp-block-cover-text a,
.wp-block-cover-image .wp-block-cover-text a:active,
.wp-block-cover-image .wp-block-cover-text a:focus,
.wp-block-cover-image .wp-block-cover-text a:hover,
.wp-block-cover-image h2 a,
.wp-block-cover-image h2 a:active,
.wp-block-cover-image h2 a:focus,
.wp-block-cover-image h2 a:hover,
.wp-block-cover .wp-block-cover-image-text a,
.wp-block-cover .wp-block-cover-image-text a:active,
.wp-block-cover .wp-block-cover-image-text a:focus,
.wp-block-cover .wp-block-cover-image-text a:hover,
.wp-block-cover .wp-block-cover-text a,
.wp-block-cover .wp-block-cover-text a:active,
.wp-block-cover .wp-block-cover-text a:focus,
.wp-block-cover .wp-block-cover-text a:hover,
.wp-block-cover h2 a,
.wp-block-cover h2 a:active,
.wp-block-cover h2 a:focus,
.wp-block-cover h2 a:hover {
    color: #fff;
}

Why couldn't we replace all that with this?:
_0,1,1_ (_0,2,1_ with the :psuedo)

.wp-block-cover a,
.wp-block-cover a:active,
.wp-block-cover a:focus,
.wp-block-cover a:hover {
    color: #fff;
}

Or even better, use color: inherit; instead.

.has-background-dim
current specificity: _0,3,1_

.wp-block-cover.has-background-dim.has-background-dim-10::before {

_0,2,1_

.wp-block-cover.has-background-dim-10::before {

[m-e-h]

embeds

.wp-block-embed__wrapper
current specificity: _0,4,0_

.wp-embed-responsive .wp-block-embed.wp-embed-aspect-1-1 .wp-block-embed__wrapper,
.wp-embed-responsive .wp-block-embed.wp-embed-aspect-1-2 .wp-block-embed__wrapper,
.wp-embed-responsive .wp-block-embed.wp-embed-aspect-4-3 .wp-block-embed__wrapper,
.wp-embed-responsive .wp-block-embed.wp-embed-aspect-9-16 .wp-block-embed__wrapper,
.wp-embed-responsive .wp-block-embed.wp-embed-aspect-16-9 .wp-block-embed__wrapper,
.wp-embed-responsive .wp-block-embed.wp-embed-aspect-18-9 .wp-block-embed__wrapper,
.wp-embed-responsive .wp-block-embed.wp-embed-aspect-21-9 .wp-block-embed__wrapper {
    position: relative;
}

Replace all that with this:
_0,2,0_

.wp-embed-responsive .wp-block-embed__wrapper {
    position: relative;
}

.wp-block-embed__wrapper::before
current specificity: _0,4,1_

.wp-embed-responsive .wp-block-embed.wp-embed-aspect-1-1 .wp-block-embed__wrapper::before,
.wp-embed-responsive .wp-block-embed.wp-embed-aspect-1-2 .wp-block-embed__wrapper::before,
.wp-embed-responsive .wp-block-embed.wp-embed-aspect-4-3 .wp-block-embed__wrapper::before,
.wp-embed-responsive .wp-block-embed.wp-embed-aspect-9-16 .wp-block-embed__wrapper::before,
.wp-embed-responsive .wp-block-embed.wp-embed-aspect-16-9 .wp-block-embed__wrapper::before,
.wp-embed-responsive .wp-block-embed.wp-embed-aspect-18-9 .wp-block-embed__wrapper::before,
.wp-embed-responsive .wp-block-embed.wp-embed-aspect-21-9 .wp-block-embed__wrapper::before {
    content: "";
    display: block;
    padding-top: 50%;
}

Replace all that with this?:
_0,2,1_

.wp-embed-responsive .wp-block-embed__wrapper::before {
    content: "";
    display: block;
    padding-top: 50%;
}

.wp-block-embed__wrapper iframe
current specificity: _0,4,1_

.wp-embed-responsive .wp-block-embed.wp-embed-aspect-1-1 .wp-block-embed__wrapper iframe,
.wp-embed-responsive .wp-block-embed.wp-embed-aspect-1-2 .wp-block-embed__wrapper iframe,
.wp-embed-responsive .wp-block-embed.wp-embed-aspect-4-3 .wp-block-embed__wrapper iframe,
.wp-embed-responsive .wp-block-embed.wp-embed-aspect-9-16 .wp-block-embed__wrapper iframe,
.wp-embed-responsive .wp-block-embed.wp-embed-aspect-16-9 .wp-block-embed__wrapper iframe,
.wp-embed-responsive .wp-block-embed.wp-embed-aspect-18-9 .wp-block-embed__wrapper iframe,
.wp-embed-responsive .wp-block-embed.wp-embed-aspect-21-9 .wp-block-embed__wrapper iframe {

_0,2,1_

.wp-embed-responsive .wp-block-embed__wrapper iframe {

or even:
_0,1,1_

.wp-embed-responsive iframe {

aspect-* .wp-block-embed__wrapper::before x7
current specificity: _0,4,1_

.wp-embed-responsive .wp-block-embed.wp-embed-aspect-21-9 .wp-block-embed__wrapper::before {
    padding-top: 42.85%;
}

_0,3,1_

.wp-embed-responsive .wp-embed-aspect-21-9 .wp-block-embed__wrapper::before {
    padding-top: 42.85%;
}

figcaption
current specificity: _0,1,1_

.wp-block-embed figcaption {
    color: #555d66;
    font-size: 13px;
    margin-bottom: 1em;
    margin-top: 0.5em;
    text-align: center;
}

Maybe a little off topic but I'm noticing several places where figcaption is qualified with a .class but given the exact same styles in each instance. Would it be wrong to just style figcaption in general? If a theme already had styles for figcaption, they would override.
_0,0,1_

figcaption {
    color: #555d66;
    font-size: 13px;
    margin-bottom: 1em;
    margin-top: 0.5em;
    text-align: center;
}

[joyously]

I'm thinking specificity is a problem, but also that the CSS has so many colors and font sizes and paddings and margins. It shouldn't have any of that. The theme will handle all that naturally. But especially colors should not be in styles that affect content. (they are okay for editor interface)
The figcaption is one that is totally overkill; every property should be removed. I am seeing button color of gray, even though that is not a color in my theme (and this is after the fix in 12005) and it shows on the front end as well!

The specificity problems I encounter are on blockquote, pre, and code elements, (even h1, h2, h3 have color styles in the editor). Because my theme styles the elements, then the GB styles are styling the classes that wrap the elements, the GB styles override (more specific).

[karmatosed]

This is something totally should be looked at during 5.0.1 perhaps. I am going to remove the design feedback label as this firmly sits in code. It won't or shouldn't effect any design.

[Wingo5315]

My editor-style.css file for my custom theme contains the same rules as my main style.css file but it contains !important at the end of each line. Why?