I've been working on a 6wk contract gig to shore up some code, and the previous developer decided to go with Tailwind. I've mentioned why I think that's a bad idea before, but I had to explain to my new clients some of the problems that have happened because of that initial poor choice:
ME: So - I realise that it was another {my contractor} developer who chose to add Tailwind to this project. I don't know his or her reasoning. I can tell you, however, that one of the big problems with using Tailwind to create UI components is that it is extremely difficult (near impossible) to overwrite those properties assigned by tailwind utility classes when trying to extend a component to have the same functionality but different styles.
I think for now it's best to just create a seperate "TransparentButton" and "RippleButton" components which are independent of the Button component defined in {our UI library}.
Response:
I believe the overall goal with adding tailwind was to reduce the number of components and or css classes/styling we have to maintain. Ideally we maintain "nothing" outside of our core value prop and can just plug & play industry standard components & libraries.
I think that is a noble goal. Unfortunately, in practice, I find Tailwind to actually be counterproductive to that goal, because since you can't just make minor tweaks to existing libraries, or existing components, you end up having to recreate entire components from scratch.
This is mostly because CSS does something Tailwind doesn't - it cascades.
That is, if the library has a button called "Button" with the className of "bg-orange", it will have an orange background. I can't then modify Button with react props or adding more Tailwind classes to create a button that is identical except it has different styling, (such as a transparent background).
On the other hand, if the library's Button component were created with a CSS file associated with the class .button, where button was defined as
.button {
background-color: orange;
}
I could simply use that component, add another class name (.transparent-button, for example) and then define the .transparent-button with
.transparent-button {
background-color: transparent;
}
The computer will read <button class="button transparent-button">Button</button> as "First apply the .button styles. Then apply the .transparent-button styles, overwriting any styles that are different."
Tailwind doesn't have that functionality, in part because a design choice of tailwind is that it sorts class definitions according to it's own criteria (which I presume is alphabetical) in the tailwind postprocessor, not based on the order in which you write them.
So, If you were to define <button class="bg-orange bg-transparent"/> then Tailwind would apply the orange. Because (I presume) "bg-o" comes before "bg-t" alphabetically.
Top comments (3)
Not sure if I understood the issue correctly. The order of class names inside the class(-name) attribute does not influence which css rule overwrites another rule.
So
<button class="foo bar"></button>behaves identical to<button class="bar foo"></button>If you add a special-case class with a transparent background it either needs to have higher specificity or needs to come later in the CSSOM (which could be influenced by import order).
But I must admit I don't have any experience with tailwind and don't know how tailwind handles all the css rules in the build step. I am still firmly in the one bespoke css file per each component camp and see no reason to abandon the approach.
I've demonstrated this isn't how tailwind works in their sandbox in the top div with bg-orange-500 and bg-transparent.
play.tailwindcss.com/abJssqXxcb
Can you offer an example which supports your argument?
Very much agree.