Supporting TailwindCSS natively

[khawarizmus]

Problem to solve

This is supposed to be an open discussion and a suggestion more then a feature request but since Vuetify Issuer creator doesn't yet support discussions, I went ahead and choose a feature request type.

Vuetify currently uses CSS utility class and few props to control the styling of the framework and those are great. However it requires some effort from the team to maintain and evolve and it's a moving part in this project that the team is handling.

Proposed solution

Since Vuetify is being ported to Vue 3 (not completely from scratch) and the team has been already looking into unifying the naming conventions of the utility class based on VueConf Toronto
Talk by @johnleider which was great BTW and is doing some work around that.

I suggest that the team considers using TailwindCSS utilities class in staid of "re-inventing the wheel" and offloading the overhead to tailwind.

The purpose of this issue is to discuss the pros and cons and why not using TailwindCSS but to me the biggest factors are:

• Offloading the load to a very strong project that is fast growing in development and popularity and building an ecosystem around it.
• TailwindCSS is very flexible and comes with a configuration file that would enable a whit-label kinda approach to theming configuration (which again from the VueConf Toronto
  Talk I know the team is trying to achieve).
• TailwindCSS also have a plugin system which would enables further customization for missing utility class (i am thinking of a ripple effect class for example).

Finally, the two projects are both exemplary open source projects and would really make a perfect match, it would be really exciting to see that happen!

[Rolanddoda]

🆙!

Does anyone knows if v3 is going to add support for tailwind ?

[khawarizmus]

Would love to hear what @johnleider @heatherleider @KaelWD and @MajesticPotatoe think about this. it would be helpful to know if the core team is interested to look further into this discussion/proposal :)

[johnleider]

Not to dive in on any specifics, it's something we have discussed as a team and with the new version it could theoretically work. We'll have more on this once we hit beta.

[Rolanddoda]

The white-label approach. In a talk you said that the framework will have a default styling for their components but we can turn that off so we can have our own styles but still have all the well-tested functionality of a component.

That was a really exciting feature but in the docs I can only see: "By default, Vuetify components have no color and are white-label in nature" which sounds very different from what was introduced in the talk.
I personally thought that "white-label" is what others refer to as "unstyled" components where you can turn off the default styling and apply your own.

[Rolanddoda]

https://youtu.be/aXY4upCtiPI?t=1916

[hermes85pl]

Nothing will happen. Vuetify components don't use utility classes for default styling.

@johnleider, unfortunately this is not correct. Surely at least the blueprint for MD3 breaks, see #18846. Unless by "default styling" you don't mean blueprints 🙈. Still, as an end user, I perceive a blueprint as a variant of default styles, and the documentation doesn't warn about the side effect of breaking blueprints in case you completely disable the utility classes feature.

[johnleider]

Fair enough. Updated the docs 488f594

[Splinterjke]

The components' evelvation prop depends on utility classes. So disabling utils breaks some styles in case a non-zero elevation is considered as a default styling for some copmponents. Anyway, elevation is still easy doable by using unocss (or any other css helpers). Of course enabling layers is recommended in that case.