Use semantic color roles to establish hierarchy, communicate actions, and preserve meaning across themes.
Color helps people recognize relationships and understand what they can do. In Liquidify, begin with the role a color serves, then use the corresponding token or component option. Keep those decisions consistent across the interface.
Separate the color of content from the color of actions. Primary text needs a clear relationship to its surface; secondary text supports it. An accent can identify an action without becoming the background for every section.
| Role | Liquidify token or component option |
|---|---|
| Primary foreground | --lq-color-fg-primary |
| Secondary content surface | --lq-color-bg-secondary |
| Interactive accent | --lq-color-accent |
| Boundary between regions | --lq-color-separator |
| Destructive action | A supported component's destructive role |
These identifiers describe intent. The shipped base bg-*, fg-*, and accent aliases have fixed default values; changing the color scheme does not rewrite them. Theme-aware component styles use explicit light and dark token pairs. Participating contrast scopes can substitute increased-contrast values. Consult Colors for the implementation vocabulary and the distinction between fixed aliases and theme-aware pairs.
The swatches show the base aliases, so their fills remain the same in both appearances. The diagram changes its surrounding surface and label colors explicitly. Use the theme-aware pairs below when an application surface needs to adapt.
Prefer the component's public option when one exists. For example, Button exposes a destructive role and a tint choice, but their rendered effect depends on the variant. See Button guidance before combining them. Use a token in a page-owned CSS class when styling an application surface.
.account-summary {
color: light-dark(
var(--lq-color-label-primary-light),
var(--lq-color-label-primary-dark)
);
background: light-dark(
var(--lq-color-bg-secondary),
var(--lq-color-system-gray-6-default-dark)
);
}This application-owned surface explicitly pairs a light secondary background with a dark gray background and matching label colors. Load @liquidify/react/styles.css and place the surface inside a Theme scope, or set the document color scheme explicitly. light-dark() follows the effective CSS color scheme; a dark-looking background alone does not select the dark values. Review any boundaries or emphasis added to it in both appearances.
A semantic token can be reused wherever the same meaning applies. Avoid replacing it with a sampled color from a screenshot: that value describes only one appearance under one set of conditions.
Use a prominent treatment for the action that needs attention. Keep surrounding controls visually quieter so the main action remains recognizable.
A destructive action needs a clear label as well as an appropriate role. Color alone does not explain what will be removed, whether the operation can be undone, or what happens next. Describe those consequences where people make the decision.
Liquidify's Theme provider sets the CSS color scheme for its subtree. Use type="light" or type="dark" for an explicit appearance and type="system" to follow the browser preference; the provider defaults to light when its type is omitted.
IncreaseContrast level="on" passes a setting to surfaces that use Liquidify's glass engine. Those surfaces select increased-contrast semantic colors. The provider does not render a CSS wrapper, so it does not by itself change arbitrary HTML children. The shipped CSS also responds to prefers-contrast: more; level="off" does not override that browser preference. Contrast changes affect color, not the material's blur or refraction. Review application-owned surfaces separately.
This example directly imports @liquidify/glass; make that package an explicit dependency of the application as well as @liquidify/react.
import type { ReactNode } from "react"
import { IncreaseContrast, Theme } from "@liquidify/glass"
import "@liquidify/react/styles.css"
export function ContrastScope({ children }: { children: ReactNode }) {
return (
<Theme type="system">
<IncreaseContrast level="on">{children}</IncreaseContrast>
</Theme>
)
}

Review the same task in both themes. Check foregrounds, boundaries, icons, and selected states together, including application-owned surfaces outside the contrast provider's effect. Supplying a theme-aware token does not prove that every combination of content and surface has sufficient contrast.
A glass surface changes the relationship between foreground content and the background behind it. Review it over the backgrounds people will actually encounter, including images and dense content during scrolling.
If a label becomes difficult to read, reconsider the surface treatment or the amount of detail behind it. Do not keep increasing saturation as a substitute for a clear foreground-background relationship.
Use Status indicators to distinguish a persistent condition from a temporary outcome message. Pair status colors with readable text, an appropriate icon, or another explicit indicator. Ensure that selection and errors remain understandable when colors are difficult to distinguish.
For charts, distinguish interface colors from series encodings. Liquidify's semantic colors are not a validated chart palette. Use Color palettes to plan consistent series identities, redundant cues, and theme review.
Review the rendered interface with the accessibility requirements of the product. The guidance here describes design decisions; it does not certify a particular palette or application.