npm - srcdev-nuxt-components - Versions diffs - 9.3.12 → 9.4.0 - Mend

srcdev-nuxt-components 9.3.12 → 9.4.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (62) hide show

package/.claude/skills/components/cookie-consent-banner.md ADDED Viewed

@@ -0,0 +1,88 @@
+# CookieConsentBanner
+## Overview
+Fixed, non-modal banner shown while cookie consent is undecided (`useCookieConsent().status === 'unset'`). Accept/Reject buttons call `acceptAll()`/`rejectAll()` on [[composable-cookie-consent]] directly — no `v-model`, no emits to wire up. Pair with [[composable-google-analytics]] (or any other consent-gated script) which reads the same consent state.
+**Location**: `app/components/01.atoms/cookie-consent-banner/CookieConsentBanner.vue`
+**Types**: `~/types/components` — `CookieConsentBannerProps`, `CookieConsentStatus`
+---
+## Props
+| Prop | Type | Default | Notes |
+|---|---|---|---|
+| `theme` | `SemanticTheme` | `"info"` | Colours the banner's accent border and accept button via `--theme-accent`. |
+| `styleClassPassthrough` | `string \| string[]` | `[]` | Extra classes on the root element. |
+### app.config defaults
+```ts
+// Consumer's app.config.ts
+export default defineAppConfig({
+  srcdev: {
+    cookieConsentBanner: {
+      theme: "info",
+    },
+  },
+})
+```
+Resolution chain: **prop → app.config → hardcoded fallback**.
+## Slots
+| Slot | Purpose | Default |
+|---|---|---|
+| `message` | The consent message body | "This site uses cookies to understand how it's used. You can accept or reject them." |
+| `acceptLabel` | Accept button text | "Accept" |
+| `rejectLabel` | Reject button text | "Reject" |
+Per [[feedback_i18n_required]] in consuming apps, always fill these slots with `t()`-sourced copy rather than relying on the English defaults.
+## Basic usage
+Register once, in the app's default layout, alongside `DisplayToastProvider` and a call to `useGoogleAnalytics()`:
+```vue
+<!-- layouts/default.vue -->
+<script setup lang="ts">
+const { t } = useI18n();
+useGoogleAnalytics();
+</script>
+<template>
+  <div class="page-layout">
+    <slot />
+    <DisplayToastProvider position="top" alignment="right" :max-visible="3" />
+    <CookieConsentBanner>
+      <template #message>{{ t("global.cookieConsent.message") }}</template>
+      <template #acceptLabel>{{ t("global.cookieConsent.accept") }}</template>
+      <template #rejectLabel>{{ t("global.cookieConsent.reject") }}</template>
+    </CookieConsentBanner>
+  </div>
+</template>
+```
+## CSS / styling
+Public tokens (all on `.cookie-consent-banner`, `var(--cookie-consent-banner-*, fallback)` pattern):
+| Token | Default |
+|---|---|
+| `--cookie-consent-banner-z-index` | `999999` |
+| `--cookie-consent-banner-gutter` | `1.6rem` |
+| `--cookie-consent-banner-max-width` | `64rem` |
+| `--cookie-consent-banner-border-radius` | `0.8rem` |
+| `--cookie-consent-banner-border` | `0.1rem solid light-dark(var(--slate-10), var(--slate-02))` |
+| `--cookie-consent-banner-background` | `light-dark(var(--slate-00), var(--slate-10))` |
+| `--cookie-consent-banner-transition-duration` | `200ms` |
+## Notes
+- **Teleported to `<body>`** — like `DisplayToastProvider`, query it in tests via `document.querySelector(".cookie-consent-banner")`, not `wrapper.find(...)`.
+- **No focus trap / backdrop** — this is a dismiss-by-decision banner, not a modal. It collapses via a `grid-template-rows` transition (same mechanic as `DisplayPrompt`) once `status` leaves `"unset"`, rather than unmounting.
+- **Only ever one instance** — `useCookieConsent()`'s underlying state is a module-scope singleton, so mounting the banner twice in one app just duplicates the UI, it doesn't create separate consent state.
+- To let a visitor change their mind later (e.g. from a cookie-policy page), call `useCookieConsent().rejectAll()` or clear the `cookie-consent` cookie — the banner reappears since `status` returns to `"unset"` only once the cookie is gone; `rejectAll()` itself sets it to `"denied"`, which keeps the banner hidden but stops GA. Expose a dedicated "reset my choice" affordance if you want the banner itself to resurface.

