Resolve Quasar and Tailwind CSS conflicts

[gbouteiller]

Is your feature request related to a problem? Please describe.

This proposal aims to resolve conflicts between Quasar and TailwindCSS with minimum changes. Currently, Quasar and TailwindCSS offer both useful classes. This post is not to discuss the pros and cons (you can debate here) but to ease the use of TailwindCSS with Quasar for those who want to.

After investigation (with the help of CSS compare and CSS sort), we can divide Quasar class names in 4 categories:

• Classes prefixed with q- : not a problem.
• Classes not prefixed but not redundant with TailwindCSS (some of these classes are utility classes and could be renamed to match TailwindCSS) : not a problem.
• Classes with the same name and behavior in both frameworks : not a problem.
• Classes with the same name but with a different behavior : it is a problem.

Hopefully, the last category contain only 12 classes in 5 files with few differences:

/* Quasar: flex.styl */
.flex{ display: flex; flex-wrap: wrap }
.order-first { order: -10000 }
.order-last { order: 10000 }
/* TailwindCSS */
.flex { display: flex }
.order-first { order: -9999 }
.order-last { order: 9999 }

/* Quasar: mouse.styl */
.cursor-not-allowed { cursor: not-allowed !important }
.cursor-pointer { cursor: pointer !important }
/* TailwindCSS */
.cursor-not-allowed { cursor: not-allowed }
.cursor-pointer { cursor: pointer }

/* Quasar: size.styl */
.block { display: block !important }
.inline-block { display: inline-block !important }
/* TailwindCSS */
.block { display: block }
.inline-block { display: inline-block }

/* Quasar: typography.styl */
.text-justify { text-align: justify; hyphens: auto }
/* TailwindCSS */
.text-justify { text-align: justify }

/* Quasar: visibility.styl */
.hidden { display: none !important }
.invisible { visibility: hidden !important }
.overflow-auto { overflow: auto !important }
.overflow-hidden { overflow: hidden !important }
/* TailwindCSS */
.hidden { display: none }
.invisible { visibility: hidden }
.overflow-auto { overflow: auto }
.overflow-hidden { overflow: hidden }

You can see that:

• for 8 classes, it is just a difference with the presence of !important in Quasar
• for 2 classes (order-first, order-last), the value chosen for the indexes differ from 1
• for 2 classes (flex, text-justify), a second property is added to the utility class in Quasar

I forgot to mention the particular case of colors that have the same problem of !important (the way I deal with them is described below).

Describe the solution you'd like

As a preferred solution and personal taste, it is possible with minimal modifications to change these 12 classes to avoid conflicts. For that, we could:

• check the pertinence of !important for the 8 classes (after a search they are not used in many components), remove it when unecessary or replace it with another class (named hiddenImportant instead of hidden for instance) or style in that particular cases.
• simply change the values of indexes for consistency (9999 or 10000 is arbitrary and will not impact anything).
• divide the two other classes to utility classes (by the way, for flex, we already have wrap to indicate flex-wrap: wrap) which will be more consistent.

For colors, a clean solution would be (in the case of !important being not that 'important' but a matter of taste) to offer a property in config to add/remove colors (kind of what it is done with brand).

I would also vote for renaming utility classes that only differ from names to have something really robust but it is not mandatory.

Describe alternatives you've considered

For now, for the 12 classes :

• I have chosen to use Quasar as the source of truth because classes are used in some components and I did not want to monkeypatch and maintain each of them on my own (considering that they could be updated by the Quasar team at anytime). Consequently, I use them with caution and add a comment for warning.

For now, I manage colors in this way :

• I recreate quasar.*.css files with a postinstall script that mimic what Quasar do to build CSS but with an index.styl without colors.styl. It is less a problem because it consists only in one file and I am not sure that the !important is relevant for the colors (I didn't encounter problems yet).
• I define all the colors in my tailwind.config.js and it is ok with Quasar that offers the same class names for customization.

Additional information

Also, I would like t o mention two other important concepts:

• Breakpoints : I have configured TailwindCSS to use the same values as Quasar in config. I know that these values can be changed in Quasar as they are stylus (or sass) variables but as I have seen mentions of them in components, I don't really know if it would impact these components badly if I change for instance md or lg values.
• PurgeCSS : I have managed to reduce Quasar core CSS and purge all CSS with something similar as this pull request. But instead of including all src components, I use the same technique that Quasar uses with its auto import process to keep only the styles of the components that I use.

[pdanpdan]

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.

[gbouteiller]

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.

[alexrififi]

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

[jmellicker]

@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!

[gbouteiller]

@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 ;)

