Type fundamentals

Text is the primary way of communicating within GitLab. A thoughtful use of semantics and visual hierarchy can provide consistency and clarity to aid in comprehension and action.

Typefaces

GitLab Sans, based on Inter, is used for most user interface (UI) elements, with system fonts used as a back-up. GitLab Mono, based on JetBrains Mono, is used for code-related elements, for example, code blocks, branch names, commit IDs, and pipeline IDs. The fonts are available to download in this package.

The decision to use custom typefaces supports a consistent core experience for users, regardless of their device. A finer control of font size, variable weight, and other attributes like disambiguation enable greater optimization of usability and polish.

The typefaces were chosen because:

• Tall x-height that improves legibility at small sizes and readability of mixed- and lower-case text.
• Features that include character disambiguation and OpenType Font Variations.
• Balanced and complementary pairing that supports the GitLab brand expression.
• Open source.

Sans serif font stack

font-family: 'GitLab Sans', -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, 'Noto Sans',
  Ubuntu, Cantarell, 'Helvetica Neue', sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji',
  'Segoe UI Symbol', 'Noto Color Emoji';

Monospace font stack

font-family: 'GitLab Mono', 'Menlo', 'DejaVu Sans Mono', 'Liberation Mono', 'Consolas',
  'Ubuntu Mono', 'Courier New', 'andale mono', 'lucida console', monospace;

Type scales

GitLab utilizes two type scales: dynamic and fixed.

• The dynamic scale is used for any UI text within GitLab. The 500–800 options rely on the viewport width to dynamically change size between the min and max.
• The fixed scale is used for Markdown (user generated content). Sizes match the min of the dynamic scale.

Note that in implementation the variables use rem values (relative units) instead of pixels (absolute units), so that text respects browser settings for size and scale.

Contextual adjustments

By default, heading levels are mapped to the dynamic scale. However, in some cases, visual hierarchy can be established aside from semantics. For example:

• In an alert, its container already has sectioning affordances like color, spacing, and iconography. Because of this, a level 2 heading in the alert doesn't need the same emphasis as a level 2 heading for a content section elsewhere on the page.
• Similarly, in a card, the properties of the card itself indicate a section. Because of this, a level 3 heading may not require the same sectioning effect as a level 3 heading in body content.

When in doubt, use the scale by default, consider the full page context, and reference existing patterns.

Font weight

GitLab uses contrasting font weights to support visual hierarchy within the application. Generally, three weights are used by default: 400, 600, and 700.

Text color

There are a number of text colors defined in GitLab. Color choice depends on the location and purpose of the text.

Semantics

• Every page should have a level 1 (h1) heading. It can be visually hidden if the context of the page is clear for all users, but it must be present in the DOM.
• Headings should not skip levels, with the following exceptions:
  • When an alert, or other messaging component, gets inserted before the main page content. These components are designed to use a level 2 (h2) heading.
  • When a heading is used to identify a region, like navigation. Generally, a level 2 (h2) heading is used.
  • In user-generated Markdown content a user can order headings as they like. The visual appearance of a heading is the only guide provided for choosing the correct hierarchy.
• Styles correspond with semantics by default, for example, an h3 is larger and has more visual weight than an h4.