package/.claude/skills/composable-cookie-consent.md ADDED Viewed

@@ -0,0 +1,78 @@
+# useCookieConsent Composable
+## Overview
+`useCookieConsent` tracks the visitor's cookie-consent decision (`unset` / `granted` / `denied`), persists it in a `cookie-consent` cookie, and wraps `@nuxt/scripts`' `useScriptTriggerConsent()` gate so any consent-dependent script (Google Analytics via [[composable-google-analytics]], or anything else added later) can be wired to it.
+**This composable ships inside the `srcdev-nuxt-components` layer** (`app/composables/useCookieConsent.ts`). Consuming apps get it via Nuxt's layer auto-import — **do not create a local copy** in the consuming app.
+## Prerequisites
+- `@nuxt/scripts` — the layer itself declares this as a dependency and registers it in its own `modules` array, so it's present in any app that extends this layer. No action needed in the consuming app, but be aware `useScriptTriggerConsent`/`useScriptGoogleAnalytics` are auto-imported from that module, not this layer.
+## Setup in the consuming app
+### 1. No import needed
+`useCookieConsent` is auto-imported by Nuxt from the layer. Use it directly in `<script setup>` or any composable without an explicit import.
+### 2. Render the banner
+Pair it with [[cookie-consent-banner]] (`CookieConsentBanner.vue`), registered once in the app's default layout — see that component's skill doc for placement and copy slots.
+## Composable reference
+Source lives at `app/composables/useCookieConsent.ts` in the layer. Shown here for reference only — do not recreate it in the consuming app.
+```ts
+const consentTrigger = useScriptTriggerConsent(); // module-scope singleton
+export function useCookieConsent() {
+  const stored = useCookie<"granted" | "denied" | null>("cookie-consent", {
+    maxAge: 60 * 60 * 24 * 365,
+    sameSite: "lax",
+    default: () => null,
+  });
+  if (stored.value === "granted" && !consentTrigger.consented.value) {
+    consentTrigger.accept();
+  }
+  const status = computed(() => stored.value ?? "unset");
+  const acceptAll = () => {
+    stored.value = "granted";
+    consentTrigger.accept();
+  };
+  const rejectAll = () => {
+    stored.value = "denied";
+    consentTrigger.revoke();
+  };
+  return { status, acceptAll, rejectAll, trigger: consentTrigger };
+}
+```
+### Key rules
+- **`useScriptTriggerConsent()` is called once at module scope**, mirroring `@nuxt/scripts`' own documented pattern — it's a single shared gate for the app's lifetime, not a fresh instance per call-site. `useCookie()` is read fresh inside the function body on every call instead, which stays SSR-request-safe (Nuxt dedupes `useCookie()` by key within a single request).
+- **`status` is the public read API.** `trigger` is exposed only so `useGoogleAnalytics` (or another consent-gated script composable) can pass it straight into `scriptOptions.trigger` — don't read/mutate `trigger` directly from app code, use `status`/`acceptAll`/`rejectAll`.
+- A prior "granted" cookie is replayed into the trigger on init, since the in-memory trigger resets on every full page load but the cookie doesn't.
+## Usage
+```ts
+const { status, acceptAll, rejectAll } = useCookieConsent();
+if (status.value === "unset") {
+  // show the banner
+}
+```
+To let a user change their mind later (e.g. a "cookie preferences" link in the footer or a cookie-policy page), call `rejectAll()` or clear the `cookie-consent` cookie to bring the banner back.
+## Notes
+- Cookie name `cookie-consent` is fixed by the layer, not configurable per app.
+- This composable only tracks the yes/no decision — it does not itself load any script. See [[composable-google-analytics]] for the GA4 integration that consumes `trigger`.

package/.claude/skills/composable-google-analytics.md ADDED Viewed

