You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
then class="!foo" will apply the text-lg and underline rules but without the !important syntax. The same limitation is true if I instead use addUtilities() or addComponents() in my Tailwind config, like:
On the other hand, any rules for .foo declared with normal CSS syntax (or normal CSS-in-JS syntax) will get !important in the class="!foo" case.
It would be nice if the important-modifier worked with @apply rules in custom utilities and components. The !important would of course have to go on the actual property-value pairs, which are sometimes nested in at-rules or media queries (with syntax like @apply sm:underline); I don't know whether that would present a major challenge.
In anticipation of the argument that one simply shouldn't use @apply in this way:
In my opinion, this sort of situation—building new utilities/components from existing ones—is precisely where @apply really shines! This technique lets you keep everything "in sync," so that if, for example, the definition of text-lg ever changes, then that change cascades to .foo in my code above. (And you'll even get an error if you try to @apply something that doesn't exist, which I'd argue is helpful here.) I know that one can use the theme() directive to refer to theme-values, but that doesn't let you do things like weave in custom variants with complex selectors (my typical use-cases for this technique are considerably more complicated than the simple example I've given).
The text was updated successfully, but these errors were encountered:
@MichaelAllenWarner unrelated to this feature request / bug, I see you were @applying to the utilities layer.
I believe this layer is intended for custom utilities.
I think the @layer you should use is components.
The tailwind docs seem to demonstrate it very nicely on this page: https://tailwindcss.com/docs/functions-and-directives#layer
@MichaelAllenWarner unrelated to this feature request / bug, I see you were @applying to the utilities layer. I believe this layer is intended for custom utilities. I think the @layer you should use is components. The tailwind docs seem to demonstrate it very nicely on this page: https://tailwindcss.com/docs/functions-and-directives#layer
Yes, probably (and thank you), and to be clear: the "bug" / feature-request affects both utilities and components. (I just picked one for demonstration purposes.)
That said, here is another aside: I rarely use @layer components or addComponents(), and the reason is that Tailwind "components" don't respect the important preference in the Tailwind config, as described here. Usually this doesn't matter, but I've run into difficulty when using the selector strategy for the purpose of scoping my Tailwind rules. (The prefix option is an alternative, but if you haven't configured it from the beginning then you'll be in for a lot of refactoring.)
What version of Tailwind CSS are you using?
v3.4.1
What build tool (or framework if it abstracts the build tool) are you using?
N/A
What version of Node.js are you using?
v19.8.1
What browser are you using?
Chrome
What operating system are you using?
macOS
Reproduction URL
https://play.tailwindcss.com/N1pmDRsMmo
Describe your issue
This may be intended behavior—if so, apologies for filing this as an issue. I couldn't find any previous discussions or issues about this, though.
The important-modifier doesn't work for
@apply
rules that are part of custom utilities or components. For example, if I've done:then
class="!foo"
will apply thetext-lg
andunderline
rules but without the!important
syntax. The same limitation is true if I instead useaddUtilities()
oraddComponents()
in my Tailwind config, like:On the other hand, any rules for
.foo
declared with normal CSS syntax (or normal CSS-in-JS syntax) will get!important
in theclass="!foo"
case.It would be nice if the important-modifier worked with
@apply
rules in custom utilities and components. The!important
would of course have to go on the actual property-value pairs, which are sometimes nested in at-rules or media queries (with syntax like@apply sm:underline
); I don't know whether that would present a major challenge.In anticipation of the argument that one simply shouldn't use
@apply
in this way:In my opinion, this sort of situation—building new utilities/components from existing ones—is precisely where
@apply
really shines! This technique lets you keep everything "in sync," so that if, for example, the definition oftext-lg
ever changes, then that change cascades to.foo
in my code above. (And you'll even get an error if you try to@apply
something that doesn't exist, which I'd argue is helpful here.) I know that one can use thetheme()
directive to refer to theme-values, but that doesn't let you do things like weave in custom variants with complex selectors (my typical use-cases for this technique are considerably more complicated than the simple example I've given).The text was updated successfully, but these errors were encountered: