Provide a way to configure rule specificity

[drupsys]

I'm migration an old application to react, using mui as default components, since v5 mui started to use emotion which brings me here. This legacy application has a lot of styles that cannot be removed and are messing up material ui components, I need emotion generated css to have higher specificity. This is something that I used to be able to do quite easily with JSS plugins, all that you need to do is prefix all rules with :not(#\\20) where #\\20 is just a char DC4 (device control 4), this can be anything I just chose #\\20 because no one would normally have an id with this name, e.g.

example 1

:not(#\\20)div {
    // your css code...
}

the number of :not(#\\20) defines the specificity, with this approach you can have multiple layers of specificity

example 2

:not(#\\20):not(#\\20)div {
    // your css code...
}

will always take precendence over the example 1. This approach to specificity increase is described here and if you would like to see how I did this in JSS you can find source code for it here and here (no documentation for it, sorry).

Since material ui moved to emotion I now have a need to find a way to replicate this functionality in emotion, perhaps this is something that is already possible but I can't find any documentation for it, so I would like to propose 2 solutions.

Solution 1

Add an ability to add plugins that allow css rule names to be modified. A highly flexible solution but probably too difficult to use.

Solution 2

Add an ability to specify the level of specificity emotion should use. A react example could be something like

export interface ICssSpecificityState {
  level: number;
  prefix: string;
}

const CssSpecificityContext = createContext<ICssSpecificityState>({
  level: 0,
  prefix: ':not(#\\20)',
});

With this users would be able to choose the specificity that suits them, this is less flexible approach but very easy to use.

[srmagura]

Emotion allows you to add arbitrary CSS to the page, so you should be able to use the :not(#\\20) hack to artificially increase a selector's specificity. I'm not sure what your specific use case is, but it could be helpful to use & to reference the parent selector, like in Sass.

Example: https://codesandbox.io/s/emotion-specificity-hack-78jl77?file=/src/App.tsx

[drupsys]

Hi @srmagura, thank you for looking into this. I think I didn't made this clear enough, I'm not just adding some new css, if that's all I had to do this wouldn't be much of an issue. What I need to do is prefix all existing css including css that I didn't write or have control over, e.g. css generated by material ui, to have :not(#\\20) prefixed to every css rule.

Basically rules generated by material ui should have increased specificity, so that mui styles would take priority within some div where react components are rendered.

[srmagura]

Ah, thanks for the clarification. This seems like a difficult issue, and what Andarist said is probably your best bet.

[Andarist]

You could explore writing a Stylis plugin for this or try to hack around using a custom cache.sheet

[drupsys]

Well I sort of found a way, it's not exactly what I want but it appears to work. If someone else needs to solve the same issue the following is what I've done.

import createCache, {
  StylisElement,
  StylisPluginCallback,
} from '@emotion/cache';
import { prefixer, serialize } from 'stylis';
import { CacheProvider } from '@emotion/react';
import { map } from 'lodash';

const plugin = (
  element: StylisElement,
  index: number,
  children: StylisElement[],
  callback: StylisPluginCallback,
) => {
  let modified = false;
  const props = map(element.props, (prop) => {
    if (prop.includes(':not(#\\20)')) {
      return prop;
    } else {
      modified = true;
      return `:not(#\\20)${prop}`;
    }
  });

  if (element.type === 'rule' && modified) {
    serialize([{ ...element, props }], callback);
  }
};

const myCache = createCache({
  key: 'temp-frontend',
  stylisPlugins: [plugin, prefixer],
});

const store = buildStore();

<CacheProvider value={myCache}><ReactApp/></CacheProvider>

I wish stylis had better documentation on how these plugins suppose to work. Maybe someone else knows better and can help because the above snippet does not modify the rule name, I could not find a way to do that, it just inserts the clone of the rule with a modified rule name. Not exactly desired behaviour but it works for now.

[drupsys]

@Andarist @srmagura just to expand on this a bit, ideally I would like my plugin to be this

const plugin = (element: StylisElement) => {
  if (element.type === 'rule' && !element.value.includes(':not(#\\20)')) {
    return `:not(#\\20)${element.value}`;
  }
};

which should produce this

:not(#\20).temp-frontend-o6vxv4-MuiInputBase-root-MuiOutlinedInput-root {
    font-family: 'Montserrat',sans-serif;
    font-weight: 400;
    font-size: 1rem;
    line-height: 1.4375em;
    color: rgba(0, 0, 0, 0.87);
    box-sizing: border-box;
    position: relative;
    cursor: text;
    display: -webkit-inline-box;
    display: -webkit-inline-flex;
    display: -ms-inline-flexbox;
    display: inline-flex;
    -webkit-align-items: center;
    -webkit-box-align: center;
    -ms-flex-align: center;
    align-items: center;
    position: relative;
    border-radius: 4px;
    padding-right: 14px;
}

but it doesn't, however, if I do this with non rule elements it does work (sort of, still not exactly what I would expect)

const plugin = (element: StylisElement) => {
  if (element.type !== 'rule' && !element.value.includes(':not(#\\20)')) {
    return `:not(#\\20)${element.value}`;
  }
};

produces the following styles

.temp-frontend-o6vxv4-MuiInputBase-root-MuiOutlinedInput-root {
    : not(#\20):not(#\20)font-family:'Montserrat',sans-serif;
    font-family: 'Montserrat',sans-serif;
    : not(#\20)font-weight:400;
    font-weight: 400;
    : not(#\20)font-size:1rem;
    font-size: 1rem;
    : not(#\20)line-height:1.4375em;
    line-height: 1.4375em;
    : not(#\20)color:rgba(0, 0, 0, 0.87);
    color: rgba(0, 0, 0, 0.87);
    : not(#\20)box-sizing:border-box;
    box-sizing: border-box;
    : not(#\20)position:relative;
    position: relative;
    : not(#\20)cursor:text;
    cursor: text;
    : not(#\20)display:inline-flex;
    display: -webkit-inline-box;
    display: -webkit-inline-flex;
    display: -ms-inline-flexbox;
    display: inline-flex;
    : not(#\20)align-items:center;
    -webkit-align-items: center;
    -webkit-box-align: center;
    -ms-flex-align: center;
    align-items: center;
    : not(#\20):not(#\20)position:relative;
    position: relative;
    : not(#\20)border-radius:4px;
    border-radius: 4px;
    : not(#\20)padding-right:14px;
    padding-right: 14px;
}

Why does this behave differently? I'm not familiar with emotion code base but after scanning though it a bit, it does seem like there is a problem with how Stylis is implemented.

[Andarist]

Stylis plugins are quite tricky. It should be possible to write one for this - but I have not experimented with it enough to be sure.

It might be easier for you to do stuff like this:

const cache = createCache({ key: 'temp' })
const { insert } = cache.sheet
cache.sheet.insert = function (rule) {
  return insert.call(this, rule.replace(/\.temp/g), ':not(#\\20).temp')
}

Note that this might not work properly with SSR.

[ivan-kleshnin]

@Andarist I have a related problem, would be very nice to get your feedback!

1. I'm making a Typography component for Chakra-UI (Emotion based) where I want to assign styles to say h1 but leave an opportunity to override them with Heading and its custom styles/props.

Typography declares default styles like:

"h1": {
  marginTop: "1em",
  marginBottom: "1rem",
},

and they, unfortunately, do override Heading styles because of higher specificity of the generated CSS selectors 😞

For example <Heading marginTop="2rem"> produces:

.xxx {
  marginTop: "2rem"
}

And Typography generates more specific:

.xxx h1 {
  marginTop: "1em",
  marginBottom: "1rem",
}

---

2. Now I update Typography definitions to what I believe should fix the problem:

":where(&) h1": {
  marginTop: "1em",
  marginBottom: "1rem",
},

:where selector was designed to control specificity.

❗ Unfortunately, Emotion does not recognize & inside :where and the above becomes:

.xxx:where(.xxx) h1 {
  ...
}

instead of:

:where(.xxx) h1 {
  ...
}

Which would have a correct, lower specificity than styles from <Heading sx={...}/>.

To me it looks like a bug and I believe Emotion should recognize :where(&) notation and doesn't prefix the whole selector with the generated class.

E.g. body :where(&) h1 produces no duplicated class:

body :where(.xxx) h1 {
  ...
}

but it's, again, an increased specificity. What do you think?

[srmagura]

Issue 1

It seems like a problem to me that Typography generates CSS like

.xxx h1 {
  marginTop: "1em",
  marginBottom: "1rem",
}

I would expect '.xxx' to be the <h1> element itself.

Issue 2

Emotion is generating the following CSS, which is the expected behavior for the styles you have passed in.

.xxx:where(.xxx) h1 {
  ...
}

When Emotion outputs CSS, the generated class name is always first — except when using our <Global /> component. <Global /> could solve your problem.

In most cases, this type of specificity hack is not necessary when using Emotion. Can you improve your design so that it does not require specificity hacks?

[ivan-kleshnin]

@srmagura thank you for the response.

I would expect '.xxx' to be the h1 element itself.

It would be true for a normal, component-based flow. But I'm styling raw HTML / markdown!

Then styling tags as components would require to bundle a whole Markdown parser...
Instead of that I want to style nested tags which will be a far more lightweight solution.

Chakra-Prose does the same thing (and suffers from the same problem). I don't like many of Prose's decisions so I write an alternative.

Global could solve your problem.

Unfortunately not, because it can't access theme tokens. Global accepts a low-level style with no access to theme, nor its values or shorcuts.

In most cases, this type of specificity hack is not necessary when using Emotion. Can you improve your design so that it does not require specificity hacks?

I wish I knew that. My case is not typical, but it's still a basic task in my book.

[ivan-kleshnin]

UPDATE

The following syntax does what I want:

"*:where(&) p": {
  hyphens: "auto",
  textAlign: "justify",
  my: "1rem",
},

It assigns styles to p which are still overridable from something like Paragraph. I was just missing * in front of :where 🤦‍♂️

[benmcginnis]

So I am working on a similar problem, but what I was hoping to do was write a stylis plugin that just wrapped all the generated sheets in an @layer my-theme{} rule. @ivan-kleshnin or @Andarist or @srmagura do y'all have any suggestions on how I might do that?