Sign in or sign up before continuing. Don't have an account yet? Register now to get started.
Register now

Semantic design token overrides in GitLab

Recap: we are adding design tokens to implement a dark mode without teams needing to design and build twice. By assigning the design token that captures the meaning of the thing, the design system can maintain how that thing looks across multiple modes and modifiers.

Problem

We've observed instances where consumers are changing the semantic meaning of elements based on color mode to force a different style. For example:

.class {
  background: background.color.subtle;

  & .gl-dark {
    background: background.color.section;
  }
}

I feel uncomfortable with this approach because it changes the meaning and purpose of an element based on color mode. It makes maintaining and understanding these styles more difficult.

Examples

  • https://gitlab.com/gitlab-org/gitlab/-/blob/55a84668417793157449600910f3d8250bf28f67/app/assets/stylesheets/framework/tables.scss#L45
  • https://gitlab.com/gitlab-org/gitlab/-/blob/f42ff1e3f5d0329b4575aa5dc33fb4cbcc28faac/app/assets/stylesheets/page_bundles/pipeline.scss#L235
  • https://gitlab.com/gitlab-org/gitlab/-/blob/67ec1fc57b538e0841fcd23a339fe40869a198fc/app/assets/stylesheets/page_bundles/notes/\_diff_comments.scss#L255

Questions for discussion

  1. Am I the only one who thinks we shouldn't do this?
  2. Should we implement linting rules to flag such misuses?
  3. How can we better educate teams about the proper use of design tokens?
Edited Oct 17, 2024 by Dan MH
Assignee Loading
Time tracking Loading