quasar: Resolve Quasar and Tailwind CSS conflicts

This is one of those opportunities to open up Quasar to a wide swath of new users. A lot of devs resist Material - we’ve all seen that, and increasingly so. People want more design choice and control - with some quality building blocks to work with - that’s why Tailwind has been so successful.

People also want to build top-quality Vue apps for all platforms using the right building blocks - that’s what Quasar is all about. So it’s different core competencies, but pointed at the same addressable market.

As another corollary, check the new PrimeVue release - they put “themes” front and center. You can change it anytime in the top menu, showcasing its flexibility. A deliberate choice on their part.

Those reading this post know that Quasar beats PrimeVue, Vuetify and all the rest hands down. Quasar is so much more than a collection of components, so much more than a presentation layer. But a lot of folks won’t look past the doorway if they believe they are locked into Material. You lose 'em before they get a proper introduction. Put this in place, prominently brand compatibility with Tailwind, put some basic guidance in the docs…and you take that resistance off the table.

Another question worth asking IMO is why does Quasar need to have its own utility classes at all instead of just using Tailwind? Simply using Tailwind would greatly reduce the load on Quasar contributors since they would offload all the thinking about design systems to the Tailwind team. If all Quasar components were re-written using headless ui, Tailwind and maybe take the CSS-in-JS route (e.g.: vue-emotion), it would be easier for devs to customize everything to their needs.

This is something worth considering for, maybe not Quasar 2, but version 3.

Create a ‘Quasar devtools’ that has access to fs instead of being a browser extension and base it on Vue.js devtools and ui-devtools, bake it into the Quasar CLI and we’ll have a very good DX.

Our company is new to both Quasar and Tailwind (but are already Quasar supporters on Github because we like it so much!). May I add our perspective here with respect to the term ‘frameworks.’

We selected Quasar because we wanted an application architecture and build framework. The functionality suited our needs and the speed with which we can get off the ground was very nice.

We also understand that any framework selection comes with a certain amount of “opinion” on how things ought to be, or – at the very least – some implementation decisions made to meet the goal with the resources available. So we have no complaints with respect to anything in Quasar today.

Having said that, from a business perspective, there is no relationship between “what” we want Quasar to do for us and how it looks, outside of some obvious items like Q-components that govern the layout of your whole app. But that’s a very small number of components. For everything else, all we want from Quasar is function and build-time considerations (like knowing everything we build will translate to a mobile app). For everything else, we want to rely on Tailwind and TailwindUI – not out of any judgment that Quasar or material design aren’t to our liking; it’s just a matter of our app and its audience.

In other words: We don’t want our application architecture (functional framework) to dictate appearance (CSS framework) any more than is absolutely necessary.

“But Quasar is a material design framework,” you say: That is absolutely part of how Quasar is today and we get it. For us, Tailwind is anything but superfluous, and the conflicts appear significant but not overwhelming. I’m the business guy more than the developer on this one so maybe I’m missing something; it seems like it’s possible to please everyone here and just a matter of legwork.

We are prepared to devote some resources to this issue if it will help: We are rebuilding a large legacy app that doesn’t have to see a production release for six months. I don’t want to have to go ‘all material design’ any more than I want to have to scrap all the q-components we’re using and re-write them. What is needed to facilitate this?