[jmellicker]

@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.

[MordantWastrel]

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?

[Batsirai]

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

[charlie17]

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.

[timsayshey]

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

[2x2xplz]

@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.

[sergio-chumacero]

@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 :)

[cinderisles]

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

[fergusmeiklejohn]

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.

[cinderisles]

@fergusmeiklejohn That sounds great, but would be a lot of work. Many components have prop names that only make sense for Material Design. Some components like text inputs are pretty universal no matter the style framework. However, a more complex component like a date picker could look very different depending on custom branding and would be difficult to make generic enough to support a large number of CSS libs.

While still difficult, maybe it would be possible to choose a style guide like Material using a combination of styles and mixins. Using mixins you could pull in all the Material Design specific props and functionality for a component that has been made as generic as possible.

I can also see this being possible using Vue's Composition API. Just pulling in the appropriate setup() function and styles for Material or whatever lib. All this is easier said than done though

[fergusmeiklejohn]

@cavatron I've bene experimenting with building out a custom UI based on Quasar and I'm finding that I only really need fully customisable base level components, like buttons, toggles, text fields. Everything else I really just need a functional box (Dialog, List etc), then I put whatever html/css I want in that box. So Quasar wouldn't have to change as much as I thought to make the framework effectively styleless

[fergusmeiklejohn]

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..

[hawkeye64]

@fergusmeiklejohn That's interesting ot note because the encapsulating div is using "row justify-center items-center" so they should be lining up properly.

[saulmmendoza]

Hello, where can I find news or documentation on Quasar Themes? Is there any way we could help?

PD: Would be nice to know how many people wanted to have typescript support vs themes support, just to hate more typescript for taking precious time from quasar dev team 🤓

[ontwikkelfabriek]

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

[fergusmeiklejohn]

@hawkeye64 I know.. it's beyond me to figure out why the CSS is fighting (or seems to be, as I say it's beyond me...) Just another example to illustrate: I used @sergio-chumacero post-css technique (which helped a bit thanks Sergio!) but this is the same code in Tailwind play and in a Quasar app..

            <div
              class="z-10 mx-3 origin-top absolute right-0 left-0 mt-1 rounded-md shadow-lg bg-white ring-1 ring-black ring-opacity-5 divide-y divide-gray-200"
              role="menu"
              aria-orientation="vertical"
              aria-labelledby="options-menu"
            >
              <div class="py-1">
                <a
                  href="#"
                  class="block px-4 py-2 text-sm text-gray-700 hover:bg-gray-100 hover:text-gray-900"
                  role="menuitem"
                  >View profile</a
                >
                <a
                  href="#"
                  class="block px-4 py-2 text-sm text-gray-700 hover:bg-gray-100 hover:text-gray-900"
                  role="menuitem"
                  >Settings</a
                >
                <a
                  href="#"
                  class="block px-4 py-2 text-sm text-gray-700 hover:bg-gray-100 hover:text-gray-900"
                  role="menuitem"
                  >Notifications</a
                >
              </div>
              <div class="py-1">
                <a
                  href="#"
                  class="block px-4 py-2 text-sm text-gray-700 hover:bg-gray-100 hover:text-gray-900"
                  role="menuitem"
                  >Get desktop app</a
                >
                <a
                  href="#"
                  class="block px-4 py-2 text-sm text-gray-700 hover:bg-gray-100 hover:text-gray-900"
                  role="menuitem"
                  >Support</a
                >
              </div>
              <div class="py-1">
                <a
                  href="#"
                  class="block px-4 py-2 text-sm text-gray-700 hover:bg-gray-100 hover:text-gray-900"
                  role="menuitem"
                  >Logout</a
                >
              </div>
            </div>

I feel like Quasar is trying to be Vuetify, NuxtJS and Ionic all at once and while that is very cool it's also leading to conflicts

[fergusmeiklejohn]

I also spun up a Vue cli app to check and it's fine:

[hawkeye64]

@fergusmeiklejohn :man_shrugging: Sorry, I have never tried to do what you are doing, only suggestions.

[sawanm9000]

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.

[hawkeye64]

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

[pjar]

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.

[smakinson]

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

[SKFrozenCloud]

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.

[akshay-sood]

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!

[SKFrozenCloud]

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

[hawkeye64]

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

[smakinson]

@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

[hawkeye64]

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

[ldiebold]

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.

[mila76]

I'm thinking on a similar idea as @ldiebold Add on vite plugin the unocss, make a preset that mimic quasar utility classes Use another scss for bootstrapping the vite plugin that not have the utility class of quasar