@@ -0,0 +1,87 @@
+# useGoogleAnalytics Composable
+## Overview
+`useGoogleAnalytics` loads Google Analytics 4 (`gtag.js`) via `@nuxt/scripts`' `useScriptGoogleAnalytics()`, gated behind [[composable-cookie-consent]]'s consent state and Google Consent Mode v2's `defaultConsent`. The script does not fetch, and no analytics cookie is set, until the visitor accepts via [[cookie-consent-banner]] (or your own call to `useCookieConsent().acceptAll()`).
+**This composable ships inside the `srcdev-nuxt-components` layer** (`app/composables/useGoogleAnalytics.ts`). Consuming apps get it via Nuxt's layer auto-import — **do not create a local copy** in the consuming app.
+## Prerequisites
+- `NUXT_PUBLIC_GOOGLE_ANALYTICS_ID` env var set to your GA4 measurement ID (`G-XXXXXXXXXX`).
+- `@nuxt/scripts` — already a layer dependency, registered in the layer's own `modules` array. Nothing to add in the consuming app.
+- The app's CSP (if using `nuxt-security`) must allow `https://www.googletagmanager.com` in `script-src`/`connect-src` and `https://www.google-analytics.com` in `connect-src`, or the script will be blocked once consent is granted.
+## Setup in the consuming app
+### 1. Runtime config
+```ts
+// nuxt.config.ts
+runtimeConfig: {
+  public: {
+    googleAnalytics: {
+      id: "", // NUXT_PUBLIC_GOOGLE_ANALYTICS_ID
+    },
+  },
+},
+```
+### 2. Call it once
+Call `useGoogleAnalytics()` once, near the app root — e.g. in the default layout's `<script setup>`, alongside where [[cookie-consent-banner]] is registered:
+```vue
+<script setup lang="ts">
+useGoogleAnalytics();
+</script>
+<template>
+  <div class="page-layout">
+    <slot />
+    <CookieConsentBanner />
+  </div>
+</template>
+```
+It no-ops (with a console warning) if `googleAnalytics.id` is unset — safe to call unconditionally in every environment, including local dev without a real measurement ID.
+## Composable reference
+Source lives at `app/composables/useGoogleAnalytics.ts` in the layer. Shown here for reference only — do not recreate it in the consuming app.
+```ts
+export const useGoogleAnalytics = () => {
+  const config = useRuntimeConfig();
+  const id = config.public.googleAnalytics?.id;
+  if (!id) {
+    console.warn("[useGoogleAnalytics] public.googleAnalytics.id is not configured");
+    return;
+  }
+  const { trigger } = useCookieConsent();
+  useScriptGoogleAnalytics({
+    id,
+    scriptOptions: { trigger },
+    defaultConsent: {
+      ad_storage: "denied",
+      ad_user_data: "denied",
+      ad_personalization: "denied",
+      analytics_storage: "denied",
+    },
+  });
+};
+```
+### Key rules
+- **`useRuntimeConfig()` inside the function body**, not module scope — same reasoning as `useWhatsApp` (see [[composable-whatsapp]]).
+- **`defaultConsent` is all `"denied"`** — this is what makes the script Consent Mode v2 compliant: gtag.js can load (if triggered) but won't set cookies or send identifiable pings until `useCookieConsent().acceptAll()` calls `trigger.accept()`, which flips consent to granted via `@nuxt/scripts`' own consent-update wiring.
+- Does not return anything — it's a side-effecting setup call, not a value composable. Read GA-related state (if ever needed) via `useCookieConsent()` instead.
+## Notes
+- Only loads GA4 (`gtag.js`) — no other Google tags (Ads, Tag Manager container, etc.). Extend `defaultConsent`/add a second `useScript*` call if those are needed later.
+- The measurement ID in `public` config is visible in the client bundle — expected, GA4 IDs are not secret.

package/.claude/skills/index.md CHANGED Viewed

@@ -32,6 +32,7 @@ Each skill is a single markdown file named `<area>-<task>.md`.
 ├── theming-override-default.md      — replace the entire default theme with a custom palette (set --theme-hue/--theme-chroma)
 ├── theming-partial-override.md      — override a specific colour token category (palette, buttons, inputs) without a full theme replacement
 ├── theming-form-geometry-tokens.md  — non-colour form/button/input tokens (padding, border-radius, gaps): full inventory, why partial override doesn't need duplicating the source files
+├── theming-component-token-pattern.md — standard shape for overridable component colours: public token + inline fallback, no bare var()/no private-only indirection; the three tiers (theme slots / cross-component families / component-scoped); rollout status
 ├── colour-scheme-disable.md         — disable light/dark scheme support in a consumer app
 ├── component-dynamic-slots.md        — named dynamic slots ($slots iteration) vs indexed dynamic slots (itemCount pattern)
 ├── component-local-style-override.md — styleClassPassthrough + scoped style block for per-usage visual customisation
