Skip to content

Decision needed: How should consumers implement their own variables that change across mode

Design tokens > Governance (gitlab-org/gitlab-services/design.gitlab.com#1654) lays out plans and processes for design tokens to be a product of the design system, not a store of every variable or style that changes across mode.

To give dark mode the best chance of success, we need to give teams a recommendation for authoring and maintaining their own styles that might change across mode.

This recommendation should look to

  • limit the creation of tech and design debt.
  • not slow teams down for fast moving and experimental work.
  • be easy to move to design tokens later if the attributes become part of the design system.
  • be centralised and visible to the design systems team to inform our roadmap.

Proposal

For each of our consumer product, create a single place where styles can be authored, documented, and tracked.

For example. in the GitLab.com project


/* Design management styles */
/* Link to discussion: #issueissue */
/* Owned by Plan: Project management */

:root {
    --design-comment-border: var(--gl-color-neutral-800);
    --design-comment-background: var(--gl-color-purple-300);
    --design-comment-icon: var(--gl-icon-color-default);
}

:root.gl-dark {
    --design-comment-border: var(--gl-color-neutral-200);
    --design-comment-background: var(--gl-color-purple-600);
    --design-comment-icon: var(--gl-color-purple-100);
}

/* Comment styles */
/* Link to discussion: #issueissue */
/* Owned by Create: Code review */

:root {
  --timeline-entry-internal-note-background-color: var(--gl-feedback-warning-background-color);
  --timeline-entry-target-background-color : var(--gl-feedback-info-background-color);
}

:root.gl-dark {
  --timeline-entry-internal-note-background-color: #453522;
  --timeline-entry-target-background-color : #2A394E;
}

Please excuse the highlevel psudo code. I'm not sure if css var is enough for consumers or if they need some other formats.

As a design system team, our goal would be to keep this as small as possible. We can use this as an indicator for where the system isn't supporting enough usecases.

As a secondary benefit, we could also use this as a place for platform specific overrides. For example if doc's wants to use the design tokens, but keep the purple, this could be where that happens.

I'd imagine each project, such as switchboard, customers dot, design.gitlab.com and so on would have its own file like this.

Edited by Dan MH