Parts for a generic design system
For the web.
Before we go make stylesheets, we should make sure all elements render as consistently as possible across major browsers. This could be accomplished by using normalize.css.
Also consider doing some sort of reset so we don’t mix up browser defaults with our own styles. This is helpful since we’re planning on building a design system, and don’t want it to mix too much with the browser’s own.
The theme variables
These should be the palette from which you compose your semantic parameters.
The theme parameters are the core variables which will have the greatest impact on appearance.
- units, from
- type families,
- line heights,
The abstract or semantic variables
These parameters should only be based on values from the ‘theme’ parameters defined above.
These are so-called derived variables, and we should aim to use them in our codebase.
We could also call these tokenized variables because they are referred to using a token. For instance
--color-warning instead of
--color-ochre. This makes it easier to replace all instances where you want a warning colour, but there might be more than one place using ochre.
You should be able to use these without tweaking, but they are definitely meant to be adjusted on projects which require it.
- font stacks,
- font sizes,
8xl, or should these be named after the typographic hierarchy?)
- horizontal spacing,
- vertical spacing,
- link, link:hover, link:active
Type and helper utility classes
these should be a combination of the typeface, the weight and style, and any additional type-related adjustments like letter-spacing, line-height, casing etc
We should style up a set of easily overridable standard form elements. This will necessarily be a combination of HTML and CSS.
These form elements should be able to be used «out of the box» with no customization, but should be easily stylable using our abstract variables.
design-system, design, pattern, typography