The biggest benefit of this over inline styles is that if I decide to change the color of "gray-700", since those colors come from a configuration, I only need to change it in my configuration.
It takes some getting used to of the rules, but after a day or two I don't even need to think about what the class names are.
I've actually come across C code that had "#define ONE_THOUSAND_TWENTY_FOUR 4096" because that was the audio buffer size and later had to be increased to 4096 but the macro name was never changed. AUDIO_BUFFER_SIZE would probably have been a better name in the first place.
Most code is not that bad though, haha. But that is still my first reaction. What if instead of slightly changing the gray color, you now want them to be blue and underlined? Or take HN for example, the username, vote buttons, and timestamp are all #828282, but have different class names. Is keeping this in sync ever a problem in Tailwind? This is only my first time looking at Tailwind, but it seems it's not really meant for "complex" apps where you'd run into these problems often?
I think for your specific example, I would use the `@apply` directive to apply certain utilities to all links.
I've used Tailwind on large, complex apps with around 50 screens (so far), and using extracted components or partials hasn't been a problem at all with keeping things in sync.
``` a { @apply text-gray-700; }
// now becomes a { @apply text-blue-500 underline; } ```
The documentation goes over this pretty well, I think.
https://tailwindcss.com/docs/extracting-components#extractin...
But gray-700 says it's a 70 % gray. Changing it to something else is akin to changing "color: #666" to "color: #444" through redefinition (JS?).
i.e. "text-gray-dark", or "text-gray-700", would have a class with a single css property:
color: #4A5568;
By default Tailwind comes with a default color palette with hand picked colors. They were hand picked by a designer, not determined through an algorithm.
https://tailwindcss.com/docs/customizing-colors#default-colo...
This sounds like a boldRedText pattern to me [1]. I get the idea of adding utility classes that inherit the base classes, but altering the definition of the "gray" class to be some other color feels wrong.
In reality I'm pretty sure that you wouldn't alter it directly either and that if you do, you would try to keep the 10 versions of it somewhat linear, or at least consistent with the use that you do of it. Theses colors are there for prototyping quickly yet still offering good looking result. Sure "color: gray" works, but look at the colors choices [1], it's much better than the default gray and offer more choice than lightgray, gray and darkgray without having to do math over #808080.
[1] https://tailwindcss.com/docs/customizing-colors/#default-col...
