The variants section of your tailwind.config.js file is where you control which variants should be enabled for each core plugin:
Each property is a core plugin name pointing to an array of variants to generate for that plugin.
The following variants are supported out of the box:
Variant Descriptionresponsive Responsive variants like sm, md, lg, and xl. dark Targets dark mode. motion-safe Targets the prefers-reduced-motion: no-preference media query. motion-reduce Targets the prefers-reduced-motion: reduce media query. first Targets the first-child pseudo-class. last Targets the last-child pseudo-class. odd Targets the odd-child pseudo-class. even Targets the even-child pseudo-class. visited Targets the visited pseudo-class. checked Targets the checked pseudo-class. group-hover Targets an element when a marked parent matches the hover pseudo-class. group-focus Targets an element when a marked parent matches the focus pseudo-class. focus-within Targets the focus-within pseudo-class. hover Targets the hover pseudo-class. focus Targets the focus pseudo-class. focus-visible Targets the focus-visible pseudo-class. active Targets the active pseudo-class. disabled Targets the disabled pseudo-class.
For more information about how variants work, read our documentation on responsive variants, dark mode variants, and hover, focus and other state variants.
If you’d like to enable extra variants for a plugin in addition to the defaults, you can configure your variants using the extend keyword, similar to how you can use extend inside of the theme section:
Because the order of variants is important, any variants added under the extend key are automatically ordered for you using a sensible default variant order. You can customize this order using the variantOrder option if necessary.
Any variants configured directly under the variants key will override the default variants for that plugin.
When overriding the default variants, make sure you always specify all the variants you’d like to enable, not just the new ones you’d like to add.
Ordering variantsIt’s important to note that when overriding variants, variants are generated in the order you specify them, so variants at the end of the list will take precedence over variants at the beginning of the list.
For example, here focus variants have the highest precedence for backgroundColor utilities, but hover variants have the highest precedence for borderColor utilities:
This means that given the following HTML:
…if the input was hovered and focused at the same time, the background would be white but the border would be black.
Generating variants in order this way gives you the most flexibility as an end-user, but it’s also a sharp tool and can have unintended consequences if you aren’t careful. We recommend enabling extra variants instead of overriding the defaults whenever possible, and using this feature only as an escape hatch.
Special variants ResponsiveThe responsive variant is a special case in Tailwind and is not impacted by the order you list in your variants configuration.
This is because the responsive variant automatically stacks with other variants, meaning that if you specify both responsive and hover variants for a utility, Tailwind will generate responsive hover variants as well:
Responsive variants are grouped together and inserted at the end of your stylesheet by default to avoid specificity issues, regardless of where responsive appears in your variants list.
If you’d like to customize this behavior for whatever reason, you can use the @tailwind screens directive to specify where responsive variants should be inserted.
Dark, motion-safe, and motion-reduceThe dark, motion-safe, and motion-reduce variants also stack with other variants, but unlike responsive, they stack in the same “slot”, so you can combine them with both responsive and simple state variants, but not with each other.
The order of these variants matter relative to each other, but not relative to other variants. There is just about no situation imaginable where these would conflict with each other in practice, so this ends up being a non-issue anyways.
You can include these variants in any order in your variants configuration and never notice the difference.
You can use the special DEFAULT variant to control where the normal, non-prefixed version of a utility is generated relative to the other variants.
This is an advanced feature and only really useful if you have a custom variant (like children in the example below) that should have a lower precedence than the normal version of a utility.
Learn more about creating custom variants in the variant plugin documentation.
Using custom variantsIf you’ve written or installed a plugin that adds a new variant, you can enable that variant by including it in your variants configuration just like if it were a built-in variant.
For example, the tailwindcss-interaction-variants plugin adds a group-disabled variant (among others):
Learn more about creating custom variants in the variant plugin documentation.
Ordering custom variantsIf you’d like to specify a default sort position for a custom variant, override your variantOrder to include the custom variant:
You’ll need to specify the entire list when overriding the variantOrder to include any custom variants.
Here is a complete reference of Tailwind’s default variants configuration, which can be useful when you’d like to add a new variant while preserving the defaults.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4