@jmellicker As I mentioned, Quasar CSS is already doing a great job and it is just about some minor changes that could be taken into account in the future. For example, changing a value of an index from 10000 to 9999 is about 2 seconds, it doesn’t affect anything in 99,99% of cases (the 0,01% would be the case of someone deciding to use a custom index near to that value) and would avoid conflicts. Concerning the ‘!important’ keyword, I think it can be debated (and it already has been many times in the CSS community as some people consider it to be a bad practice) in the way that changing it would imply changes for the components and breaking changes for some users. Finally, about the two classes ‘flex’ and ‘text-justify’, my personal opinion is that unique property for utility classes in a CSS framework/library is more robust. For that particular change again, it is an easy fix for the framework but again, can lead to breaking changes for some users. As @pdanpdan wisely said, it should only be considered for a next major breaking change release and I totally agree with that. That being said, and with all due respect to your big experience, allow me to disagree on the fact that if some upstream thoughts can make the next release easier to integrate with other existing growing tools with minor development, it should be worth the risk to consider it. Besides, I think it is less costly to ease the use of a specialized library like Tailwind with Quasar and think “modular” than integrate all its functionalities natively into Quasar. In that spirit, Quasar app extensions are awesome. Last, about discussing it more productively, I think it already has been done on other issues and it looks like maybe you misinterpreted my intent here. So, to clarify, this issue was not to give more work to the team that made and continue to make a wonderful job with Quasar but, at the contrary, to ease their work by showing exactly what had to be done if they decided to resolve the conflicts with Tailwind in the future. In fact, It took me quite some time to review it 😉

We came up with a workaround on our team to get Quasar and Tailwind to work together. Our goal was to build everything in Tailwind on Quasar but we didn’t want Quasar styles loading in and taking over or conflicting with our Tailwind styles. The first thing we had to do was prevent the Quasar stylesheet from loading in however there is no option to disable it so we do a find/replace to remove it when webpack builds.

Run npm i string-replace-loader then add the following code to the extendWebpack() method in your quasar.conf.js file:

cfg.module.rules.push({
  test: /client-entry\.js$/,
  loader: 'string-replace-loader',
  options: {
    search: "import 'quasar/dist/quasar.sass'",
    replace: '',
  },
})

Then to limit Quasar styles to a specific Quasar component, we’re going to scope all Quasar classes to a specific wrapper class. To do this, create an app.scss file with the following code in it and add app.scss to the css:[] property in your quasar.conf.js file. ie css: ['app.scss'],:

.quasar-style-wrap {
  @import '~quasar/dist/quasar';
}

Here’s an example of how to apply Quasar styles to your Quasar Component:

<div class="quasar-style-wrap">
  <div class="q-pa-md flex flex-center">
    <q-knob
      v-model="value"
      size="50px"
      color="orange"
      class="q-ma-md"
    />
  </div>
</div>

With this solution, the actual Quasar components still use Material design and not Tailwind but it no longer conflicts and you can still use Quasar components when needed.

This workaround will get us by for now. However it would be nice for the Quasar team to add a way to disable Quasar styles from the config file without the Webpack replace workaround. And of course, Tailwind versions of the Q components would be great too.

Hope this helps!

-Tim

We are using Quasar and TailwindCSS/TailwindUI in a production app. In truth it’s a mix of material and tailwind, but if quasar’s material design was more of a theme, then it would allow for a variety of component customizations or plugins.

