Tailwind looks for classes inside `:not()` in utilities and components when in at-rules

[exoRift]

What version of Tailwind CSS are you using?

v3.3.3

What build tool (or framework if it abstracts the build tool) are you using?

Next.js 13.4.13 (Tool agnostic bug)

What version of Node.js are you using?

For example: v18.16.0

What browser are you using?

For example: Chrome

What operating system are you using?

For example: Windows

Reproduction URL

https://play.tailwindcss.com/Tg2m8Otzun

Describe your issue

Tailwind searches for importance for things like disabled in places that are not classnames.

As shown in the example above, DaisyUI applies variants upon hover when the component is not disabled.
Because Tailwind sees a string !disabled, the styles applied in Daisy's hover variant become important and thus overshadow things like the active style.

If you hold click on the menu options in the playground, nothing happens. However, if you remove the !disabled span and hold click, you will see the proper :active styles become applied

This also happens in React (checking a variable, for instance) and is documented here: saadeghi/daisyui#2240

[thecrypticace]

Hey, thanks for reporting this.

Tailwind searches for importance for things like disabled in places that are not classnames.

This is by design. Not everyone uses Tailwind in HTML but in JSX, Svelte, Pug, etc… Parsing files to find class names and to do so properly would have significant limitations as we would have to understand the code, how it works at build time, and how it works at runtime. This is not feasible for Tailwind itself. Tailwind CSS scans entire source files for matches generally regardless of where that match occurs. This means you can get false positives but you can typically use the blocklist feature to work around this.

If you hold click on the menu options in the playground, nothing happens. However, if you remove the !disabled span and hold click, you will see the proper :active styles become applied

This is definitely a bug. We do not traverse classes inside :not() — but it is still (incorrectly) traversed when inside an at rule.

Minimized repro: https://play.tailwindcss.com/GMBdxJHeL9?file=config

I'll look at this in the am.

[0x221A]

@thecrypticace I think the level of how tailwind scans the code is too much

[thecrypticace]

This should be fixed by #12105, and will be available in the next release.

You can already try it by using the insiders build npm install tailwindcss@insiders.

[exoRift]

I re-opened my original playground and set the version to Insiders. However, the aforementioned bug is still occurring

[thecrypticace]

It takes about 15 minutes for it to publish.

[thecrypticace]

@0x221A As I said above, this is by design. This breaks down as soon as you switch languages. And even even within the same language you'd still want the classes generated for something like this:

let styles = {
  normal: 'bg-gray-600 text-gray-100',
  active: 'bg-blue-700 text-white',
}

function generateClasses({ active }) {
  return clsx(
    'px-4 py-2 font-bold',
    !active && styles.normal,
    active && styles.active,
  )
}

export function Button({ active }) {
  return <button className={generateClasses({ active })}></button>
}

Tailwind works this way today on purpose and is not something we're going to change.

[thecrypticace]

@exoRift Also, right now, insiders releases for Play are semi-manual and sometimes require a bit more work to push out. Once the insiders build is published to npm I'll get working on updating Play.

[thecrypticace]

@exoRift NPM was giving us some problems so it took longer to publish than normal but Play is now updated and I verified that the bug is indeed gone with your play above.