How to remove styles from a particular input?

[bcorcoran]

I use vue and i'm using a third-party component called vue multiselect.

Is there a way to ignore input elements within a particular selector (i.e., ignore input elements inside a particular class) so that, for example, there isn't a border around the text input?

[RobbieTheWagner]

Rather than ignore one, I would like to ignore all and only apply styles to the inputs I choose. I feel like that would be much more in line with the philosophy of tailwind and how @tailwindcss/custom-inputs used to work. Is there any way to opt totally out and instead choose the inputs I want styles added to?

[bcorcoran]

OK,

Seems if you just override them, it plays nicely.

For my use cases, I used the following:

.multiselect__input,
.multiselect__input:focus {
    @apply shadow-none ring-0 border-0;
}

.ProseMirror,
.ProseMirror-focused {
    @apply shadow-none ring-0 border-0 outline-none;
}

Some documentation would have saved me some time though!

[RobbieTheWagner]

@bcorcoran we shouldn't have to guess all the properties to override though. There should be a way to either mark an input as unstyled or better yet this plugin shouldn't add styles to all inputs, and should instead provide utils we apply to the inputs ourselves, more like how tailwind usually works.

[bcorcoran]

In principle, I agree; nevertheless I had to find a solution in the meantime.

[RobbieTheWagner]

@adamwathan how can I help land these changes? I'm quite surprised this plugin takes such an opposite stance to tailwind and styles all inputs. I would expect it to behave like tailwind and only style elements you explicitly add classes to.

[jordn]

I agree. This feels like a mis-step with the tailwind approach and it's unnecessarily painful to try to disable it for a particular input.

[RobbieTheWagner]

@adamwathan @RobinMalfait not sure who is in charge of this plugin, but could we get someone to weigh in here? I'm happy to help implement this if there is buy in.

[viperfx]

I was looking through the issues for exactly this! I use plugins like react-select and other JS libraries which uses styled-component and other non-tailwind type css styling options - and this plugin does not play well!

100% agree that adding a simple form-input class was much easier!

[Phixyn]

I've made a patch file of #39 for use with patch-package until the PR gets merged. Seems that a lot of people (including me) want this. Thanks @chasegiunta for the PR!

Patch file gist: https://gist.github.com/Phixyn/7a2779771b0304be23b9f82e144aedb1

After applying the patch, set useFormClasses: true in your Tailwind config file:

  plugins: [
    require("@tailwindcss/forms")({
      useFormClasses: true,
    })
  ],

Now you can explicitly use form-* classes to apply the plugin styling to your input elements, or leave it out to not use the styles.

[adamwathan]

We've added the class strategy now for folks who only want to apply form styles using classes, so going to close this one.

FWIW I don't consider the base style approach to be in conflict with Tailwind at all, in fact to me it feels more correct. Just like we unstyle things like headings and buttons to make them more "styleable" the goal of this plugin is to "reset" the default browser form styles in a way that makes them actually accept utilities gracefully.

Put another way, the goal is for this to just work:

<input type="checkbox" class="rounded-none">

Without resetting the form styles the way this plugin does, you can't do stuff like that. Adding a class like form-checkbox feels more like a component library to me that is providing "designed" form elements, whereas here we are deliberately trying to reset them to a pretty ugly but malleable base.

[1player]

Adding a class like form-checkbox feels more like a component library to me that is providing "designed" form elements, whereas here we are deliberately trying to reset them to a pretty ugly but malleable base.

Fair enough. The biggest reason the class strategy is needed in the first place is when integrating external libraries and widget: on the default strategy one would have to modify the widget CSS to also clear the additional styles added by Tailwind.

In an ideal world where everything is consistently designed by the same team it's a non-issue, but in some projects where you don't have the luxury to write your own calendar widget and have to use a third-party one and ship it, it becomes necessary.

I appreciate the fact that both strategies are viable now, so thanks.

[rjdellecese]

Why not offer an opt-out class, like not-prose in @tailwindcss/typography? (not-forms?) Seems like this would still capture the spirit of the library, while also allowing an escape hatch in the cases where users need to allow full control by pre-styled HTML/CSS components.

[ckizer]

Is there a class in tailwinds v3 that I can use to unapply the tailwindscss-forms plugin from one single element on the page?