@salesforce/afv-skills 1.22.0 → 1.23.0

package/skills/applying-slds/guidance/slds-development-guide.md

@@ -1,288 +0,0 @@
----
-id: slds.guidance.development
-title: SLDS Development Guide
-description: Root-level guidance for generating or optimizing SLDS-compliant code
-summary: "Comprehensive development guide covering the component selection hierarchy (LBC → Blueprints → Hooks → Custom), framework-specific patterns, styling hooks usage, linter resolution, naming conventions, and code generation best practices."
-
-artifact_type: guide
-domain: development
-topic: development
-
-content_format: structured
-complexity: intermediate
-audience: [implementer]
-
-tasks: [learn, implement, choose]
-
-refs:
-  - slds.guidance.hooks.typography
-  - slds.guidance.hooks.spacing
-  - slds.guidance.uplift
-  - slds.guidance.hooks
-  - slds.guidance.hooks.color
-  - slds.guidance.blueprints
-  - slds.guidance.utilities
-  - slds.guidance.icons
-  - slds.guidance.design
-
-tags: [development, lwc, slds, theming, styling-hooks]
-keywords: [component hierarchy, Lightning Base Components, SLDS Blueprints, styling hooks, utility classes, code generation, linter, naming conventions]
----
-
-# SLDS Development Guide
-
-Root-level guidance for AI coding agents generating or optimizing SLDS-compliant code.
-
----
-
-## What is SLDS?
-
-The **Salesforce Lightning Design System** provides:
-
-| Resource | Description |
-|----------|-------------|
-| **Lightning Base Components** | Pre-built LWC components with accessibility and theming built-in |
-| **SLDS Blueprints** | CSS/HTML patterns for any framework (React, Vue, Angular, vanilla JS) |
-| **Styling Hooks** | CSS custom properties (`--slds-g-*`) for theming |
-| **Utility Classes** | Rapid styling classes for spacing, layout, visibility |
-| **Icons** | SVG icons across action, utility, standard, custom, and doctype categories |
-
-> **Version Note:** This guide targets **SLDS v2**. Legacy `--lwc-*` tokens and `slds-*--modifier` class syntax are deprecated.
-
----
-
-## Component Selection Hierarchy
-
-**Always follow this order when building UI:**
-
-```
-┌─────────────────────────────────────────────────────────────┐
-│ 1. Lightning Base Components (LWC only)                     │
-├─────────────────────────────────────────────────────────────┤
-│ 2. SLDS Blueprints (any framework)                          │
-├─────────────────────────────────────────────────────────────┤
-│ 3. Custom with Styling Hooks                                │
-├─────────────────────────────────────────────────────────────┤
-│ 4. Custom CSS (last resort, still use hooks for values)     │
-└─────────────────────────────────────────────────────────────┘
-```
-
-### Level 1: Lightning Base Components (LWC Only)
-
-Pre-built, accessible, themed components. **Always check first for LWC projects.**
-
-| Component | Use Case |
-|-----------|----------|
-| `lightning-button` | All button actions |
-| `lightning-input` | Text, email, number, date inputs |
-| `lightning-combobox` | Dropdown selection |
-| `lightning-datatable` | Tabular data with sorting/selection |
-| `lightning-card` | Content containers |
-| `lightning-modal` | Dialog overlays |
-
-### Level 2: SLDS Blueprints
-
-HTML/CSS patterns for non-LWC frameworks or when no Lightning Base Component exists.
-
-### Level 3: Styling Hooks
-
-CSS custom properties for theming. Use when customizing appearance.
-
-```css
-.my-card {
-  background: var(--slds-g-color-surface-1);
-  padding: var(--slds-g-spacing-4);
-  border-radius: var(--slds-g-radius-border-2);
-}
-```
-
-### Level 4: Custom CSS
-
-**Only when no hook exists for the property.** See [When Hooks Don't Exist](#when-hooks-dont-exist).
-
----
-
-## Framework-Specific Patterns
-
-### LWC Layout
-
-```html
-<!-- Use lightning-layout for responsive grids -->
-<lightning-layout multiple-rows>
-  <lightning-layout-item size="12" medium-device-size="6">
-    <lightning-card title="Card 1">Content</lightning-card>
-  </lightning-layout-item>
-</lightning-layout>
-```
-
-### Non-LWC Layout (React, Vue, Angular)
-
-```html
-<!-- Use SLDS grid classes -->
-<div class="slds-grid slds-wrap slds-gutters">
-  <div class="slds-col slds-size_1-of-1 slds-medium-size_1-of-2">
-    <!-- Content -->
-  </div>
-</div>
-```
-
----
-
-## Common Patterns Quick Reference
-
-| Pattern | LWC Component | Blueprint |
-|---------|---------------|-----------|
-| Forms | `lightning-input`, `lightning-combobox` | Input, Combobox |
-| Data Tables | `lightning-datatable` | Data Tables |
-| Modals | `lightning-modal` | Modals |
-| Cards | `lightning-card` | Cards |
-
-**Form validation pattern (LWC):**
-```javascript
-handleSubmit() {
-  const allValid = [...this.template.querySelectorAll('lightning-input')]
-    .reduce((valid, input) => input.reportValidity() && valid, true);
-  if (allValid) { /* submit */ }
-}
-```
-
-**Modal pattern (LWC):**
-```javascript
-import LightningModal from 'lightning/modal';
-export default class MyModal extends LightningModal {
-  handleClose() { this.close('result'); }
-}
-```
-
----
-
-## Core Rules
-
-### Do ✅
-- Follow hierarchy: LBC → Blueprints → Styling Hooks → Custom CSS
-- Use `var(--slds-g-*)` with fallbacks for all themeable values
-- Create custom classes (e.g., `my-*`) instead of overriding `.slds-*`
-- Verify components/hooks exist before implementing
-
-### Don't ❌
-- Hard-code colors, spacing, or typography
-- Override `.slds-*` classes directly
-- Use deprecated `--lwc-*` tokens as primary values
-- Use color alone to convey meaning
-
----
-
-## When Hooks Don't Exist
-
-Not all CSS properties have styling hooks. Use this decision tree:
-
-```
-Does a styling hook exist for this property?
-├─ YES → Use the hook with fallback: var(--slds-g-*, fallback)
-├─ NO → Is there a utility class?
-│       ├─ YES → Use the utility class
-│       └─ NO → Use minimal custom CSS with:
-│               1. Custom class (my-*, c-*)
-│               2. Document why no hook/utility exists
-│               3. Use hooks for related values (e.g., colors in gradients)
-```
-
-**Properties without hooks (examples):**
-- `transform`, `transition` (use `--slds-g-timing-*` for duration only)
-- `z-index` (use SLDS utility classes when possible)
-- `cursor`
-- `overflow`
-- Complex gradients (use hook colors within gradient syntax)
-
-**Example - gradient with hook colors:**
-```css
-.my-gradient-bg {
-  /* No gradient hook exists, but use hook colors */
-  background: linear-gradient(
-    to bottom,
-    var(--slds-g-color-surface-1),
-    var(--slds-g-color-surface-2)
-  );
-}
-```
-
----
-
-## Naming Conventions
-
-### Custom Class Names
-
-Use a consistent prefix to avoid collision with SLDS:
-
-| Pattern | Use Case | Example |
-|---------|----------|---------|
-| `my-*` | General custom styling | `my-card-header` |
-| `c-*` | LWC component-specific | `c-accountList-row` |
-| `[namespace]-*` | Package/app namespace | `acme-dashboard-widget` |
-
-**Avoid:**
-- Generic names: `container`, `wrapper`, `header`
-- SLDS-like names: `custom-slds-button`
-- BEM on SLDS classes: `slds-card__custom-header`
-
-### Custom Hook Names (for app-level theming)
-
-```css
-:root {
-  /* Namespace your custom hooks */
-  --my-app-primary: var(--slds-g-color-brand-1);
-  --my-app-card-padding: var(--slds-g-spacing-4);
-}
-```
-
----
-
-## Code Generation Style
-
-When generating SLDS code, follow these patterns:
-
-### Minimal HTML + Classes
-
-```html
-<!-- Prefer utility classes over custom CSS for common patterns -->
-<div class="slds-card slds-p-around_medium slds-m-bottom_small">
-  <h2 class="slds-text-heading_medium">Title</h2>
-</div>
-```
-
-### Avoid Unnecessary JavaScript
-
-Use CSS/HTML solutions when possible:
-- `slds-hide` instead of `{if}` for simple visibility
-- `slds-is-selected` class toggling instead of complex state
-
-### Component Structure (LWC)
-
-```html
-<template>
-  <lightning-card title="Title">
-    <div class="slds-p-around_medium">
-      <!-- Content uses utility classes for spacing -->
-    </div>
-  </lightning-card>
-</template>
-```
-
-```css
-/* Component CSS only for truly custom styles */
-.my-custom-element {
-  /* Use hooks */
-  background: var(--slds-g-color-surface-2);
-}
-```
-
----
-
-## Resources
-
-| Resource | URL |
-|----------|-----|
-| SLDS Linter | https://developer.salesforce.com/docs/platform/slds-linter/guide |
-| Lightning Components | https://developer.salesforce.com/docs/component-library/overview/components |
-| SLDS Website | https://www.lightningdesignsystem.com/ |
-| Styling Hooks Index | https://www.lightningdesignsystem.com/2e1ef8501/p/591960-global-styling-hooks |

package/skills/applying-slds/guidance/styling-hooks/borders.md

@@ -1,202 +0,0 @@
----
-id: slds.guidance.hooks.borders
-title: Borders and Radius Styling Hooks
-description: Styling hooks for border width, border radius, and structural separation
-summary: "Guidance for border and radius styling hooks. Covers border width hooks for interactive boundaries, radius hooks for corner rounding, and SLDS 2 philosophy of minimal border usage."
-
-artifact_type: reference
-domain: styling-hooks
-topic: borders
-
-content_format: structured
-complexity: intermediate
-audience: [implementer]
-
-tasks: [choose, implement, troubleshoot]
-
-refs:
-  - slds.guidance.hooks.color.feedback
-  - slds.guidance.hooks.color
-  - slds.guidance.hooks
-  - slds.guidance.hooks.spacing
-  - slds.guidance.hooks.shadows
-tags: [styling-hooks, borders, radius, corners, visual-structure]
-keywords: [border width, border radius, corners, interactive boundaries, focus states, visual separation]
----
-
-# Borders and Radius Styling Hooks
-
-## Overview
-
-Borders and radius styling hooks establish structure, clarity, and visual consistency in UI interfaces. All border styling hooks are prefixed with `--slds-g-` and are followed by a border-related property name. These hooks ensure that border treatments remain consistent, themeable, and aligned with SLDS design principles.
-
-**Important:** Border and radius hooks are NOT density-aware. Unlike spacing and typography hooks, border values remain constant regardless of comfy or compact display density settings.
-
----
-
-## `--slds-g-sizing-border-*`
-
-### Description
-
-Border width hooks specify the thickness of borders. Use these hooks to define the thickness of lines that outline components, containers, and other visual elements. The scale ranges from subtle separation to strong emphasis.
-
-**Hook Pattern:** `--slds-g-sizing-border-*`
-
-### Usage
-
-####  Do
-
-- Use border width hooks to specify the pixel width of borders
-- Use border width hooks for creating visual separation between content areas without overwhelming the interface
-- Use border width hooks for indicating interactive boundaries on form elements like inputs and textareas
-- Use `--slds-g-sizing-border-1` for standard interactive elements such as buttons, inputs, and badges
-- Use `--slds-g-sizing-border-3` specifically for focus states where additional visual emphasis is needed
-- SLDS 2 favors minimal border usage — use borders purposefully for structure and meaning
-
-####  Don't
-
-- Avoid using borders decoratively around cards and containers in SLDS 2 (this is a design philosophy shift from SLDS 1)
-- Avoid hard-coded pixel values instead of border width hooks
-- Avoid inconsistent border widths across similar elements
-
-#### Context: When to Use Border Width Hooks
-
-**Use border width hooks when building:**
-
-| Component Type | Border Application | Recommended Hook |
-|----------------|-------------------|------------------|
-| Form inputs (text, textarea, combobox) | Interactive boundary | `--slds-g-sizing-border-1` |
-| Buttons | Interactive boundary | `--slds-g-sizing-border-1` |
-| Badges | Subtle outline | `--slds-g-sizing-border-1` |
-| Focus states | Emphasis ring | `--slds-g-sizing-border-3` |
-| Divider lines | Content separation | `--slds-g-sizing-border-1` |
-
-**SLDS 2 Philosophy:** Apply borders sparingly. Use consistent thickness and color. Prefer light/subtle borders for separation without overwhelming the interface.
-
-### Accessibility
-
-- Use `--slds-g-sizing-border-3` for focus states to ensure sufficient visibility for keyboard users
-- Borders must maintain minimum 3:1 contrast ratio with adjacent surfaces (40-point separation in SLDS grade system)
-- Accessibility requirements apply — consult your project's accessibility standards
-
----
-
-## `--slds-g-radius-border-*`
-
-### Description
-
-Border radius hooks manage the curvature of UI elements' corners, impacting the perceived softness or hardness of components. Use these hooks to establish consistent rounded corner styles across components. The scale provides options from subtle rounding to fully circular shapes.
-
-**Hook Patterns:**
-- `--slds-g-radius-border-*` — Numbered radius scale
-- `--slds-g-radius-border-circle` — Circular elements
-- `--slds-g-radius-border-pill` — Pill-shaped elements
-
-### Usage
-
-### Component Radius Reference
-
-| Hook | Components |
-|------|------------|
-| `--slds-g-radius-border-1` | Badges, Checkboxes |
-| `--slds-g-radius-border-2` | Text Inputs, Comboboxes, Text Areas, Tooltips |
-| `--slds-g-radius-border-3` | Menus, Popovers |
-| `--slds-g-radius-border-4` | Cards, Modals, Docked Composers |
-| `--slds-g-radius-border-circle` | Buttons, Button Icons, Avatars, Radios, Pills |
-
-### Usage
-
-####  Do
-
-- Apply consistent radius to create a cohesive design throughout the interface
-- Match radius scale to content density — smaller radius for dense content, larger for spacious elements
-
-####  Don't
-
-- Avoid mixing sharp corners (0 radius) with rounded corners within the same component — mixing these styles can create a visually jarring experience and reduce design harmony
-- Avoid hard-coded pixel or rem values instead of radius hooks
-- Avoid inconsistent radius values across similar elements
-- Avoid radius values that conflict with the brand's visual identity
-
-#### Context
-
-- Establish a consistent style for rounded corners across components such as cards, modals, and buttons
-- Create a modern, approachable aesthetic that aligns with the brand identity
-- Improve usability by subtly guiding users' focus to key interface elements
-
-### Accessibility
-
-- Rounded corners must not obscure focus indicators or reduce visible border contrast
-- Ensure focus states remain clearly visible regardless of radius value
-
----
-
-## `--slds-g-color-border-*` (Summary)
-
-### Description
-
-Border color hooks are part of the SLDS semantic color system. They define colors for borders based on semantic meaning rather than specific color values. Use these hooks to ensure border colors adapt to themes, maintain accessibility, and communicate appropriate meaning.
-
-> **For complete border color documentation**, see the Color Overview and [Feedback Hooks](ref:slds.guidance.hooks.color.feedback) for error/warning/success border patterns.
-
-**Key Border Color Hook Patterns:**
-
-- `--slds-g-color-border-*` — Neutral borders for functional structure, separation, and dividers
-- `--slds-g-color-border-accent-*` — Branded emphasis and thematic exceptions
-- `--slds-g-color-border-error-*` — Error states and destructive actions
-- `--slds-g-color-border-success-*` — Success states
-- `--slds-g-color-border-warning-*` — Warning states
-- `--slds-g-color-border-disabled-*` — Disabled elements
-- `--slds-g-color-border-inverse-*` — Dark backgrounds
-
-### Usage
-
-####  Do
-
-- Use `--slds-g-color-border-1` for decorative borders and divider lines between content
-- Use `--slds-g-color-border-2` as the standard choice for functional or interactive components
-- Use accent border colors only for branded containers or specific thematic emphasis where neutral borders are insufficient
-- Use error/warning/success border colors exclusively for communicating system feedback states
-- Use inverse border colors when placing elements on dark backgrounds
-- Border colors should reinforce semantic meaning, not serve as decoration
-
-####  Don't
-
-- Avoid using feedback border colors (error, warning, success) for general styling — reserve for actual states
-- Avoid hard-coded color values instead of border color hooks
-- Avoid border colors that don't meet contrast requirements with adjacent surfaces
-- Avoid using accent border colors for standard interactive elements where neutral hooks are the established system pattern
-- Avoid using accent border colors when the element doesn't represent a specific branded or thematic exception
-- Avoid mixing border color semantics inconsistently (e.g., error border on non-error element)
-- Avoid using inverse borders on light backgrounds (they won't be visible)
-
-#### Context
-
-- Form field borders (neutral for default, accent for focus, error for validation)
-- Card and container borders (neutral, typically subtle)
-- Status indicator borders (error, warning, success as appropriate)
-- Disabled state borders
-- Dark theme and inverse context borders
-- Divider lines between content sections
-
-### Accessibility
-
-- **Interactive elements** (buttons, inputs): Use `--slds-g-color-border-2` for higher contrast
-- **Non-interactive elements** (dividers): Use `--slds-g-color-border-1`
-- Border colors must maintain minimum 3:1 contrast with adjacent surfaces (40-point separation)
-- Color alone must not be the only indicator of state — combine with icons, text, or other cues
-- Focus borders must use high-contrast colors; pair with `--slds-g-sizing-border-3` for visibility
-
----
-
-### SLDS 2 Philosophy Reminder
-
-SLDS 2 favors minimal border usage. Before applying borders, ask:
-- Can spacing achieve the same visual separation?
-- Can shadows create the desired depth?
-- Is this a holdover from SLDS 1 patterns?
-
-Use borders purposefully for structure, interactivity indication, and state communication — not as default decoration.
-
-> **Complete Philosophy:** SLDS 2 favors minimal border usage — apply borders purposefully for structure, interactivity indication, and state communication.
-

package/skills/applying-slds/guidance/styling-hooks/color/expressive-palette-hooks.md

@@ -1,153 +0,0 @@
----
-id: slds.guidance.hooks.color.expressive-palette
-title: Expressive Palette Color Styling Hooks
-description: Extended color palettes for data visualization and expressive interfaces
-summary: "Guidance for expressive palette hooks including cool tones (cloud blue, indigo, purple, violet) and warm tones (green, orange, hot orange, red). Use for data visualization and highlighting—not standard UI."
-
-artifact_type: reference
-domain: styling-hooks
-topic: color
-subtopic: expressive
-
-content_format: structured
-complexity: advanced
-audience: [implementer]
-
-tasks: [choose, implement]
-
-refs:
-  - slds.guidance.hooks.color
-  - slds.guidance.hooks.color.accent
-  - slds.guidance.hooks.color.surface
-  - slds.guidance.hooks.color.feedback
-  - slds.guidance.hooks.color.system
-tags: [styling-hooks, color, palette, expressive, visualization, data]
-keywords: [expressive colors, data visualization, cool tones, warm tones, cloud blue, indigo, purple, orange, green]
----
-
-# Expressive Palette Color Styling Hooks
-
-> **Hook Selection:** Palette hooks provide raw color access for rare cases. For standard UI, use semantic hooks first. See [Hook Selection Hierarchy](ref:slds.guidance.hooks.color).
-
-## Overview
-
-Expressive palette color styling hooks contain an extended range of colors beyond the core system palette. These palettes are useful for displaying data, visualizations, and highlighting important areas in your user experience. The expressive palettes offer variety while maintaining cohesion with the design system's overall aesthetic.
-
----
-
-## Available Expressive Palette Categories
-
-### Cool Tone Palettes (Recommended)
-
-#### Cloud Blue
-Useful for data visualization and cool-toned accents. A calm, professional blue palette. Use intentionally to avoid confusion with info feedback colors (blue).
-
-**Hook Pattern:** `--slds-g-color-palette-cloud-blue-{grade}`
-
-#### Indigo
-A rich purple-blue palette similar to the brand color. Use intentionally to avoid disrupting button hierarchy.
-
-**Hook Pattern:** `--slds-g-color-palette-indigo-{grade}`
-
-#### Purple
-A vibrant purple palette suitable for expressive, data-heavy interfaces.
-
-**Hook Pattern:** `--slds-g-color-palette-purple-{grade}`
-
-#### Violet
-A deep, saturated purple palette that works well for accent and emphasis in visualizations.
-
-**Hook Pattern:** `--slds-g-color-palette-violet-{grade}`
-
-### Warm Tone Palettes (Use with Caution)
-
-#### Green
-Use to draw attention to important information. Use sparingly to avoid confusion with success feedback colors (teal).
-
-**Hook Pattern:** `--slds-g-color-palette-green-{grade}`
-
-#### Orange
-A warm, energetic orange palette effective for highlighting critical areas. Use sparingly to avoid confusion with warning feedback colors (yellow). 
-
-**Hook Pattern:** `--slds-g-color-palette-orange-{grade}`
-
-#### Hot Orange
-A bright, intense orange effective for maximum attention-grabbing. Reserve for truly critical states.
-
-**Hook Pattern:** `--slds-g-color-palette-hot-orange-{grade}`
-
-#### Red
-A bold red palette effective for highlighting issues or important information. Use intentionally and sparingly to avoid confusion with error feedback colors (pink).
-
-**Hook Pattern:** `--slds-g-color-palette-red-{grade}`
-
----
-
-## Usage
-
-###  Do
-- Use expressive palette colors for data visualization and charts
-- Use cool tones (cloud blue, indigo, purple, violet) as your primary choices
-- Use warm tones (orange, hot orange, red, green) strategically to draw attention
-- Combine multiple palettes in visualization scenarios when each color needs semantic meaning
-- Use expressive palettes when you need colors beyond the semantic system (accent, surface, feedback)
-- Proper contrast ratios are important when layering expressive colors over backgrounds
-- Use a consistent palette approach to unify similar data visualizations
-
-###  Don't
-- Avoid using expressive palettes as a first choice—prefer semantic colors (accent, surface, feedback) first
-- Avoid overusing warm colors like orange, red, and green—they work best for highlighting critical information
-- Avoid using indigo in ways that could confuse users with the brand color (buttons, interactive states)
-- Avoid mixing expressive palette colors with feedback colors without clear visual distinction
-- Avoid using expressive colors where neutral grays or system colors would be more appropriate
-- Avoid relying on color alone to convey meaning—pair colors with icons, labels, or patterns
-- Avoid overriding accessibility requirements for visual appeal
-
-### Context
-- Data visualization and charting
-- Complex dashboards with multiple data categories
-- Highlighting specific data points or trends
-- Geographic or hierarchical data representation
-- Educational materials and infographics
-- Scenario-based UI variations
-
-## When to Use Semantic Colors Instead
-
-Before choosing expressive palette colors, evaluate these alternatives:
-
-- **For interactive elements:** Use `--slds-g-color-accent-*` instead of expressive palettes
-- **For backgrounds and containers:** Use `--slds-g-color-surface-*` or `--slds-g-color-surface-container-*`
-- **For feedback states:** Use `--slds-g-color-error-*`, `--slds-g-color-warning-*`, or `--slds-g-color-success-*` instead of palette colors
-- **For text and icons:** Use `--slds-g-color-on-surface-*` or `--slds-g-color-on-accent-*` for proper contrast
-
-## Palette Selection Guidelines
-
-### Color Tone Recommendations
-
-**Cool Tone Priority (Recommended for most designs):**
-- Cloud Blue: Professional, calm, data-forward
-- Indigo: Similar to brand, use intentionally
-- Purple: Expressive, creative
-- Violet: Accent, emphasis
-
-**Warm Tone Use (Use when attention is needed):**
-- Green: Issues, highlights (use sparingly to distinguish from teal success)
-- Orange: Warnings, important data
-- Hot Orange: Critical warnings, maximum emphasis
-- Red: Errors, urgent information (use sparingly to distinguish from pink error state)
-
-## Accessibility
-
-- Expressive palette colors do not guarantee accessible contrast—manual verification required
-- **Contrast requirements:** 50-point separation for text (4.5:1), 40-point for UI elements (3:1)
-- **CVD warning:** Avoid Red+Green and Blue+Purple as sole differentiators
-- Use patterns, icons, or labels in addition to color to convey meaning
-- Test with colorblind simulation tools when using multiple palette colors
-- Semantic color hooks are preferred when accessibility guarantees are required
-- Accessibility requirements apply — consult your project's accessibility standards
-
-## Color Grade Scale
-
-> **Grade Scale:** SLDS uses a 0-100 grade scale where 0 is darkest and 100 is lightest. Point separations guarantee accessibility: 50-point = 4.5:1 contrast (text), 40-point = 3:1 contrast (UI).
->
-> For complete grade scale documentation and the numerical color system, see the [Color Hooks Index](ref:slds.guidance.hooks.color).