3.0.12 gives non-applicable warning about @apply

[brycewray]

What version of Tailwind CSS are you using?

Tailwind version: 3.0.12

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

@11ty/eleventy 1.0.0, postcss 8.4.5, postcss-cli 9.1.0

What version of Node.js are you using?

14.16.0

What browser are you using?

N/A

What operating system are you using?

macOS 12.1

Reproduction URL

https://github.com/brycewray/eleventy_site (Note: trying to run that repo right now is problematic due to an apparent bug in Eleventy 1.0.0.)

Describe your issue

When running a build for dev or production, Tailwind generates the following error message:

CssSyntaxError: tailwindcss: /Users/thewrays/eleventy_site/src/assets/css/intervf.css:2:1: You cannot `@apply` the `italic` utility here because it creates a circular dependency.

  1 | /* === handling Inter VF obliquing */
> 2 | .italic, i, cite, em, var, address, dfn, h3, .h3, h5, .h5 {  /* dealing with Inter VF */
    | ^
  3 |   font-variation-settings: 'slnt' -8;
  4 |   /* previous is needed by Chromium and Safari; its presence makes Firefox "over-slant" Inter VF, so we override that below with the media query for Firefox */

. . . which didn't occur before 3.0.12. The CSS to which it apparently objects is there to handle the peculiarities of using the variable version of the Inter font for both regular and oblique/italic text. But here's the thing: that particular CSS doesn't use @apply:

/* === handling Inter VF obliquing */
.italic, i, cite, em, var, address, dfn, h3, .h3, h5, .h5 {  /* dealing with Inter VF */
  font-variation-settings: 'slnt' -8;
  /* previous is needed by Chromium and Safari; its presence makes Firefox "over-slant" Inter VF, so we override that below with the media query for Firefox */
  font-style: oblique 8deg;
  /* previous is needed by Firefox and Safari; it apparently has no effect on Chromium */
}

@supports (-moz-appearance: none) {
  .italic, i, cite, em, var, address, dfn, h3, .h3, h5, .h5 {
    /* font-variation-settings: normal; */
    font-style: normal;
  }
}
/* === end, handling Inter VF obliquing */

While I can get around this by using a different font which doesn't require this kind of babying 😄 I would guess that this issue's having cropped up in 3.0.12, and never before, is something worth noting.

[brycewray]

Can also confirm I don't see this error after reverting to 3.0.11.

[thecrypticace]

Hey, thanks for the report and reproduction!

Unfortunately, this is working as intended. The workaround should be fairly simple: split the .italic part of the rule in src/assets/css/intervf.css into a rule by itself and that should fix the error you are seeing.

So, what's going on then?

1. In src/assets/css/intervf.css you have this rule:

.italic, i, cite, em, var, address, dfn, h3, .h3, h5, .h5 {
  /* clipped */
}

2. In src/assets/css/global.css you have this rule:

h3, .h3, h5, .h5 {
  @apply italic;
}

This coupled with the fact that @apply takes entire rules into account — not just the single selector — because they're not always equivalent means we detect a circular dependency.

For example, these two selectors while seemingly separate, are not (h/t @RobinMalfait for the example):

/* <div class="a">This will **not** be red</div> */
.a, .b::unknown-and-broken-thing { color: red; }

/* <div class="a">This **will** be red</div> */
.a { color: red; }
.b::unknown-and-broken-thing { color: red; }

Since the browser doesn't know about ::unknown-and-broken-thing the entire rule gets thrown out and we need to properly handle that with apply.

You can read even more details on how apply works in this comment: #6451 (comment)

Hopefully that answers your question — if you have more questions please feel free to comment.

[brycewray]

@thecrypticace Much obliged, sir. Giving .italic its own rule did indeed fix the issue. (I'm still curious re why it changed with 3.0.12, but no matter.)

[thecrypticace]

Long-story short: apply got better at detecting these cases and also applying css when defined with rules like .something, h3 { … }

[jshah4517]

@thecrypticace We have some cases which also have broken in the 3.0.12 upgrade. The following is an example where sp-border-0 on the element gets ignored because of our stylesheet, so we have a separate part to handle that.

div.sp-filter-results > div.sp-table-row {
    @apply sp-border-t-8 sp-border-transparent;
}

div.sp-filter-results > div.sp-table-row.sp-border-0 {
    border: 0;
}

How could this be handled correctly following this update?