@@ -58,6 +59,8 @@ Each skill is a single markdown file named `<area>-<task>.md`.
 ├── composable-dialog-controls.md     — useDialogControls: single-call setup with config object, openDialog/closeDialog API, confirm/cancel callbacks
 ├── composable-anchor-scroll.md       — useAnchorScroll: smooth anchor scrolling with reduced-motion support, dynamic offset, and TabNavigation integration
 ├── composable-tooltips-guide.md      — useTooltipsGuide: sequential popover guide with auto-start, dismiss-to-advance, manual controls
+├── composable-cookie-consent.md      — useCookieConsent: unset/granted/denied state, cookie persistence, wraps @nuxt/scripts' useScriptTriggerConsent
+├── composable-google-analytics.md    — useGoogleAnalytics: GA4 via @nuxt/scripts' useScriptGoogleAnalytics, Consent Mode v2 defaultConsent, gated on useCookieConsent
 └── components/
     ├── alert-content-inner.md    — AlertContentInner: shared icon/body/dismiss molecule under AlertContent + AlertMaskedContent; app.config icon map (alertContent.icons + dismissIcon) covers all consumers
     ├── accordian-core.md       — AccordianCore indexed dynamic slots (accordian-{n}-summary/icon/content), exclusive-open grouping
@@ -105,7 +108,8 @@ Each skill is a single markdown file named `<area>-<task>.md`.
     ├── expanding-panel-classic.md — ExpandingPanelClassic: grid-template-rows animation (no Baseline-2025 dependency), same API as ExpandingPanel, cross-browser animation parity trade-off
     ├── site-header.md            — SiteHeader: PageRow + SkipLinks + ResponsiveHeader composition, #branding/#secondaryNavigation slots, dual styleClassPassthrough hooks
     ├── responsive-header.md      — ResponsiveHeader: overflow-collapsing adaptive nav, measurement-pipeline gotchas (unsized icons, vw font-size drift), full CSS token API
