Skip to content

Instantly share code, notes, and snippets.

@jcayzac
Last active September 19, 2024 08:49
Show Gist options
  • Save jcayzac/2388d07865936fc51de265c4ea979d5b to your computer and use it in GitHub Desktop.
Save jcayzac/2388d07865936fc51de265c4ea979d5b to your computer and use it in GitHub Desktop.
A record of decisions for frontend design

Frontend Design Decisions

# Colors

§ Specify colors in OKLCH

This lets us choose from a wider gamut of colors than sRGB, and for instance pick P3 colors.


§ Mix colors in OKLAB

Mixing colors in OKLCH yields poor results. OKLAB on the other hand gives perceptually-accurate results.


§ Derive colors using color functions

Do not specify colors directly when they can be derived from other colors. This makes it easier to maintain a consistent color scheme.


§ Do not use black page backgrounds

Although black backgrounds are OLED-friendly, the contrast between the background and other elements is too high and it's not comfortable at all, especially for reading text.

Black backgrounds can still be used for elements, e.g. code blocks, asides, quotes, etc.


§ Do not use neutral grey levels for page backgrounds

Bright text on grey background is not very comfortable to read. Add a tiny bit of color to the background to make it more comfortable, for example a dark shade of Black Pearl or Steel Blue.


§ Use vivid colors

Accent colors and other signaling colors should be more vivid than what can be represented in sRGB, when possible.


§ Do not use HDR colors for text or elements

HDR should be reserved for photography only.


# Fonts

§ Do not override the rem size

Do not set a font size. 16px is a common default, but people with bad eyesight or large screen owners often change the font size in their browser settings or the operating system settings. Do not override it.

Not setting a font size on the root element means the rem unit is always the initial rem unit.

Note

This hack is required on mobile safari.


§ Do not use web fonts for any critical content

FOUC is unavoidable, when using web fonts. Several mitigations exist, such as:

  • Using a visually-similar "safe" font first, and rely on font-display: swap to swap the actual font once it's loaded.
  • Rendering any critical text server-side with the actual font, e.g. using SVG images or SVG fonts.

These mitigations are high-effort, low-reward. The best solution is to simply use system fonts. The default fonts (ui-sans-serif, system-ui, sans-serif) look very good and consistent on all major platform.

Web fonts can still be used for below-the-fold content, such as math (e.g. KaTeX) or code (e.g. Fira Code Variable).


§ Enable programming ligatures in code blocks

These look good and are easier to read.


# Layout

§ Use initial REM units for layout and breakpoints

The initial rem unit makes it easy to reason about layout, typography and legibility much more reliably than using the reported viewport sizes, device pixel ratio, etc… as it represents a text size that is legible to the end user, whatever the device's actual physical size or its distance from the user's eyes.


§ Make prose comfortable to read

Prose text uses a slightly larger font, e.g. 1.125rem for regular paragraphs.

To ensure good readability at any size, text is never wider than 40rem, and never less than 1.25rem distant from both edges of the viewport.

Because the minimum font size a browser can render depends on the platform and user settings and thus cannot be assumed, font sizes lower than 0.75rem are never used.


§ Design for a mobile-first user experience

The default layout and navigation assume a mobile browser on a narrow device. From there, progressive enhancement for larger devices is added incrementally.


§ Use a minimal amount of breakpoints

With proper rules around elements' maximum widths and margins, the UI should be responsive enough in-between breakpoints that a very few number of actual breakpoints is required.

The CSS clamp() function can also be used to avoid excessive breakpoints.


§ Design for ultrawide displays

A supplemental breakpoint may be used for ultrawide displays, e.g. 85rem or wider, to enable more distribution of elements across the horizontal axis. For example, columns may be broken up, margins be made asymmetric, asides and replaced content moved to the side, etc.


Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment