Programmatic access to pseudo-class variants

[dkzlv]

Introduction

This proposal aims to introduce a feature in Tailwind CSS that allows developers to use regular CSS classes as alternatives to pseudo-classes. This will enable the application of pseudo-class styles, like :hover, through corresponding classes, like .hover. The objective is to make Tailwind more flexible and user-friendly, especially in scenarios like component state visualization in tools like Storybook, custom form validation styling, and managing focus states in complex UI components.

Motivation

Currently, Tailwind supports pseudo-classes, but there's no direct mechanism to mimic these styles using regular classes. Developers often need to visually represent various states of UI components (like hover, focus, active) without actual user interaction. This feature is particularly useful in design systems and component libraries, where showcasing all possible states is crucial.

Moreover, this functionality aligns with Tailwind's existing approach for dark mode, where a .dark class can be used as an alternative to the @media (prefers-color-scheme: dark) media query. Extending this pattern to other pseudo-classes would enhance consistency and utility within the framework.

Proposed Solution

Default Class-Based Pseudo-Class Implementation

• Automatic Variant Generation: For each pseudo-class (e.g., :hover, :focus), Tailwind will automatically generate a corresponding class (e.g., .hover, .focus). This behavior will be the default, ensuring backward compatibility and minimal configuration requirements.

• Naming Convention: The naming will follow the pattern .<pseudo-class-name>, mirroring the pseudo-class syntax without the colon.

• Selective Application: Users can opt-out or selectively enable this feature for specific pseudo-classes via Tailwind's configuration file.

Example Usage

After implementation, users can apply pseudo-class styles like this:

<button class="bg-blue-500 hover:bg-blue-700">Button</button>

And force hovered state with a class:

<button class="bg-blue-500 hover:bg-blue-700 hover">Button</button>

Benefits

• Enhanced Flexibility: Provides an alternate way to apply pseudo-class styles, beneficial in automated environments like Storybook.
• Ease of Use: Simplifies the process of testing and demonstrating different UI states. Say, you want to use :invalid, but don't want to limit yourself to Constraint API; or you implement a popover, and you want the trigger button to maintain focused style, even though actual focus moved to the popover; or you want to reuse some generic component's state style in an unrelated case (say, pagination, that uses generic Button component and its :active state to show current page).

Potential Concerns

• Increased CSS Size: Automatically generating classes for all pseudo-classes might lead to a larger CSS bundle size. This concern can be mitigated by making the feature opt-in or by allowing selective enabling.
• Naming Conflicts: The proposed naming convention might conflict with existing class names in user projects. Careful consideration and a possible configuration option to customize the prefix could resolve this.

Alternatives

Userland Implementation via Plugin

Here's an example. An alternative to integrating this feature into the Tailwind core is to implement it through a custom Tailwind plugin. The plugin can be configured to generate classes corresponding to desired pseudo-classes. For example, using addVariant in a Tailwind plugin:

import plugin from 'tailwindcss/plugin'

/** @type {import('tailwindcss').Config} */
export default {
  theme: {
    extend: {
      // ...
    },
  },
  plugins: [
    plugin(function ({ addVariant }) {
      addVariant('active', [`&:active`, `&.active`])
    }),
  ],
}

This method would enable users to use .active:bg-red-200 to apply styles for both the :active pseudo-class and the .active class.

Drawbacks of the Plugin Approach

The primary drawback of using a plugin for this functionality is the cumbersome nature of the resulting CSS. The addVariant function, as it currently stands, doesn't allow for the most efficient CSS generation: combining two selectors with a comma. Instead if generates two separate rules with the same content:

.active\:bg-red-200:active {
  --tw-bg-opacity: 1;
  background-color: rgb(254 202 202 / var(--tw-bg-opacity));
}

.active\:bg-red-200.active {
  --tw-bg-opacity: 1;
  background-color: rgb(254 202 202 / var(--tw-bg-opacity));
}

Also, seems to be a core feature, just like dark mode.