This lets us choose from a wider gamut of colors than sRGB, and for instance pick P3 colors.
Mixing colors in OKLCH yields poor results. OKLAB on the other hand gives perceptually-accurate results.
Do not specify colors directly when they can be derived from other colors. This makes it easier to maintain a consistent color scheme.
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.
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.
Accent colors and other signaling colors should be more vivid than what can be represented in sRGB, when possible.
HDR should be reserved for photography only.
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.
FOUC is unavoidable, when using web fonts. Several mitigations exist, such as:
- Using a visually-similar "safe" font first, and rely on
font-display: swapto 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).
These look good and are easier to read.
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.
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.
The default layout and navigation assume a mobile browser on a narrow device. From there, progressive enhancement for larger devices is added incrementally.
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.
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.