[munk-a]

It's extremely important to create classes like `.f-green` in case the definition of green ever changes. That's what we call forward portability.

Also, if your company rebrands from green to red you can just `.f-green {color:#f00;}` - it's so efficient!

[agloe_dreams]

This was the only bit in tailwind we modified a lot in our Config. You really need to remove the default colors and define them as [Primary, Secondary, Neutral, Warning, Error, Success] and then add variants of each. Then it really works. I honestly think this should be a default config change/setup option in TW. Nobody with a Design System/Brand guidelines should be including the default colors in their app.

[MrJohz]

I agree that you don't need the default colours, and in fairness this is one of the things that Tailwind fairly explicitly encourages. That said, I also used to use "primary"/"secondary"/etc names for the colours, but since using Tailwind, I've been using colour names directly (e.g. "blue" or for fancier design systems "mirage-blue" or whatever their name for their specific custom blue is).

I find it's helped for a few reasons, but the big one is just that it's easier to keep the colours in my head - I'm not thinking in terms of "tertiary-alt-3" or something, I'm looking at a design and going "that's green, which green? This green". I have more discussions talking about colours in terms of the standard English colour names than I do in terms of those colours' purposes in the design system, so the colour names seem more practical.

That said, I agree that spending some time switching the colours to whatever design system you're using us very useful. Another trick I've found is starting off a project just using raw CSS values (the `p-[8px]` syntax), and then when the basic designs are done based on whatever the designer has sent, getting a list of all the custom classes you've got and using this to define what the standard units are. This is helpful when the design guide isn't specific on these details, and the designer is being more freeform.

[nwienert]

The biggest thing I've learned in making Tamagui is that the ideal setup is not to really have specific colors at all (unless you really really are just doing a one-off single color thing), but instead to let themes handle this (essentially a classname that changes out a set of CSS variables).

Then you can do things like `color1` (or `primary1` or `secondary2`) etc, keeping them generic. With this setup you can then re-theme any area instantly, no dark-x or light-x, no green-x. You can inverse an area to be light on dark, you can change the color out if need be.

We even go one step further (as an optional feature) where you can avoid the `color1` for many cases and instead use `color`, `colorHover` etc, which allows for having themes that change contrast or the strength of their various alternate states, but that's another story.

The site itself shows off some of this, but it's really quite nice. Now your "Notice" box can be alert style, or success style, with just a single `<Theme name="alert">`.

[agloe_dreams]

This is part of why we started down this path. We have a self-white-labeling product based on a JSON file loaded at runtime. Having this sort of theming is kinda a pre-req. but we are totally not blind to the ways we can play with it.

[agloe_dreams]

I would argue that all of what you just said is your designer failing you. For us, we defined the base sizing and colors beforehand and the designer works from there. We also use named color variables and themes in Figma such that an element with a background color shows the named color so I can just type in the same name in TW. Putting design and development at the same table on day one and getting both sides to speak the same language definitely speeds development and I really do think your life would be better for it. While your designer has you stuck picking 8px, 10px or 12 px, my source mocks are just .5rem or 1 rem and I can look at a design at this point and add the right value without even checking. You deserve better from your designer; them being 'freeform' is just them doing whatever feels cool this week and a whole lot of inconsistent values.

[gedy]

This is something Bootstrap does right, and has kept us away from Tailwind so far.

[xeckr]

Or just use var(), which of course didn't exist when the article was written.

That way you can define your company's --brand-colour at the top of the file.

[interstice]

I used to think this way, but 1) it’s easy to do a find replace of f-green and 2) turns out no one we work with changes websites this way. The closest I’ve seen is changing a font site wide with some size etc adjustments

[interstice]

To be clear I still use semantic css and don’t use tailwind, but while aiming for pragmatism.

[CodeWriter23]

Nope. Green should give you green.

[jeffrallen]

Or, like, off-green. And after midnight, green with all the blue taken out.

[CodeWriter23]

Yes of course. But not red.

[nilslindemann]

It should be neither green nor red, but should describe the function. But Tailwind, that industrial CSS framework, has anyway moved far away from that.

[CodeWriter23]

I agree with the abstraction point. But if your tag says “green”, it should deliver green not a different color.

[qingcharles]

Except if you live in one of the many cultures that don't have separate words for blue or green. In which case all your greens should definitely be blue.