Add color tokens to tailwind config file

We are in the progress of building a component library, and TailwindCSS is what we use for component theming.

The config file has been created, and further configurations will be added in the future. For now, we need to add color tokens to the file, in the colors object.

Link to the config file: https://github.com/freeCodeCamp/freeCodeCamp/blob/main/tools/ui-components/tailwind.config.js#L5

Colors to be added:

• Layout colors: https://design-style-guide.freecodecamp.org/#layout-colors
• Accent colors: https://design-style-guide.freecodecamp.org/#accent-colors
• Any colors in here that the design style guide does not have: https://github.com/freeCodeCamp/freeCodeCamp/blob/main/client/src/components/layouts/variables.css

Convention:

• Token names are in camelCase
• Tokens for dark theme colors are suffixed with the word dark. Tokens for light theme can stay as is. For example: primaryColor and primaryColorDark, secondaryColor and secondaryColorDark, etc.
• Tokens are sorted alphabetically

[huyenltnguyen]

Do you see gray-foreground-primary, gray-background-primary,… as names for color variables (those in colors.css), or for the semantic colors (those in the config file)?

My take on this is that, semantic colors won’t have anything that refers to the actual color they use. An example can be the Alert component. Bootstrap and Material UI call the variants success, info, warning, … instead of green, blue, yellow.

So I guess gray-foreground-primary would be a color in the variable file, and it is mapped to, say, default-foreground-primary in the config file. Then red-foreground-primary would be something like danger-foreground-primary, etc.

With the colors are already added to colors.css, our next step is to map them to semantic tokens in the config file. Since the naming of colors in both layers will need to be adjusted again once the design style guide gets new updates, are you okay with me coming up with some temporary tokens for now?

Though I think I should do it incrementally as I build the components, rather than assuming what each color means right now and add their tokens in bulk.

[huyenltnguyen]

@ahmadabdolsaheb hope you could weigh in on this. To sum up the entire discussion, there are two approaches we can take regarding dark theme support:

• The currently approach in /learn in which we use light theme styles as the default, then override them with the .night selector for dark mode.
  • Pros:
    • Consistent with the implementation of /learn, thus easier to get familiar
    • Less configurations/changes needed
  • Cons:
    • This can be considered anti-pattern as Tailwind is a utility-first library
• The Tailwind approach in which we split the styles smaller into atomic CSS and assign their class names to our components (also see https://github.com/freeCodeCamp/freeCodeCamp/issues/42186#issuecomment-856726960)
  • 
  • Pros:
    • Get the benefits of the library by following its pattern (I’m not sure 100% what the benefits are except for the CSS purging)
  • Cons:
    • The introduction of the dark class as Tailwind uses it as the theme identifier
    • The HTML may be bloated with all sort of class names. For example: bg-colorA, focus:bg-colorB, hover:bg-colorC, dark:bg-colorD, dark:focus:bg-colorE,… )

---

I think approach (1) is more viable. This is not saying that we shouldn’t use Tailwind classes at all, as I reckon it will be very useful and convenient when it comes to handling layout. But for dark theme styling specifically, I think we are better off with our current way of writing CSS.