Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow for <input> without type #141

Merged
merged 4 commits into from Jul 13, 2023
Merged

Allow for <input> without type #141

merged 4 commits into from Jul 13, 2023

Conversation

karlhorky
Copy link
Contributor

@karlhorky karlhorky commented Jul 13, 2023

Allow for <input /> elements without the type attribute (eg. which defaults to a text input), which may be required by certain codebases:

<input /> <!-- same as input with type="text" -->

Also removed the note from the readme, which isn't required anymore if my approach works

Preview looks good - allows for overriding via A) utility classes and also B) input selector:

Screenshot 2023-07-13 at 17 07 06

Ref:

@vercel
Copy link

vercel bot commented Jul 13, 2023

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
tailwindcss-forms ✅ Ready (Inspect) Visit Preview 💬 Add feedback Jul 13, 2023 2:49pm

@adamwathan
Copy link
Member

Hey! This won't quite work because input:not([type]) has a specificity of 0,1,1 which means it is higher than a class, so you couldn't add utilities to the input to override the default styles:

image

I think the right solution is probably input:where(:not([type])) but should make sure to test it thoroughly 👍

@karlhorky
Copy link
Contributor Author

karlhorky commented Jul 13, 2023

This won't quite work because input:not([type]) has a specificity of 0,1,1 which means it is higher than a class

Oh, I'm probably not aware of the deeper details and how @tailwindcss/forms works - just heard about the project today :)

I think the right solution is probably input:where(:not([type])) but should make sure to test it thoroughly 👍

Sure, ok - after b6b4c5a I have :where() in there as well now. Happy to test this, although I'm not 100% sure I know what I'm looking for (eg. what would be a pattern I could use to test the overriding?)... here's a screenshot of the DevTools with the updated preview:

Screenshot 2023-07-13 at 16 53 21

@karlhorky
Copy link
Contributor Author

@adamwathan Maybe this is what you mean by overriding? (added py-12 to the input, which appears to be applied)

Screenshot 2023-07-13 at 16 57 14

@adamwathan
Copy link
Member

@adamwathan Maybe this is what you mean by overriding? (added py-12 to the input, which appears to be applied)

Screenshot 2023-07-13 at 16 57 14

Yep exactly! As long as you can override any of the styles set by the plugin by adding a utility then we should be good 👍

@karlhorky
Copy link
Contributor Author

Great, nice 👍 This also works with the input selector (I documented in the PR description above).

Anything else that I should to do before this is ready to merge?

@adamwathan adamwathan merged commit c846b72 into tailwindlabs:master Jul 13, 2023
2 checks passed
@adamwathan
Copy link
Member

Nope I think this looks good now, thank you!

@karlhorky
Copy link
Contributor Author

Great, glad to help :) Thanks for the guidance, review and merge! 🙌

@karlhorky
Copy link
Contributor Author

@adamwathan (or @thecrypticace, @bradlc, @RobinMalfait) could this be published as a new release? (I'm guessing @tailwindcss/forms@0.5.4 or @tailwindcss/forms@0.6.0)

@adamwathan
Copy link
Member

@karlhorky Yep we'll publish a release when we get a chance, no guarantees it'll be today but soon.

In the mean time you can use the insiders build that is automatically published on every commit:

npm i @tailwindcss/forms@insiders

@thecrypticace
Copy link
Contributor

I published v0.5.4 so there's a proper tag now ✨

@karlhorky
Copy link
Contributor Author

Great, thanks!

@abouroubi
Copy link

I think this should have been a breaking change, it added borders to all our input fields, where the border wasn't present before.

@karlhorky
Copy link
Contributor Author

@abouroubi sorry to hear! To be clear, your input elements do not have a type attribute?

@abouroubi
Copy link

No they did not have type attribute.

@vixeven
Copy link

vixeven commented Sep 1, 2023

I think this should have been a breaking change, it added borders to all our input fields, where the border wasn't present before.

Likewise in my case, many of my custom inputs now have border + focus-ring after the update.
I had to switch to a previous version :/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants