Foundation

Color Palette

We use a minimal palette to ensure meaningful color application for emphasis, tone, visual cues, and cohesive layouts. Our color combinations follow the WCAG 2.1 AA guidelines for minimum contrast ratios.

This label shows accessible and applicable text and background combinations.

Primary Palette

We use Periwinkle for interactive elements (buttons, icons, and links), Asphalt for header backgrounds in immersive views, and Snow for content area backgrounds.

Periwinkle #575195

Asphalt #353B48

Snow #FAFAFA

Neutral Palette

We use Charcoal for regular text, Gray for disabled text and disabled interactive elements (buttons, icons), and Pale Lilac Gray for table header backgrounds. We use White for text on dark backgrounds as well as card, modal, and panel backgrounds.

Charcoal #4A4A4A

Gray #6B6B6B

Pale Lilac Gray #E9E7EC

White #FFFFFF

Accent Palette

We use the accent palette for data visualization. Salmon indicates a negative connotation and Cyan indicates a positive connotation. Sleet, Midnight, and Lavender all have a neutral connotation. This palette is only for use on a white (#FFFFFF) background, and not for use as text or backgrounds.

Salmon #FF5F4E

Cyan #19A1A9

Sleet #7F97AD

Midnight #2E1B46

Lavender #8B86CA

Functional Palette

We use Forest for success messages and Firetruck for error messages and delete buttons.

Forest #088000

Firetruck #C0392B

In a compound component like Select or Action Menu, child components are rendered in the parent's slot element, part of its shadow DOM tree. Slots essentially serve as a placeholder for markup that you the developer define in the light DOM tree, like <wm-menuitem>, <wm-option>, text content, or other child elements.

The browser distributes the child elements defined in the light DOM into the shadow DOM of the parent. The result is a flattened DOM tree—a merger of the the light DOM and the shadow DOM. This flattened tree is what you see in DevTools and what is rendered on the page.

With the standard implementation of the component, dynamically updating the child items will throw an error. Elm's efficient diffing of the DOM will register that only the child items have changed and try to update them, but the component has already been composed.

Rendering the component in a Keyed node and giving it a dynamic id will cause the entire component, rather than just the child items, to render anew, avoiding the error.