Themes

In order to understand what a theme is, we need to understand first that the definition of colors, sizes, shapes... is an intrinsic part of a design system. Since these parameters are essential for guaranteeing accessibility and a good user experience, having the ability of changing them, might go frontally against the intentions of the design system.

This is precisely what themes are, just custom defined objects that allow users to override fundamental decisions of Halstack Design System. They are a way of escaping the restrictions imposed by the Design System, and using themes could result in applications not being compliant with the Halstack guidelines, or even introducing many different types of accessibility issues if not used carefully.

Typically, you would create a Halstack Design System application, and after that, only if there is a white-labeling requirement, we would apply a theme on top of the base application. This, and only this, is the whole purpose of using themes.

As explained in the previous section, themes are basically a list of properties that allow you to override fundamental decisions of the design system. Based on the amount of decisions that can be overridden, Halstack Design System has two different theming strategies:

Tokens in the second column, which names are in bold, will have the value that results from applying the transformation indicated in brackets to the 'Theme input'. (If nothing, they will have the same value as the 'Theme input').

Theme inputs value must be hexadecimal without alpha channel.