# Naming > The following set of principles guide our team when naming things in the system. These principles are loosely based on the guidelines from Brad Frost’s CSS Architecture for Design Systems. ### Make it modular Modularity reduces complexity and improves our system’s reusability. This applies to our naming as well. Different parts of the design system need to be clearly separated. ### Keep it consistent Consistency enhances clarity and makes our design system more predictable and easy to use. We use the same language and naming wherever possible. ### Prioritize legibility Developers and designers should be able to understand the system at a glance and understand the structure and purpose of any given part. ### Avoid conflicts It’s critical to ensure that the design system’s naming doesn’t conflict with other libraries and systems. This is accomplished by the provided namespacing. ### Clarity over succinctness The system may seem verbose, but it delivers clarity and resilience in exchange. Keeping naming legible and scalable sometimes means sacrificing a shorter syntax. --- ### Semantic colors Semantic colors carry meaning and imply how and where they should be used. Each semantic color name contains a role, a modifier, and a theme mode. This accommodates needs such as state, interactivity, and emphasis for different Kesko brands. For example, a component may require color variations for `:hover` and `:focus` states. - **Naming structure:** `k-color-{role}-{modifier}-{theme}` - **Role:** Each color has a specific role in the Kesko Design System such as `accent`, `border`, `text`, `status`, or `bg`. - **Modifier:** Modifiers are optional and may include variations such as `weak`, `strong`, `active`, `hover`, or `success`. - **Theme:** User interface theme modes, such as `light` or `dark`. - **Usage example:** - `k-color-text-accent` - `k-color-text-on-accent` - `k-color-bg-accent` - `k-color-bg-highlight` - `k-color-status-error` - `k-color-status-info` ### Primitive colors For the Kesko primitive palette, we use numeric scales (`100`, `200`, `300`, ..). This provides clear ordering and makes it easy to add values between the existing tokens when necessary. - **Naming structure:** - `k-color-{name}-{variant}` - **Valid characters:** Allowed characters include lowercase ASCII letters (`a-z`) and hyphens (`-`). Do not use uppercase characters, symbols, underscores (`_`), dots (`.`), or digits (`0-9`). - **Usage example:** - `k-color-orange-100` - `k-color-orange-200` - `k-color-red-100` - `k-color-red-200` - `k-color-blue-100` - `k-color-blue-200` - **Categories:** - Orange - Beige - Blue - Green - Purple - Red - Teal - Yellow - Neutral - **Tints and shades:** - `100` - `200` - `300` - `400` - `500` - `600` - `700` - `800` - `900` - `1000` - `1100` - `1200` --- ## Components Kesko’s component library ship as React components in addition to matching Custom Elements and CSS classes so that consumers without React can reach the same visual styling through `@kesko/css`. ### React components - **Format:** `PascalCase`, for example `Button`, `Spinner`, `Stack`, `VisuallyHidden`. - **Noun rather than verb:** Components are not actions, they are conceptually “things.” Prefer `Animation` over `Animating`. - **Meaningful:** Not over specific, not overly abstract. - **Short:** Maximum of 2 words. Prefer 1 word when possible. - **Pronounceable:** We want to be able to talk about them. - **Usage examples:** - `