I think there are some other benefits of tailwind. Say you have a set of css classes for different components.
Then say one component on one page now needs to be styled differently.
You have 3 options:
1. Create a whole new class which duplicates much of the previous class
2. Create a smaller class which is intended to override some rules from the first class
3. Factor out the common styles into smaller classes.
All have some maintainability concerns, but taking the 3rd option to the extreme makes the problem non existent in the first place.
That’s the real strength of tailwind. Preventing a critical mass of one off styles from making your whole css setup unmanageable
Generally this makes sense to me, and if you are just dropping markup onto the page, and don't need to worry about repeating yourself when using that component, I think that works well. Definitely better than your alternatives.
But if you've encapsulated the component at all, you're going to need to manage that variant somehow. You can't just have an 'extra tailwind classes' prop, since you can't ensure your overrides will take precedence.
Why not expose the component's styles via component-level tokens referenced through css variables? Then your new variant is a single css class on the component root that sets any new component token values that are then loaded by the component's existing css.
I’m not entirely sure what you mean by component-level tokens, but it sounds like tailwind’s themes do what you’re saying.
Most of tailwind’s classes use css variables under the hood, so setting some of those variables in a class and apply thing that class to the top level element of a component will do the trick.
But you could have an “extraClasses” prop with tailwind. Classes that appear later in a class attribute take precedence over one’s that appear earlier.
I also thing it’s possible to mark tailwind classes as important, though I don’t like doing that.
A component level token would be if your `myCard` component populated all of it's styles with component-specific css-variables, e.g. "myCard-bg", "myCard-padding". It's basically defining the styling api for your component. If you have a new variant that needs to style another property, then you should probably extend your component's style api accordingly (by defining a new component token and providing the default). As I say, I haven't yet used this approach, but it does make some sense to me. It's also useful if you're designing components across tech, targeting other style languages besides CSS.
>Classes that appear later in a class attribute take precedence over one’s that appear earlier.
This would be news to me, and it doesn't look like that's the case in TW, based on some experimenting at play.tailwindcss.com. If there are 2 classes on an element with rules that resolve to the same priority and define the same css styles, the last CSS rule to be parsed wins. Presumably you don't have control over that in TW.
Is Lightning primarily web components? That would make sense, since css vars penetrate the shadow dom, so with this approach there's no need to mess with loading your css into the component's shadow dom.
Then say one component on one page now needs to be styled differently.
You have 3 options: 1. Create a whole new class which duplicates much of the previous class 2. Create a smaller class which is intended to override some rules from the first class 3. Factor out the common styles into smaller classes.
All have some maintainability concerns, but taking the 3rd option to the extreme makes the problem non existent in the first place.
That’s the real strength of tailwind. Preventing a critical mass of one off styles from making your whole css setup unmanageable