Drop default plugins "form", "typography", and "container-queries"

[flavorjones]

Typography and container queries aren't used by this gem directly.

The form plugin is used, but I've attempted to complete styling of the generator template forms without it (though there may still be some differences due to the absence of style reset).

See #443 and #441 for examples of users getting poor rendering due to conflicts between Tailwind UI and the form plugin.

@dhh Really it's up to you whether this kind of minimalism is in line with your vision for the gem? It does seem like some developers and designers want to start from a vanilla initialization that matches what other tailwindcss tools do (Vite, CDN).

Some alternative approaches are also discussed in the comments in #443.

[dhh]

Happy to see these go. As long as everything from Tailwind UI remains copy/paste. I think that was probably the original intention behind adding these default plugins. That they were/thought to be required for Tailwind UI. So if they're getting in the way of that, good to dump.

[flavorjones]

Released in v3.1.0: Release v3.1.0 / 2024-12-29 · rails/tailwindcss-rails

[nickpoorman]

Was merging this a mistake? I'm conflicted because I was running into the copy-paste issue with TailwindUI. However, without the @tailwindcss/forms plugin, users are going to run into very different styles on say desktop vs. IOS.

Try creating a date picker and you'll see it doesn't look right on IOS without the @tailwindcss/forms plugin enabled. It looks like IOS defaults to whatever it wants for that date picker and the form field ends up really small without the plugin.

---

With forms plugin:

Desktop:

IOS:

---

Without forms plugin:

Desktop:

IOS:

---

So on one hand, this PR made Tailwind UI copy-paste easier. On the other hand, it breaks people developing for more than just desktops.

[flavorjones]

@nickpoorman Hmm, sorry to hear it's not meeting your expectations. Although we didn't intend to break things, we did make a conscious decision to merge this for reasons explained above.

Can you provide more details on the date picker you're using as the example above? Is this Tailwind UI or something else?

If people they want the forms plugin they can uncomment the line in the config file, no? Do you have any ideas on how to make this experience better?

[nickpoorman]

I’ve been playing around with it and I’m really not sure how to fix this. I’m by no means a frontend guy so unfortunately I’m terrible at troubleshooting this. The default rails app generator with tailwind does include the tailwind css bundle twice on the page, which seems wrong, but I’m not sure if that would cause these issues.

The odd thing is, the developer cdn script from the tailwindcss instillation page works just fine. https://tailwindcss.com/docs/installation/play-cdn

When I use the cdn script instead of tailwindcss-rails I don’t see any issues with any of the tailwind UI stuff. Although, I’m not sure if that loads the form plugin or not.

The date picker I am using is the standard form builder date_field. https://edgeapi.rubyonrails.org/classes/ActionView/Helpers/FormHelper.html#method-i-date_field

I wanted to double check that I didn’t have some strange setup that was causing the issue so I generated a fresh rails app, copy pasted the tailwind ui two column form and I was seeing issues with it. Disabling the form plugin seems to fix the issues but then I ran into the date_field issue on IOS.

I’ll try to get a demo repo up tomorrow and I’ll report back with it.

Either way, something strange is happening because enabling the form plugin isn’t really an option if it starts breaking things. —Again I’m no expert here so maybe the plugin isn’t meant to be used/compatible with Tailwind UI?

P.S. Hopefully I’m not coming off as not complaining, I just want to make sure we have the right solution here. I really appreciate all the work you’ve been doing @flavorjones especially with the SQLite-Ruby stuff!

[flavorjones]

@nickpoorman Let me try to break this down as well as I understand it

• Using the forms plugin breaks Tailwind UI and most tailwind tutorials that you can find on the net which assume there are no plugins loaded. This is why we dropped it in this PR, as discussed above and in Styling seems off compared to comparable/working build using Vite #443 and tailwindcss-rails is corrupting styling #441.
• Dropping the forms plugin makes some fields look inconsistent.

There are two possible paths that I can think of:

1. Do not use the forms plugin by default, but make it easy for people to add it. (This is the status quo in v3.1.0.)
2. Use the forms plugin by default, but make it easy for people to remove it. (This is what we used to have, which people clearly had problems with when they came from the world of using the CDN for tutorials.)

I'm inclined to keep the plugin out of the default, but leave it as a commented line in the generated config to make it easy to add. This is what is in v3.1.0.

If there is a third way, I'm all ears. Or if something else is broken beyond what I've described above, please open a new issue.

[flavorjones]

Maybe just to sum up:

maybe the plugin isn’t meant to be used/compatible with Tailwind UI

Correct, it's not, as discussed at #443 which links to a conversation upstream with the tailwindcss maintainer: tailwindlabs/tailwindcss#15426. This is why we dropped the plugins.