Overridable class strategy

[midnight-wonderer]

What version of @tailwindcss/forms are you using?

v0.5.7

Describe your issue

I read the discussion #22. The thread has been closed by adding class strategy.

Sorry to bring this up again

However, the class strategy is not easily overridable because it was placed later in the CSS file (at the components layer).
No matter the strategy used, tailwindcss-forms should always be a base, ready to be overridden by other stylings.

Why the need for overrides?

I can't talk for others, as you'll see some of them on the discussion links above, but for me, tailwindcss-forms adds colors that almost always need overriding because they stand out like sore thumbs.

What should we do?

Can we move CSS declarations of class strategy from components layer to base layer?
Basically, modify the code here:

tailwindcss-forms/src/index.js

Line 353 in c9d9da3

addComponents(getStrategyRules('class'))

from addComponents to addBase.

Why do I, or other similar people, use tailwindcss-forms at all?

tailwindcss has its ecosystem, and some 3rd-party components expect tailwindcss-forms to be there as the base. We still want to work with tailwindcss-forms and the people creating those components, even if we are not a fan of the approaches.

[adamwathan]

Can you give a concrete example of something that doesn't work? Are you trying to override the form styles with custom styles that you are putting in the base layer?

[midnight-wonderer]

Can you give a concrete example of something that doesn't work? Are you trying to override the form styles with custom styles that you are putting in the base layer?

Yep, that's pretty much it.
I am customizing the base style of tailwindcss-forms like this:

@layer base {
  .form-checkbox:focus, .form-radio:focus {
    --tw-ring-color: transparent;
  }
}

It needs to be at the base layer because, well, it is the base style.

[adamwathan]

Those classes are in the components layer so why not use @layer components? When using the class strategy I don't consider them base styles because they aren't applied by default, you have to opt-in to them by adding a class.

[midnight-wonderer]

I guess that's work, too; apology for the fuss.
I kind of want to leave some room because of the unseen (future), but this is probably YAGNI stuff.

Nevertheless, all strategies at the base layer have advantages in some aspects. Their consistency makes the overriding layer agnostic to the strategies used. This makes it easier to share snippets in certain situations.

That said, the advantage is likely marginal; thanks for the swift replies.

[ranseur92]

Those classes are in the components layer so why not use @layer components? When using the class strategy I don't consider them base styles because they aren't applied by default, you have to opt-in to them by adding a class.

Can you verify/check if this is the case in v4? as for me, they end up in the utilities layer. which makes changing the styles and allowing overrides not work.

@adamwathan

[chasegiunta]

In v3, I was using the class strategy, and setting some other defaults to be applied to my form- classes by nesting in @layer components. This worked without problem, because the reset classes were also being applied in the components layer. I'd get the reset, and my overrides, when applying form-input, etc.

In v4, this behavior changed for the class strategy: resets are now set in the utilities layer. I'm not sure if this is a bug for where plugin classes are applied, or an intended change. When running my previous overrides through the migration CLI, they were all converted to using the @utility directive. This did not take precedence over the reset classes applied in the utilities layer (at least not in all cases, it was not guaranteed).

My fix was to nest overrides in @layer utilities and convert the @utility conversions back to their original normal class overrides. Unfortunately, this does not seem like a reliable method either. The tailwindcss/forms package will need to apply it's classes at the components layer, not utilities.

[dargmuesli]

Source of the new behavior is this PR: tailwindlabs/tailwindcss#14221, especially the alias of components to utilities. The PR's description state:

The component APIs are an alias for the utilities APIs because the sorting in V4 is different and emitting components in a custom @layer is not necessary.

@thecrypticace could you give us some insight into what exactly that means and how we're supposed to use utilities to override .form-input's properties?

[atomgiant]

I was able to inline the @tailwindcss/forms plugin CSS so I don't need the plugin going forward and it works the same in v4 as it did in v3.

Here's the steps I used in case it's helpful for others:

I created this Tailwind Play with the form inputs I am using: https://play.tailwindcss.com/k4MfjgG3Pg (Note: Updated to @morphsteve's fixed version).

Then I copied the Tailwind Play Utilities CSS into my project, and placed it inside of a @layer components, which is how v3 worked.

[morphsteve]

To be clear, this plugin is basically unusable with Tailwind 4 when using the 'class' strategy.

(I've always avoided the 'base' strategy because there are often 'one-off' form components which don't match the default style, and IMO it kinda goes against the Tailwind ethos.)

I also used the solution above (thanks @atomgiant!) but noticed a small typo which means the textarea styles aren't included. Here's a corrected version: https://play.tailwindcss.com/k4MfjgG3Pg

[atomgiant]

Good catch @morphsteve - I updated my comment to use your version.

I use the class style for the custom form components as well. And you are right, this plugin is not usable with the class strategy unless you don't need to override the utility class styles. The @layer utilities will always win so if you set something like padding in your utility classes you can't ever change it using an inline padding, which IMO feels like a bug. I'm happy with the CSS-only version I mentioned above though, and it sounds like this is the way things may be going with other plugins like typography (i.e. - generate a CSS file rather than use a plugin).

[functasti]

I’m using V4 with this config and able to override styles as expected:

@import "tailwindcss";
@plugin "@tailwindcss/forms" {
  strategy: "class";
}

Example:

<div className="h-screen p-8 flex flex-col gap-4">
  <textarea className="form-textarea pt-5 h-16"></textarea>
</div>

Overrides the padding without issues (see devtools screenshot).

Can someone please clarify the issue? I don’t quite understand it.

[atomgiant]

@functasti - The issue is any @layer utilities classes will always win and prevent inline classes from working.

I adjusted your code to demonstrate.

HTML

<div class="h-screen p-8 flex flex-col gap-4">
  <textarea class="form-textarea pt-5 h-16 bg-blue-50">I should be blue</textarea>
</div>

CSS

@import "tailwindcss";
@plugin "@tailwindcss/forms" {
  strategy: "class";
}
@layer utilities {
  .form-textarea { @apply bg-red-50; }
}

RESULT

Here is the play: https://play.tailwindcss.com/HTZZbcMhNA?file=css

[functasti]

@atomgiant Got it. You want to override a property in a form-* utility 'globally' but still further tweak it at the element level.

What do you think about defining a similar named utility in the @components layer that extends the original? Like this:

@layer components {
  .my-form-textarea { 
    @apply form-textarea bg-red-50; 
  }
}

<div class="h-screen p-8 flex flex-col gap-4">
  <textarea class="my-form-textarea pt-5 h-16 bg-blue-50">I should be blue</textarea>
</div>

This effectively creates a new class based on the original.

Play