For us, we just style the Vue/quasar components in some places. But as design options/choices begin to grow (so many CSS frameworks and themes… imagine quasar apps that don’t look the same. We use quasar for the component functionality- not for its appearance. The appearance is not bad at all, but not everyone wants a material look.

I could see the day where quasar components have Bootstrap, Atomic, Tailwind, etc themes or plug-ins/extensions

I am closing this as it seems the best way to resolve is to have TailwindCSS classes use a prefix (ex: tw-)

@gbouteiller I think you have submitted an intelligent and well-thought out request, but I would suggest you consider just using Quasar CSS, rather than asking Quasar team to spend time trying to get two frameworks working with each other, since this is such a marginal edge case that likely, only a tiny number of Quasar community would benefit from.

As a designer for the last 20 years, working with companies like Apple, Canon, Intel and others, I 💜 Quasar CSS and have been creating beautiful UIs with it, I find it very easy to customize and make anything I can imagine, perhaps a more productive conversation would be, what specifically do you think could be improved in Quasar?

This is just my personal opinion!

@timsayshey thanks for the workaround, seems like it may take a while for an official solution to the class conflicts. It seems to me that your current approach has the following drawbacks:

• All CSS from Quasar is active within the container, so the conflicts can still arise inside of it.
• Many components and utilities depend on CSS outside of the components themselves (like dialogs and layouts), so placing these within the helper class won’t suffiice for them to work properly.

I am using the following workaround which should allow Tailwind and Quasar to work together without helper classes and without confilcts:

The idea is to use the postcss-remove-declaration plugin to remove the conflicting class declarations loaded from Quasar before importing Tailwind which would replace the removed classes. (I guess this can be considered a monkey patch.)

Install the PostCSS plugin:

yarn add postcss-remove-declaration --dev

Then add the plugin before the Tailwind import in postcssrc.js:

// postcssrc.js

// ...

// These are the conflicting classes between Quasar and Tailwind. They may change in the future.
const conflictingClasses = [
  // flex must be treated separately
  "order-first", "order-last", "cursor-not-alowed",
  "cursor-pointer", "block", "inline-block", "text-justify",
  "hidden", "invisible", "overflow-auto", "overflow-hidden"
];
// The plugin takes an object where the keys are the selectors and the values are the properties (or list of properties) to remove or all properties with "*".
const removeObj = {
  ...Object.fromEntries(conflictingClasses.map(cc => [`.${cc}`, "*"])), // Removes all properties from conflicting classes
  body: ["font-family", "font-size"], // You can also remove things like fonts and colors.
  ".row, .column, .flex": "flex-wrap" // Turns out rules defining multiple classes must be targetted as a whole.
};

module.exports = {
  plugins: [
    //...
    require("postcss-remove-declaration")({ remove: removeObj }), // The plugin must be placed before Tailwind import!
    require("tailwindcss"),
    require("autoprefixer"),
    //...
  ]
};

// ...

Hope it helps. Hopefully these workarounds will not be needed in the future. Quasar is great, and so is Tailwind, so why not use both 😃

@gbouteiller thanks for clarifying, you make some excellent points, I think debates like this are of value to see all points of view, and I did just see the other issue with more info, sorry I didn’t see that before.

While IMO Tailwind is superfluous when working with Quasar, implementing your suggestions could result in some Tailwind fans using Quasar, so your idea could be a net positive for Quasar in this case.

I see a future (and this future will have to wait) where we could use unocss - or something like it - to solve all these problems. To the best of my knowledge, Quasar needs to include many of the helpers because they’re in core. But imagine this…

• Quasar has a unocss preset that includes all the css it currently uses (e.g. q-mt-sm). This cannot be changed.
• Quasar exposes a way to extend unocss. For example:

{
  unocss: {
    presets: [],
    rules: []
  }
}

This way we have no breaking changes, and people could add any preset they like! You could add tailwind, tachyons, windi, bootstrap… or go wild and use unocss’s default preset.

Now of course there may be some small problems. There may be some clashes (as pointed out in the original issue). We’ll need to figure those edge cases out, but in the meantime you could just switch flex block etc on/off in unocss. These are solvable problems.

My gut tells me this way of doing this will be the future of many frameworks.

Having said all that, what @jmellicker pointed out about just trying to use Quasar’s css for your UI is wise. I’ve been working on a Large Quasar project, 5 days a week, 9-5 for over 5 years now. We have written about 20 lines of CSS (and we have some pretty involved UIs). Everything else uses Quasar’s utility classes.

Yes i just do it (my previous test is with the vite plugin only) Here a quick guide: npm i -D unocss quasar new boot unocss in src/boot/unocss.js import "uno.css"; in quasar.config.js boot: ["unocss"] and under build section vitePlugins: [["unocss/vite", {}]]

Do u guys tried Vuetiful? https://vuetiful.dev/docs/getting-started

We’ve been using Quasar for several years and with Unocss for a year now. It would be nice if all Quasar classes had a prefix like q-hidden this would solve the issue.

In the meantime we work around making our own classes when we have a conflict.

.tw-hidden {
  display: none;
}

Then we use tw-hidden instead of hidden. It’s not the prettiest solution but it works.

@gbouteiller this is a cool project thank you for taking the time to look into this.

@jmellicker Quasar CSS can indeed be used to make beautiful UIs. Nobody doubts that. You (and most of us here) have made the decision to learn the entire Quasar ecosystem. My issue (I started #5618) was that there are many, many web developers who already know Tailwind who probably never try Quasar because they can’t use the CSS they already know.

Every project is opinionated. React developers probably don’t migrate over to Quasar often because it’s based on Vue. The same way, devs/designers who are really comfortable with Tailwind probably get turned off by Quasar’s custom CSS. Once you learn it, it is pretty great. So it is less about which one is “better” or makes nicer UIs (both are terrific) but making it easy for the huge number of Tailwind users to join us with Quasar (basically, what @charlie17 said)

Tailwind just released this graph of user adoption today: https://adamwathan.me/tailwindcss-from-side-project-byproduct-to-multi-mullion-dollar-business/

It is 3x as popular as when I wrote that issue just 9 months ago! Again, my argument is not that one is better than the other, I just want Quasar to be embraced by the huge number of people who already know and love Tailwind.

Does adding a prefix to TailwindCSS classes work e.g. tw-flex ? Since you can do that in the TailwindCSS config file, it’s easier (and better) than changing Quasar.

An off-top here, but kind of related to how quasar classes are named. I’m strongly against using tailwind and utility classes for many reasons, but I don’t want to start another discussion on the topic. However, even without using tailwind, quasar css class naming already make it hard to find and overwrite them in our project, and what would make it way easier is to add some prefix to all classes that quasar introduces, like qsr- etc.

I used to love Quasar and I suggested it many times over other frameworks to the company I’m working for. However, I’m really disappointed since there’s still no news about the V3 which will bring “naked” components and all the work is focused on the new docs that doesn’t reflect the true power of Quasar, unfortunately… All the other frameworks have beautiful docs that one can browse while enjoying being and they are offering ways to customize styles…

@stoem Unfortunately I have to agree here. I’ve been using quasar for one year now and everything is great, except theming. I was looking for ways to customize it for some time and none of the workarounds are really acceptable. It is a shame because there are some people who won’t even consider quasar because of the material design. I read one of the core developers (I don’t remember who exactly) saying that it is just CSS, so it is up for us to change it as we we want. But that’s not that easy for reasons already brought up here and other issues. Closing this issue without a solution gives a message (Well, I guess that after 2 years, it is more than a message) that who is responsible for quasar don’t care about theming.

I successfully use Quasar in Laravel Nova (which uses Tailwind CSS), but the only problem is using

flex-wrap: wrap

in quasar .flex definition.

I think .flex should be native

Hey, bump. I revive the issue because it would be really cool to have Quasar + tailwind working together.

Are you aware that your example above is inconsequential because a selector with a higher specificity overrides !important declarations? It does not matter that Quasar uses !important in their style declarations, because the higher specificity introduced by prefixing your Tailwind classes overrides Quasar’s !important declarations.

If you choose to argue instead of getting results, then I’ll just leave you to yourself. This will be my last response on this. Stop running goose errands and get to work!

Hey, jumping on this a little late, but I think that @patforg nailed it on the solution. I started trying to implement a few Quasar components into other existing projects and noticed that the css classes used in the components conflicts with other classes. For instance, a lot of other frameworks (utility, ui etc.) use the classes [row, col, ml, pl, …] so when dropping in Quasar component the style of the component will break. Ex. Quasar Editor has a class of “row” in the toolbar, but it conflicts with other utilities that also declared that class, thus braking the toolbar:

I think that maybe not by default, but as an option, if there was a config section where it would allow to declare a “prefix” of all classes that currently don’t have the “q-” to incorporate it, it will help tremendously.

.q-row{
  //...
}

And the benefits will be:

• No conflict mode
• Allows to use only some components as dropins into other existing projects
• Allows slow migration of projects using other frameworks to Quasar
• Allows integration of Utility atomic frameworks (like Unocss, etc) to complement/enhance the functionality

Hope this helps.

Tailwind 2.0 is released: https://blog.tailwindcss.com/tailwindcss-v2

Maybe it one solution would be a style-less quasar option, the components keep their function but we have to style them ourselves. It would be a bit like ejecting from the starter configuration: you make the MVP in Quasar with default styling but then restyle it on brand when the time is right. Ideally you might eject from all Quasar component styling or just on a component by component basis.

I had conflicts between Quasar and Bootstrap 3 that I resolved this way:

// Bootstrap's row class gives -15px to margin-left and margin-right, messing up Quasar styles
[class*="q-"].row {
  margin-left: unset;
  margin-right: unset;
}

This will select every element whose class attribute contains q-, leveraging the fact that even though not all Quasar class names are prefixed, it is highly likely a non-prefixed class will also be assigned alongside a prefixed one.

This lets Quasar and Boostrap keep their own definitions for .row

I imagine you can do something similar with Tailwind conflicts

Hello @pdanpdan. Hope you’re well during this particular time and thank you for your return. I don’t know if it can be considered as an “issue” for TailwindCSS as their css choices have been debated a long time regarding what to keep and leave, how to name things and I think they achieved it gracefully. And I think Quasar is amazing on many points and really just a close step behind in the styling field. If I can modestly contribute, feel free to ask.

Hello. It’s a very nice analysis and we’ll try to account for this in the next major breaking change release. Meanwhile you can open the same issue on tailwind and see if they can do something about it.

update my repo to use Attributify Mode default preset have windi/tailwind import "uno.css" is the main entry for unoCss (view unoCSS docs) where the generated css go

UnoCSS released a webpack version that’s working with Quasar!

https://youtu.be/SpRfYw1p6bA

I use it too in my project, it works great.

But the question I guess is if you should be able to change Quasar CSS class names which I think they should not. I think any CSS framework you add to Quasar should be able to add a prefix like tw for tailwindcss

Thought I’d add a couple of recent tailwind just in time compiler related things incase it is helpful in this discussion.

https://www.youtube.com/watch?v=3O_3X7InOw8 https://github.com/tailwindlabs/tailwindcss-jit

@utopianknight We have discussed that, but it’s on hold right now for the Vue 3 port.

Hello everyone, I found a different solution for these problems. By reading the tailwindcss docs I discovered how to work with third party libraries. So in my tailwind.css file loaded by the file called quasar.config.js (css: [‘app.scss’, ‘tailwind.css’]).

Add this:

@tailwind base; @tailwind components; .xyz-hidden { @apply hidden; } @tailwind utilities;

Where the class called .xyz-hidden works like hidden by native class from taildwindcss.

I hope it will be useful.

Ooof, is there official word from the quasar team that in fact they will leave things as they are and not attempt to solution a world devs can use tailwind in quasar with no conflicts? In our current project we’re heading into styling and this is critical and damming information to us. We would not have ever started with quasar knowing this information. It’s very unfortunate given quasars flexibility in multiPlatform and yet have a reverse approach when it comes to the styling. Real shame on them if they haven’t started solutioning this.

Then I did understand correctly and can give you examples of where it doesn’t work

/* Quasar */
.hidden { display: none !important }

/* Tailwind with prefix */
.tw .hidden {
    display: none;
}
@media (min-width: 1024px) {
  .tw .lg\:flex {
    display: flex;
  }
  .tw .lg\:\!flex {
    display: flex !important;
  }
}

When you use the class hidden lg:flex you will see that it doesn’t behave as expected and it’s always hidden even on a large screen because of the !important in quasar

But if you use hidden lg:!flex then you’ll get the correct behavior because you get the !important keyword with tailwind

So while overall it does solve some problems of specifity with flex where !important is not used, it fails to solve the parts where quasar uses !important, but there is a workaround using the exclamation mark on the tailwind classes that are conflicting

Oops! That went sideways quickly. Lol.

First, I apologize for sounding like an arse in my last comment. Just pretend that I didn’t use that tone now, shall we 😜 ?

So, apart from not wanting to be an arse, the reason I am replying you again is because I want current and future readers of this thread to not be misinformed.

Now, there are two important (pun intended) things you need to understand about CSS !important rule: Cascade and Specificity. Explaining this here is beyond the scope of this discussion, but you can check this MDN article for details.

However, summarily, Tailwind’s selector overrides Quasar’s because of higher specificity, because Quasar’s sector targets component classes, but Tailwind selector targets same component classes AND the (configured) class prefix. This makes TW’s style override Quasars. That’s kinda like the best I can do for you buddy. You’ll need to check that MDN link I posted above if you seek further clarifications.

Finally, if you are still confused/unclear about this or you are still having problems handling conflicting TW and Quasar styles, you can set up a sample repo and then we can look at it together.

Cheers!

I have found that a workaround is possible with tailwind by adding ! in front of the class to apply the important keyword

Like !hidden md:!block

Might be worth documenting somewhere

Do u guys tried Vuetiful? https://vuetiful.dev/docs/getting-started

I don’t think I can thank you enough for this! 🤩

Also looking how to integrate Tailwind and Quasar…

It’s 3 years later and I was hoping the option to switch off the default quasar sass would have been supported by now but guess not.

That said I have an update to the replacement solution that supports Vite incase it helps anyone:

npm i vite-plugin-filter-replace

const replace = require('vite-plugin-filter-replace').default;

module.exports = configure(function (/* ctx */) {
  return {
   ...
    build: {
      extendViteConf (viteConf) {
        // Add filter-replace to the plugins array
        viteConf.plugins.push(
          replace([
            {
              filter: /client-entry\.js$/,
              replace: {
                from: "import 'quasar/dist/quasar.sass'",
                to: '',
              },
            },
          ]),
        )
      }
   ...

@stoem

There is a task in the project called Explore UnoCSS to power Quasar CSS utility classes.

Quoting the task description:

UnoCSS could help us to

make our CSS helpers swappable with another presets (eg. Tailwind) reduce the overall CSS weight drop q- prefix user custom dynamic extensions

Sidenote: I’ve worked on projects with both, Quasar and UnoCSS and using UnoCSS as an engine to generate CSS utility classes works fantastic.

I’m not sure why this issue has been closed as it remains unresolved. It doesn’t fill me with confidence that the Quasar team has not resolved this after two years. The use of !important on a class with such a common name as .hidden for example is bound to cause issues and in fact is really bad practice.

And rather than solving the problem you close the issue?

I also find this useful: https://tailwindcss.com/docs/configuration#selector-strategy

@smakinson Check out this video by @ldiebold https://www.youtube.com/watch?v=zWJgcvAyB0g

@hawkeye64 I thought this might be worth dropping in here. I wonder how it could play out (when its ready) with quasar. Sounds pretty interesting: https://antfu.me/posts/reimagine-atomic-css

Does adding a prefix to TailwindCSS classes work e.g. tw-flex ? Since you can do that in the TailwindCSS config file, it’s easier (and better) than changing Quasar.

I have just spun up a Quasar v2 RC project with Tailwind and have a tw prefix, seems to be working fine till now!

This is an example of why Quasar needs to please resolve these css conflicts. The bug is subtle. Two buttons:

1. Rendering in Tailwind Play
2. Rendering in Quasar The html and css are exactly the same. See how the icon and text are not aligned in the Quasar rendered button, and the Quasar button x/y axis ratio is also changed…