-    └── navigation-items.md       — NavigationItems: internal overflow-panel renderer for ResponsiveHeader, complement-visibility logic, not used standalone
+    ├── navigation-items.md       — NavigationItems: internal overflow-panel renderer for ResponsiveHeader, complement-visibility logic, not used standalone
+    └── cookie-consent-banner.md  — CookieConsentBanner: fixed non-modal Accept/Reject banner driven by useCookieConsent, message/acceptLabel/rejectLabel slots, CSS token API
 ```
 ## Skill file template

package/.claude/skills/theming-component-token-pattern.md ADDED Viewed

@@ -0,0 +1,126 @@
+# Component Token Pattern — Public Token + Inline Fallback
+## Overview
+The standard shape for every overridable CSS value in a component, from now on:
+```css
+background-color: var(--{component}-{property}, {real-default-or-shared-fallback});
+```
+One name, declared inline at the point of use, with a real default right there in the component
+source. No separate "public token must be declared somewhere else or the component breaks"
+requirement, and no private `--_` indirection standing in for the actual override point.
+`ServicesCard.vue` is the reference implementation — read its `<style>` block for the shape in
+practice.
+## Why this replaced the old pattern
+Two things used to go wrong, both found while auditing `luxury-locs-by-natasha`'s theming
+overrides (2026-08-25):
+1. **Bare `var(--theme-checkbox-symbol-color)` with no fallback anywhere.** The only way for this
+   to resolve to something was a consuming app declaring it globally. When the component was later
+   refactored (buttons moved onto the shared theme-slot system) and stopped reading the token, nothing
+   signalled that to the consumer — the app's declaration became permanently dead, silently. A
+   `var()` with an undefined custom property and no fallback just resolves to the property's
+   initial value; there is no error, no warning, ever.
+2. **Tokens that were "shared" only by accident.** `InputTextCore`, `InputSelectCore`,
+   `InputNumberCore` and the checkbox button all read the exact same `--theme-input-surface`, so a
+   consumer wanting to restyle just text inputs had no way to do that without also restyling every
+   other input type. The private `--_input-text-surface: var(--theme-input-surface);` indirection
+   made this look like it had its own override point when it didn't.
+## The three tiers
+| Tier | Example | No-fallback allowed? |
+|---|---|---|
+| **1 — theme slots** | `--theme-surface`, `--theme-border`, `--theme-ring`, `--theme-text`, ... (`_theme-slots.css`) | Yes — deliberately global, small, stable set. Changing one is meant to reskin everything that shares it. |
+| **2 — cross-component families** | `--theme-input-surface`, `--theme-checkbox-symbol-surface` | No longer created new. Existing ones stay as the *fallback value* inside Tier 3 tokens, not as the thing components read directly. |
+| **3 — component-scoped** | `--input-button-primary-surface`, `--services-card-border-colour` | Never — always `var(--{component}-token, <fallback>)`. |
+Tier 1 is the one deliberate exception. Everything else gets a real component-prefixed name with
+an inline fallback, even if that fallback happens to be a Tier 1 or Tier 2 token underneath.
+## Naming convention
+`--{component-kebab-name}-{variant-if-any}-{property}[-state]`
+- `--input-button-primary-surface` / `-surface-hover` — variant + property + state
+- `--services-card-border-colour` / `-border-colour-hover` — property + state
+- Only add a `-hover`/`-focus`/`-active` suffix if that state's value actually differs from the
+  base token. If hover reuses the exact same value as base (see `InputButtonCore`'s primary text
+  colour, fixed on purpose across states), reuse the base token — don't manufacture a second name
+  for a value that never diverges.
+## Multi-level fallback chains are fine
+A component that wants to *look like* another component's default (rather than duplicating a
+raw value) chains through it:
+```css
+/* InputCopy's copy button defaults to InputButtonCore's primary look */
+--_button-bg: var(--input-copy-button-bg, var(--input-button-primary-surface, var(--theme-surface)));
+```
+Three tiers deep here: instance/global override → "look like the primary button" → the theme
+slot underneath that. Each link in the chain is a real, resolvable token — nothing depends on a
+consuming app having declared anything.
+## What this does NOT change
+- Tier 1 theme slots (`_theme-slots.css`) stay bare `var()`, no fallback, by design.
+- Geometry/typography tokens that already have real component-local defaults
+  (`--button-padding-block: 1rem;` in `06.button-geometry.css`) were never part of this problem —
+  they're declared with real values already, just not inline at the point of use. Leave them.
+## Rollout status
+- ✅ `InputButtonCore` (primary/secondary/tertiary), `InputCopy`, `PricingCard` — migrated
+  2026-08-25, see their `CONSUMER-STYLING.md` for the full token list. This pass also included a
+  deliberate visual redesign (flat borders, `color-mix()`-darkened hover, transparent resting
+  outline, separated `:focus-visible`), not just the token API change.
+- ✅ `InputCheckboxRadioCore`/`Button` — migrated 2026-08-25, see their `CONSUMER-STYLING.md`.
+  Pure token-rename pass, no visual/default changes (unlike `InputButtonCore`'s redesign above).
+  Added Storybook stories for both (`InputCheckboxRadioCore`, `InputCheckboxRadioButton`) —
+  neither had one before.
+- ✅ `InputTextCore`, `InputSelectCore`, `InputNumberCore` — migrated 2026-08-25, see their
+  `CONSUMER-STYLING.md`. `InputTextCore`/`InputSelectCore` also had this exact problem's original
+  form: a private `--_input-text-*`/`--_input-select-*` naming scheme documented as a second
+  "local override path" alongside the global tokens, added 2026-08-22 (three days before this
+  pattern was formalised) as a workaround for a global-override-not-landing report that was never
+  root-caused. That private-var-as-override-point shape is exactly what this pattern replaces —
+  renamed public with real fallbacks, old two-path docs removed. `InputNumberCore` had no
+  component-scoped tokens at all before this (bare `--theme-input-*` throughout). Added a
+  Storybook story for `InputSelectCore` (didn't have one); `InputNumberCore` still doesn't.
+  `InputTextCore`/`InputSelectCore`'s `.normal` variant also had hover and `:focus-visible` share
+  one token (literally the same rule content duplicated under two selectors) — split into
+  `--input-text-border-hover`/`--input-select-border-hover` alongside the existing `-border-focus`
+  pair, both still defaulting to `--theme-border-focus` so default rendering is unchanged, but
+  mouse and assistive-tech interaction can now be themed independently. `InputNumberCore` has no
+  hover state on its border at all (only a `:focus-visible` box-shadow toggle), so there was
+  nothing to split there.
+- ✅ `ToggleSwitchCore`, `TripleToggleSwitchCore`, `DisplayThemeSwitch` — migrated 2026-08-25, see
+  the first two's `CONSUMER-STYLING.md`. Correction to the two lines this replaces: they claimed
+  `ToggleSwitchCore` read a bare `--theme-toggle-symbol-color-*` — that token doesn't exist
+  anywhere in this codebase and never did; false memory from conflating it with the checkbox
+  fix. `ToggleSwitchCore` itself turned out to be a plain Tier 2 case (real, live tokens, just no
+  component-scoped override point) plus five confirmed-dead private locals (declared, never read
+  anywhere in the file) removed outright. The real dead-token bug was in `TripleToggleSwitchCore`
+  (and duplicated in `DisplayThemeSwitch`'s own override): `--theme-form-radio-border`,
+  `--theme-form-radio-outline`, `--theme-form-checkbox-bg` — all three declared nowhere in the
+  layer. The first two fed two further-unused private locals (removed); the third fed the
+  selected-option marker's background (real bug, narrow impact — only visible when none of the
+  component's `system`/`light`/`dark` `:has()` overrides match).
+  Second bug, found while adding the Storybook story `TripleToggleSwitchCore` never had: those
+  `:has()` selectors (and the matching `.option-icon.system/.light/.dark` classes, template-bound
+  to each option's `id`) said `"auto"`, not `"system"` — but the only known consumer,
+  `DisplayThemeSwitch`, has only ever emitted `id`/`value: "system"` (it has to; that literal
+  string is `useSettingsStore.setColourScheme`'s type and the CSS class it applies to `<html>`).
+  `"auto"` never matched anything real, so the system option's green gradient marker had never
+  actually fired — confirmed live before and after the fix. Renamed the selectors to `"system"`
+  rather than the data, since the data value is a real external contract this component's
+  presentational selectors have no business dictating. `TripleToggleSwitchCore` still hardcodes
+  three option values as CSS selectors rather than being genuinely value-agnostic — noted in its
+  `CONSUMER-STYLING.md`, left as a larger separate change.

package/app/app.config.ts CHANGED Viewed

@@ -1,4 +1,10 @@
-import type { SemanticTheme, DisplayPromptTheme, DisplayToastTheme, DisplayToastPosition, DisplayToastAlignment } from "./types/components";
+import type {
+  SemanticTheme,
+  DisplayPromptTheme,
+  DisplayToastTheme,
+  DisplayToastPosition,
+  DisplayToastAlignment,
+} from "./types/components";
 export default defineAppConfig({
   srcdev: {
@@ -40,5 +46,8 @@ export default defineAppConfig({
       theme: undefined as SemanticTheme | undefined,
       closeIcon: "bitcoin-icons:cross-filled",
     },
+    cookieConsentBanner: {
+      theme: "info" as SemanticTheme,
+    },
   },
 });

package/app/assets/styles/setup/04.elements/forms/06.button-geometry.css CHANGED Viewed

@@ -13,5 +13,14 @@
   --button-icon-gap: 1.8rem;
-  /* --button-min-height: 4rem; */
+  /* Sized so the button's TOTAL rendered height matches --input-min-height, not its content
+     box alone — .input-button-core keeps box-sizing: content-box (changing that risks shifting
+     icon-only's aspect-ratio: 1 sizing), so its own padding-block and border have to be
+     subtracted back out here, unlike --input-min-height itself which happens to need no such
+     adjustment (InputTextCore has zero padding-block and no full border in its resting state).
+     This is a floor, not a fixed height — icon-only/pill buttons or longer button-text can
+     still grow past it. Textareas are the deliberate exception to this alignment entirely. */
+  --button-min-height: calc(
+    var(--input-min-height) - (2 * var(--button-padding-block)) - (2 * var(--button-border-width))
+  );
 }

package/app/components/01.atoms/cookie-consent-banner/CookieConsentBanner.vue ADDED Viewed

@@ -0,0 +1,148 @@
+<template>
+  <Teleport to="body">
+    <div
+      class="cookie-consent-banner"
+      :class="[{ closed: status !== 'unset' }, elementClasses]"
+      :data-theme="resolved.theme"
+      data-test-id="cookie-consent-banner"
+    >
+      <div class="cookie-consent-banner-inner" role="region" :aria-label="ariaLabel">
+        <div class="cookie-consent-banner-message">
+          <slot name="message">This site uses cookies to understand how it's used. You can accept or reject them.</slot>
+        </div>
+        <div class="cookie-consent-banner-actions">
+          <button
+            type="button"
+            class="cookie-consent-banner-reject"
+            data-test-id="cookie-consent-banner-reject"
+            @click="rejectAll()"
+          >
+            <slot name="rejectLabel">Reject</slot>
+          </button>
+          <button
+            type="button"
+            class="cookie-consent-banner-accept"
+            data-test-id="cookie-consent-banner-accept"
+            @click="acceptAll()"
+          >
+            <slot name="acceptLabel">Accept</slot>
+          </button>
+        </div>
+      </div>
+    </div>
+  </Teleport>
+</template>
+<script setup lang="ts">
+import type { CookieConsentBannerProps } from "../../../types/components";
+const props = withDefaults(defineProps<CookieConsentBannerProps>(), {
+  theme: undefined,
+  styleClassPassthrough: () => [],
+});
+const appConfig = useAppConfig();
+const resolved = computed(() => {
+  const config = appConfig.srcdev?.cookieConsentBanner;
+  return {
+    theme: props.theme ?? config?.theme ?? "info",
+  } as const;
+});
+const { elementClasses } = useStyleClassPassthrough(props.styleClassPassthrough);
+const { status, acceptAll, rejectAll } = useCookieConsent();
+const ariaLabel = "Cookie consent";
+</script>
+<style lang="css">
+@layer components {
+  .cookie-consent-banner {
+    /* Matches DisplayToastProvider/DisplayDialog's z-index convention so
+       this clears ordinary page chrome (and a consumer's sticky header) but
+       still sits below an active modal dialog if one somehow overlaps. */
+    --_z-index: var(--cookie-consent-banner-z-index, 999999);
+    --_gutter: var(--cookie-consent-banner-gutter, 1.6rem);
+    --_max-width: var(--cookie-consent-banner-max-width, 64rem);
+    --_border-radius: var(--cookie-consent-banner-border-radius, 0.8rem);
+    --_border: var(--cookie-consent-banner-border, 0.1rem solid light-dark(var(--slate-10), var(--slate-02)));
+    --_background: var(--cookie-consent-banner-background, light-dark(var(--slate-00), var(--slate-10)));
+    --_transition-duration: var(--cookie-consent-banner-transition-duration, 200ms);
+    position: fixed;
+    inset-inline: var(--_gutter);
+    inset-block-end: var(--_gutter);
+    z-index: var(--_z-index);
+    margin-inline: auto;
+    max-width: var(--_max-width);
+    display: grid;
+    grid-template-rows: 1fr;
+    opacity: 1;
+    transition: all var(--_transition-duration) ease-in-out;
+    &.closed {
+      grid-template-rows: 0fr;
+      opacity: 0;
+      pointer-events: none;
+    }
+    .cookie-consent-banner-inner {
+      overflow: hidden;
+      display: flex;
+      flex-wrap: wrap;
+      align-items: center;
+      gap: 1.2rem;
+      padding: 1.6rem;
+      border-radius: var(--_border-radius);
+      border: var(--_border);
+      background-color: var(--_background);
+      &[aria-label] {
+        border-block-start: 0.2rem solid var(--theme-accent);
+      }
+    }
+    .cookie-consent-banner-message {
+      flex: 1 1 24rem;
+    }
+    .cookie-consent-banner-actions {
+      display: flex;
+      gap: 0.8rem;
+      margin-inline-start: auto;
+    }
+    .cookie-consent-banner-reject,
+    .cookie-consent-banner-accept {
+      padding: 0.8rem 1.6rem;
+      border-radius: 0.4rem;
+      border: 0.1rem solid transparent;
+      cursor: pointer;
+      transition:
+        border-color var(--_transition-duration),
+        background-color var(--_transition-duration);
+    }
+    .cookie-consent-banner-reject {
+      background-color: transparent;
+      border: 0.1rem solid light-dark(var(--slate-08), var(--slate-04));
+      &:hover,
+      &:focus-visible {
+        border-color: var(--theme-accent);
+      }
+    }
+    .cookie-consent-banner-accept {
+      background-color: var(--theme-accent);
+      color: light-dark(var(--slate-00), var(--slate-12));
+      &:hover,
+      &:focus-visible {
+        opacity: 0.9;
+      }
+    }
+  }
+}
+</style>