Investigate CSS conflicts with host platform CSS and styled components

[afercia]

Styled components don't allow to control CSS selectors specificity when components get integrated in an external platform. There's simply no way to control all the places where a component will be used in a specific platform UI that already uses its own CSS rules.

When the platform uses CSS rules with selectors with higher specificity, these rules will override the components one, exposing us to any sort of layout breakage. Unless we want to use !important everywhere 🙈

As an example, when testing the Help Center in the Gutenberg branch that supports metaboxes (see https://github.com/WordPress/gutenberg/pull/2804/) this is how the KB search looks:

At the moment, Gutenberg uses these selectors and rules:

.gutenberg-meta-box-html input[type="text"]

display: inline-block;
padding: 0;
line-height: 24px;
background: inherit;
border: 0;
outline: none;
font-family: inherit;
font-size: 13px;
color: #23282d;
box-shadow: none;
padding: 4px;
border: 1px solid #e2e4e7;

.gutenberg-meta-box-html #poststuff h2

box-sizing: border-box;
color: #555d66;
position: relative;
padding: 15px;
outline: none;
width: 100%;
font-weight: 600;
border-bottom: 1px solid #e2e4e7;

they have higher specificity than the typical selectors used by styled components, say for example sc-VigVT dKplst, which are then used singularly as .sc-VigVT {} and .dKplst {}

[atimmer]

This should also be a bug in Gutenberg? I think they should never have such specific selectors for metaboxes which are in control of plugins.

[afercia]

In a perfect world I'd agree with you, but in WordPress crazy selectors with very high specificity are pretty common.

Regardless, this could happen in any platform because styled components rules use a single class selector. Even if an element has multiple selectors like: class="sc-kEYyzF jtPFuc sc-dnqmqq hcNCrn sc-htoDjs hLTUqo"

the related rules use a single class selector:

.jtPFuc {
    ...
}

.hcNCrn {
    ...
}

so each rule has a very low specificity and it's very likely to be overridden. Even a simple, for example: .wrapper div has a higher specificity than .hcNCrn if "hcNCrn" is a div.

[afercia]

Current CSS conflicts in the Help Center when integrated in WP:

In the metabox:

The KB search heading is not aligned as it should, also the font looks different:

it should look like this:

same for the heading in the Support tab:

Both in the metabox and the settings pages:

The search field should look like this (WP styles input[type="text"] which has a higher specificity):

This is an unordered list and should have bullets, but WP resets the default list styles:

[afercia]

The only reference I've found so far suggesting a way to increase the specificity of a styled component rule is: https://github.com/styled-components/styled-components/issues/85#issuecomment-253965711

Basically, repeating the generated class selector:

const StyledUpYo = styled.div`
  && {
    background-color: green;
  }
`;

will output a CSS with a doubled CSS class selector, e.g.: .jfhdui.jfhdui { ... }

this will help, increasing the computed specificity from 10 to 20. Still can be overrider though, for example: .wrapper .inner div has a specificity of 21 #wrapper div has a specificity of 101

You can easily calculate specificity here: https://specificity.keegan.st/

Also, even if the specificity is higher, properties that are not overridden will still be inherited from a conflicting class with lower specificity.

[BE-Webdesign]

Hi @afercia ,

I will change the selectors on the 2804. Always feel free to leave a comment on the ticket there. It is in a state of refinement, so any observations or improvements you have please let me know.

[afercia]

@BE-Webdesign thanks! Keeping selectors specificity as low as possible is always good 🙂

[BE-Webdesign]

Agreed! 😄

[BE-Webdesign]

I will drop a note here, when I change the styles, and hopefully that will improve things from your end.

[BE-Webdesign]

I updated the metabox PR on Gutenberg to have much lower selector specificity. Let me know if that works better for y'all.

Thank you for pointing that flaw out. I hope it will make the transition more seamless. Your insights are very valued.