react-tooltip: [BUG] classNames are ignored in v5.13.0

Bug in v5.13.0: classNames like the Tailwind-Class bg-blue-900 are ignored somehow:

<Tooltip className="z-50 bg-blue-900" id="Home" delayShow={200}>
   Home
</Tooltip>

With v5.12.0 everything works just fine.

About this issue

  • Original URL
  • State: closed
  • Created a year ago
  • Comments: 15 (9 by maintainers)

Most upvoted comments

Hey guys, I don’t think that’s problem with the current version. Tailwind classes were ignored with react-tooltip@5.8.3. This is why I had to create separate CSS class like:

.tooltipWrapper { 
  @apply rounded-lgplus bg-tixy-1000 p-2 text-sm font-normal leading-4 text-tixy-10 shadow-sm;
}

or with the current version:

.tooltipWrapper[role="tooltip"] { 
  @apply rounded-lgplus bg-tixy-1000 p-2 text-sm font-normal leading-4 text-tixy-10 shadow-sm;
}

Hi, I tested here and the issue is:

  • CSS is being injected into the page

CSS works like objects, when we pass a custom class, this is the behavior:

Before v5.13.0

  1. import CSS styles:
  2. component receive a new class
  3. browser process and render it
.tooltip-default-css {
  background: red;
}

.bg-green-500 {
  background: green;
}

--------- same as:

Object.assign({ background: 'red' }, { background: 'green' })

On version v5.13.0:

  1. component receives a new class
  2. CSS is injected into the page
  3. browser process and render it
.bg-green-500 {
  background: green;
}

.tooltip-default-css {
  background: red;
}
--------- same as:

Object.assign({ background: 'green' }, { background: 'red' })

this is a bug, we will take a look as soon as possible. We are open to suggestions on fixing this because the CSS class from props and injected CSS have the same CSS specificity.

Solution 1 -> you need to increase the CSS specificity from your side - I don’t like to force the community using our library to write extra code

Solution 2 -> we need to increase the specificity of the CSS received by props (how?) - I prefer this approach, but I don’t have any ideas on how to do that at the moment - edit: as far as I checked, it’s not possible, the best solution to fix this bug is solution 1. I’ll wait for the community if someone has some suggestions to fix this issue. I really don’t want to do a rollback of the feature to inject style by default instead of importing CSS.

reference: https://developer.mozilla.org/en-US/docs/Web/CSS/Specificity

@NemeZZiZZ

That’s totally understandable, but by our experience this hasn’t been an issue to the package users in general.

You’re welcome to open a PR with a rough idea of how you suggest we do this (doesn’t have to be perfect, just enough to get the idea) so we can better discuss it.

Available at v5.16.0 - please note to use v5.16.1 😉

I’ll close this issue as resolved, @NemeZZiZZ and @ansgarsteinkamp please feel free to open a new issue if needed,

@NemeZZiZZ, as I said before, we are trying to not roll back the decision to inject the styles by default, but when reading your comments, I started to think about refactoring the inject the styles function.

Today:

  • we just disabled the extraction of the CSS into our production build and the rollup is handling the injection of the styles by adding the following code at the beginning of the generated files:
function styleInject(css, ref) {
  if ( ref === void 0 ) ref = {};
  var insertAt = ref.insertAt;

  if (!css || typeof document === 'undefined') { return; }

  var head = document.head || document.getElementsByTagName('head')[0];
  var style = document.createElement('style');
  style.type = 'text/css';

  if (insertAt === 'top') {
    if (head.firstChild) {
      head.insertBefore(style, head.firstChild);
    } else {
      head.appendChild(style);
    }
  } else {
    head.appendChild(style);
  }

  if (style.styleSheet) {
    style.styleSheet.cssText = css;
  } else {
    style.appendChild(document.createTextNode(css));
  }
}

The refactored code:

  1. enable code extraction to prevent rollup injecting the styles by default
  2. move this style injection function to our lib and add a prop to disable it if needed

This change will also give us more control, like the style injection inside of web components as example.

I don’t promise, but I’ll try to take a look at this as soon as possible.