Doing so we have a much smaller css bundle and have access to many more utility class. I'm not saying to redo the ui with atom css in mind that is not a good idea (I personally don't like the "tailwind/atomic way"), only the css utility class part in quasar.

I know is not so simple because the plugin don't see the utility class used in quasar native component. Maybe talking with the author of unocss there is a way or make an "extension" for that problem.

But I think is a doable path with some offer from the quasar team and the comunity (I try myself this route when I have spare time and see if something work) Maybe can make that happen for quasar3 (if the idea of rewrite the cli to use vite instead of webpack is on roadmap) and a "beta testing" for the vite plugin

[ldiebold]

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

https://youtu.be/SpRfYw1p6bA

[damms005]

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

[Tofandel]

I don't think this issue should be closed, there really isn't a lot of conflicts and they could easily be fixed by dropping the !important keyword on the display helpers Adding a prefix to all tailwind classes is a painful solution and having quasar and tailwind complete each other would really be nice

[Tofandel]

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

[damms005]

@Tofandel I think you did not check the document linked in my comment

Adding a prefix to all tailwind classes is a painful solution

I don't know what your use-case is, but for the standard Tailwind deployment, simply adding the prefix option to your Tailwind config does the magic

[Tofandel]

It's not about adding the option, it's about developping with a prefix, it makes it a lot more error prone because you never know which prefix to put where. It also very hard to do for an existing app (imagine having to replace 5000 classes...)

[damms005]

Sorry. My bad. I linked the wrong article but gave the wrong explanation! Well, your bad too, you should read the linked documentation :)

Anyways. You are not prefixing anything. The linked article clearly states that you specify a CSS selector that is used automatically for your generated Tailwind CSS file

[damms005]

So, usually, the selector will wrap your document root. E.g. .container, .tailwind-container or even body tag. Whatever wraps your Tailwind comfortably for your use-case. Then you put the Selector for this same wrapper into your Tailwind config file. Then when your CSS is generated, Tailwind's shiny brand new JIT engine will intelligently wrap your Tailwind classes with the selector, so that your TailwindCSS styles are used over and above Quasar component declarations due to the Rule of Specificity

[Tofandel]

Well in that case that doesn't solve the issue, specificity doesn't solve the fact that quasar uses !important and tailwind doesn't in the conflicting selectors

[damms005]

Please note that my response to OP is directed at solving OP's specific use case and also adding my voice to the solutions already provided on this page; and they all achieve OP's aim perfectly well.

You may need to open another issue if your aim is not to have Tailwind CSS' style applied to your components instead of Quasar's (which is what my suggested approach provides, together with other approaches previously mentioned in this same issue)

[Tofandel]

And I just highlighted that your suggested solution exactly doesn't do what OP is asking See

/* Quasar: visibility.styl */
.hidden { display: none !important }
.invisible { visibility: hidden !important }
.overflow-auto { overflow: auto !important }
.overflow-hidden { overflow: hidden !important }
/* TailwindCSS */
.hidden { display: none }
.invisible { visibility: hidden }
.overflow-auto { overflow: auto }
.overflow-hidden { overflow: hidden }

Notice how quasar uses important and tailwind doesn't. Hence your solution cannot work for those cases which is exactly what we are after, and that I also gave a workaround that does just that by adding a ! in front of conflicting classes

[damms005]

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!

[Tofandel]

@damms005 Sorry but you're 100% wrong a higher specificity doesn't override !important that's exactly the point of !important

If you choose to argue instead of getting results, then I'll just leave you to yourself. Stop running goose errands and get to work!

I'm not the one doing that, but maybe go learn something about the basics of css before picking a fight

https://www.w3schools.com/css/css_important.asp

Important About !important The only way to override an !important rule is to include another !important rule on a declaration with the same (or higher) specificity in the source code - and here the problem starts! This makes the CSS code confusing and the debugging will be hard, especially if you have a large style sheet!

/* Quasar: visibility.styl */
.hidden { display: none !important }
/* TailwindCSS */
.prefix .hidden { display: none } /* Doesn't do anything */
.prefix .hidden { display: none !important } /* Now it does */

[damms005]

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!

[Tofandel]

Apologies accepted, you can then ignore my tone as well

But I still think there is a misunderstanding in what we're talking about because in your link there is the same warning again

Note: The only way to override this !important declaration would be to include another !important declaration on a declaration with the same specificity later in the source order, or one with higher specificity.

So I don't understand how could tailwind which doesn't use important but has a higher specificity override quasar which uses important and a lower specificity, because !important always gets the last word

PS: Sorry about the spam for the 25 participants