Imagine you want to add a new blue section to a page. Ideally you want all the components you built to adapt to the new theme automatically, without having to change anything
The Laika Theming System is a proposal to do exactly that.
Overview
Theming
Theming is the process of pairing colors to pleasant combinations.
For example, it allows us to apply palette colors to light or dark sections.
Palette and purpose
When it comes to theming, there are two relevant concepts: Palette tokens and purpose tokens. Theming is the process that connects them.
The palette-tokens include actual color values but without information on how to use them.
Palette token example
Purpose-tokens could be described as agnostic, or color blind.
They do not hold any information about the actual color value, but
instead about how the color should be used. An example token name is
color-font-title-main.
Purpose token example
The process where purpose tokens are being assigned palette tokens (actual colors) is called theming.
Theming example
Theming combines palette-tokens and purpose-tokens, generating themes. Themes can be created with variations using our palette, to give us flexibility to colorize components in many different ways.
Components only ever use purpose-tokens. The individual component is therefore detached from actual colors, and this gives us powerful scalability.
Problems with this approach
It would be possible to stop here. For every theme, we would just create a large map of tokens. This is problematic though, for two reasons:
1. Sections and surfaces both create context
One of our early observations was that within the same theme, typography might use different colors depending on whether it is placed directly on the section, or on a surface like a card.
The text within the card uses different colors, even though it is part of the same theme as the text in the section.
We say that both section and surface create context, because they independently influence the color of typography nested within them.
Ideally, the titles themselves would react automatically to the
context that they are being placed within, so that we still only need
one purpose token ($color-font-title-main) to control
their color.
2. Redundancies
Another observation was that between different themes (and contexts), there are a lot of redundancies. For example, while a blue section and black section might have different background colors, the typography and buttons used on them might be identical.
Both themes still have some overlap - they use identical typography and button colors.
Theme classes
To account for the problem of redundancies, we decided to split themes into 4 distinct classes:
Sections
Surfaces
Typography
Buttons
Essentially we are dividing the total pool of purpose tokens into smaller, reusable groups.
A list of fictional tokens
Theme classes group tokens into different categories
Theme packages
Per group we can then define several theme packages. Every theme package represents an actual theme map.
Two package examples for the section class could be section-white and section-black. Packages of the same class can then be used interchangebly.
Schema
Every package of a given class (eg section-black of the section class) would then need to specify all required token listed by that class' schema.
For example, every section package implements the exact same purpose tokens, just possibly mapping to different purpose tokens.
6 configurations per theme
Considering that both section and surface create context (and therefore influence the color of Typography and Buttons nested within), this leaves us with a total of 6 different configurations per theme:
Section
Section typography
Section buttons
Surface
Surface typography
Surface buttons
Note that although typography can be configured independently for section and surface contexts, the pool of available theme packages for both is identical.
Class connections
Class connections specify possible connections between theme classes. The connections define compatible packages.
Examples
Let's say we want to use a white section theme, with a light gray surface color:
The combination of theme packages to achieve that might look something like this. Note that for this example, both section and surface have identical context - they use the same font and button package.
To the contrary, here is an example theme starting with the same white section package, but a blue surface package:
Note how now section and surface use different contexts. While text that is placed directly on the section is dark, the text placed on the surface has to be light in order to achieve enough contrast.
Elaboration
Traditionally, adding a new theme (for example a blue theme) to your website meant that you had to add blue theme support to every single component on the website. If that wasn't possible because of limited resources, you had to restrict what components might be used in that new blue section you wanted to create. Neither solution was very satisfying.
With the growing browser support of CSS custom properties, it became possible to dynamically change the values of your color variables (purpose tokens). With this approach, many websites now offered 2 different themes: dark and light.
But still, current systems usually don't go further than that. What if you want to use a variety of differently themed sections on the same page, with all components adapting automatically?
The Laika Theming System attempts to support a much wider range of themes than just light and dark - allowing to add as many themes as desired in a scalable fashion.
A current weakness is being limited to 2 layers only (section and surface). What about for example a pop up being displayed on top of a card? This would be a surface on top of another surface. Further versions of the theming system might attempt to solve this problem.