mod-base 1.0.72 → 1.0.73-beta.1

package/CHANGELOG.md

@@ -1,5 +1,8 @@
 # Changelog
 
+## 1.0.73
+- Fix hero content box-shadow not being removed in dark mode when form-in-progress is active on mobile.
+
 ## 1.0.72
 
 - Adding dark mode support for the input component when the input is active or focused.

package/package.json

@@ -1,6 +1,6 @@
 {
     "name": "mod-base",
-    "version": "1.0.72",
+    "version": "1.0.73-beta.1",
     "description": "Base Styles for S3 Sites",
     "author": "",
     "license": "ISC"

package/src/styles/templates/_dark-mode.scss

@@ -1172,11 +1172,15 @@ $contact-us-blue-light: #8498E7;
 					box-shadow: none;
 				}
 
-				&.form-in-progress {
-					.hero {
-						background-color: $background-color;
-					}
+			&.form-in-progress {
+				.hero {
+					background-color: $background-color;
 				}
+
+				.hero__content {
+					box-shadow: none;
+				}
+			}
 			}
 
 			@include breakpoint-lg {

package/docs/research-scss-to-css-vars-migration.md

@@ -1,219 +0,0 @@
-# Research Ticket: SCSS to Native CSS Variables Migration
-
-## 1. Title and goal
-
-| Field | Value |
-|-------|-------|
-| **Title** | Research: Migrate mod-base from SCSS variables to native CSS custom properties |
-| **Goal** | Produce an epic with implementable tickets and a coexistence plan so S3 sites can adopt the new system in batches without big-bang cutover |
-
-**Outcome of this research (deliverables):**
-
-1. Filled-in sections 2–3 below (findings and recommendation).
-2. Final epic title and description.
-3. Final list of child tickets (titles + short descriptions) ready for the issue tracker.
-4. Written **Proposal for new version alongside current** (coexistence strategy, recommended option, batch migration steps).
-
----
-
-## 2. Research tasks (complete during research)
-
-Use this checklist to drive the research. Record answers in this document or linked notes.
-
-### 2.1 Inventory
-
-- [ ] **Confirm and extend** the variable inventory for every file under `src/styles/**/*.scss`.
-- [ ] **Classify each variable** as:
-  - **(a)** Design token → candidate for CSS custom property.
-  - **(b)** Theme / runtime (e.g. dark mode) → candidate for CSS custom property.
-  - **(c)** Compile-time only (paths, breakpoint literals) → keep as SCSS.
-
-**Pre-filled inventory (validate and extend):**
-
-| Category | File(s) | Approx. count | Overridable | Notes |
-|----------|---------|---------------|-------------|--------|
-| **Colors** | `src/styles/base/_colors.scss` | ~213 definitions | No (`!default` only in `_variables.scss`) | Palettes (Modernize, BC, legacy), a11y |
-| **Typography / base** | `src/styles/base/_variables.scss` | 16 | Yes (`!default`) | h2/h3/body/disclaimer sizes & line-heights, font families, transition |
-| **Spacing** | `src/styles/base/_spacing.scss` | 9 | No | Tokens only (none, xxs → 2xl) |
-| **Radius** | `src/styles/base/_radius.scss` | 7 | No | xxs → xl, pill |
-| **Ratings** | `src/styles/base/_ratings.scss` | 4 | 1 with `!default` | Heights, `$rating-icons-folder` (path) |
-| **Icons** | `src/styles/icons/_*.scss` (per family) | 1 per family | Yes (`!default`) | `$icons-folder` (path only) |
-| **Dark mode** | `src/styles/templates/_dark-mode.scss` | 10 global + ~20+ mixin params | Via mixin | Theme globals set by mixin; heavy use of color vars |
-
-**Compile-time only (expected to stay SCSS):**
-
-- Breakpoint values in `src/styles/base/_breakpoints.scss` (inside mixins).
-- Asset paths: `$icons-folder`, `$rating-icons-folder` (used in `url()` / `@font-face`).
-
-**Findings (fill in):**
-
-- Additional variables discovered: _…_
-- Edge cases: _…_
-
----
-
-### 2.2 Naming convention
-
-- [ ] Propose a **naming scheme** for CSS custom properties (e.g. `--mod-color-*`, `--mod-spacing-*`, `--mod-radius-*`).
-- [ ] Confirm **no clashes** with consumer or third-party CSS.
-- [ ] Define how **theming / dark mode** maps to names (e.g. semantic `--mod-theme-surface` vs. palette `--mod-color-grey-300`).
-
-**Proposed convention (draft — finalize in research):**
-
-| Layer | Pattern | Example |
-|-------|---------|---------|
-| Palette | `--mod-color-{palette}-{step}` | `--mod-color-dark-purple-500` |
-| Semantic (optional) | `--mod-{role}` | `--mod-color-text`, `--mod-color-surface` |
-| Spacing | `--mod-spacing-{token}` | `--mod-spacing-sm` |
-| Radius | `--mod-radius-{token}` | `--mod-radius-md` |
-| Typography | `--mod-font-{role}-{prop}` | `--mod-font-body-size`, `--mod-font-body-line-height` |
-
-**Final decision (fill in):** _…_
-
----
-
-### 2.3 Consumption impact
-
-- [ ] Survey **how S3 sites override mod-base** today (e.g. redefine `!default` variables before `@import`).
-- [ ] Map each override pattern to an **equivalent with CSS vars** (e.g. set `--mod-*` on `:root`, or on a site wrapper class).
-- [ ] Identify **breaking changes** if any consumer relies on SCSS-only APIs.
-
-**Findings (fill in):**
-
-- Common override patterns: _…_
-- CSS var override pattern for consumers: _…_
-- Risks: _…_
-
----
-
-### 2.4 Dark mode
-
-- [ ] Document how `_dark-mode.scss` sets **globals** (`!global`) and applies colors today.
-- [ ] Propose how the same behavior is achieved with **CSS vars** (e.g. set `--mod-theme-*` inside `@media (prefers-color-scheme: dark)` and `body[data-color-scheme='system']`).
-- [ ] Decide whether the **mixin stays** (wrapping var assignments) or is replaced by a **static theme block**.
-
-**Findings (fill in):**
-
-- Current behavior summary: _…_
-- Proposed CSS-var-based approach: _…_
-- Opt-in contract (unchanged vs. updated): _…_
-
----
-
-### 2.5 Coexistence strategy
-
-- [ ] Compare **Option A**, **Option B**, and **Option C** (see section 3).
-- [ ] **Recommend one** with pros/cons and batch migration steps.
-
-**Recommendation (fill in after research):** _Option A / B / C — rationale: …_
-
----
-
-## 3. Coexistence options to evaluate
-
-Compare these during research and pick one for the proposal.
-
-### Option A — Dual entry point (same package)
-
-- Keep current `src/styles/base/index.scss` (SCSS vars, current compiled output) **unchanged**.
-- Add a **second entry** (e.g. `src/styles/base/index-tokens.scss` or `theme.scss`) that:
-  - Emits CSS custom properties (and/or pulls partials that use `var(--mod-*)`).
-- Consumers migrate **per site** by switching imports when ready; same package semver.
-
-| Pros | Cons |
-|------|------|
-| No forced major bump; gradual adoption | Two code paths to maintain until deprecation |
-| Same npm version for all sites | Must document which entry each site uses |
-
----
-
-### Option B — New major version (v2)
-
-- Publish **mod-base v2** with CSS vars throughout; **v1** unchanged.
-- Consumers migrate by **semver bump** when ready.
-
-| Pros | Cons |
-|------|------|
-| Clear boundary | Duplicate maintenance until v1 sunset |
-| Simple mental model (“v2 = vars”) | Coordination across many repos |
-
----
-
-### Option C — Single codebase, two build outputs
-
-- One SCSS tree compiles to **legacy** (SCSS vars in output) or **vars** (output uses `var(--mod-*)` + a theme file that sets defaults).
-- Controlled by **entry file** or build flag.
-
-| Pros | Cons |
-|------|------|
-| Single source of truth for token values | Higher implementation complexity |
-| Flexible CI | Requires build pipeline alignment |
-
----
-
-### Batch migration (example — adjust to chosen option)
-
-After research, document steps such as:
-
-1. Site adds import of new token/theme entry (or bumps to v2).
-2. Site replaces SCSS overrides with `:root { --mod-*: … }` where applicable.
-3. Site validates dark mode and critical flows.
-4. Site removes legacy overrides when fully on vars.
-
----
-
-## 4. Epic and child tickets (create after research)
-
-Use this structure when opening the epic in your tracker. Refine titles/descriptions after section 2–3 are complete.
-
-### Epic
-
-**Title:** Migrate mod-base design tokens from SCSS variables to native CSS custom properties (batch-friendly, coexistence with current version)
-
-**Description (template):**
-
-> Move design tokens (colors, spacing, radius, typography, and theme-related values) to native CSS custom properties while keeping a migration path for S3 microsites. Legacy SCSS-variable-based entry remains available until sites migrate in batches. Dark mode remains opt-in. Document naming, overrides, and deprecation.
-
----
-
-### Child tickets
-
-| # | Title | Short description |
-|---|--------|-------------------|
-| 1 | Define CSS variable naming and scope | Finalize `--mod-*` (or chosen) convention; document `:root` vs. theme class; document consumer override pattern. |
-| 2 | Implement color tokens as CSS variables | New partial or entry defining palette (and optional semantic aliases) as custom properties; keep `_colors.scss` or mirror so legacy + new paths stay aligned. |
-| 3 | Implement spacing and radius as CSS variables | Map `_spacing.scss` and `_radius.scss` tokens to `--mod-spacing-*`, `--mod-radius-*`. |
-| 4 | Implement typography / base tokens as CSS variables | Font sizes, line heights, families, transition from `_variables.scss` as CSS vars; map `!default` override story to CSS. |
-| 5 | Wire base styles to use CSS variables | Update base partials (grid, text, built-in-classes, components, etc.) to use `var(--mod-*)` **behind the new entry point**; leave legacy `index.scss` output unchanged until deprecation. |
-| 6 | Dark mode with CSS variables | Refactor opt-in dark-mode template to drive theme via CSS custom properties inside media / `data-color-scheme` selectors; preserve behavior where possible. |
-| 7 | Ratings and icons token decision | Decide which rating/icon values become CSS vars; keep path vars as SCSS; implement agreed vars. |
-| 8 | New entry point and documentation | Ship chosen coexistence approach; README + CHANGELOG: migration steps, import paths, override examples. |
-| 9 | Deprecation and rollout | Timeline for legacy entry; batch rollout plan for S3 sites; communication checklist. |
-
----
-
-## 5. Deliverables checklist (research complete when all checked)
-
-- [ ] Section 2 research tasks answered (inventory extended, naming, consumption, dark mode, coexistence).
-- [ ] Section 3: **one option recommended** with batch migration steps written out.
-- [ ] Epic title + description finalized (copy from §4 with edits).
-- [ ] Child tickets created in tracker from §4 table (with any renames from findings).
-- [ ] **Proposal for new version alongside current** attached or summarized below.
-
----
-
-## Appendix: Proposal summary (fill in after research)
-
-**Recommended coexistence approach:** _Option A / B / C_
-
-**How the new version lives alongside the current one:** _e.g. second import path in same package, or parallel v1/v2 publish_
-
-**Batch migration steps (for site teams):**
-
-1. _…_
-2. _…_
-3. _…_
-
-**Risks and mitigations:** _…_
-
-**Target timeline (optional):** _…_

package/docs/research-scss-to-css-vars-results.md

@@ -1,181 +0,0 @@
-# Research results: SCSS → native CSS variables (mod-base)
-
-**Source ticket:** [research-scss-to-css-vars-migration.md](./research-scss-to-css-vars-migration.md)  
-**Date:** 2026-03-11  
-**Scope:** Repository analysis only; consumer (S3 site) override patterns marked as *to validate with site teams*.
-
----
-
-## Executive summary
-
-- **~260** top-level SCSS variables across mod-base; **~213** are palette colors in `_colors.scss`.
-- **CSS custom properties** should back design tokens (colors, spacing, radius, typography, optional rating sizes) and **semantic theme tokens** for dark mode.
-- **Keep SCSS** for compile-time concerns: breakpoint mixins, `$icons-folder`, `$rating-icons-folder`, and any `url()` paths.
-- **Recommended coexistence:** **Option A — dual entry point** in the same package: legacy `base/index.scss` unchanged; new entry loads token definitions + styles using `var(--…)` tokens (see §2).
-- **Dark mode:** Keep **opt-in `@mixin dark-mode`**, but have the mixin (or generated blocks) **assign CSS variables** on `body[data-color-scheme='system']` under `@media (prefers-color-scheme: dark)` instead of relying on SCSS `!global` for theme values in the long term.
-
----
-
-## 1. Variable inventory (confirmed)
-
-Counts are definitions matching `^\$name:` at file top level (not mixin-local `$property`).
-
-| File | Count | Classification |
-|------|------:|----------------|
-| `src/styles/base/_colors.scss` | 213 | **(a)** Design tokens → CSS vars |
-| `src/styles/base/_variables.scss` | 16 | **(a)** Typography / base → CSS vars |
-| `src/styles/base/_spacing.scss` | 9 | **(a)** → CSS vars |
-| `src/styles/base/_radius.scss` | 7 | **(a)** → CSS vars |
-| `src/styles/base/_ratings.scss` | 4 | **(a)** star heights → CSS vars optional; **(c)** `$rating-icons-folder` → SCSS only |
-| `src/styles/icons/_basics.scss`, `_fill.scss`, `_stroke.scss`, `_stroke-md.scss` | 1 each | **(c)** `$icons-folder` → SCSS only |
-| `src/styles/templates/_dark-mode.scss` | 10 module-level + 1 constant | **(b)** Theme/runtime → CSS vars; globals today are SCSS |
-
-**`src/styles/templates/_dark-mode.scss` detail**
-
-| Item | Role |
-|------|------|
-| Module globals (`$background-color`, `$text-color`, `$theme`, …) | Set inside `@mixin dark-mode` via `!global` when mixin runs |
-| `$contact-us-blue-light` | Fixed hex; could become `--color-contact-us-blue-light` or stay SCSS |
-| `@mixin dark-mode(...)` | **34 parameters** (colors, filters, radio/checkbox, TCPA, value props, etc.) |
-| Inner `$content-selectors`, `$background-selectors` | Selector strings — remain SCSS |
-
-**Files with no top-level `$` definitions (compile-time / structural only)**
-
-- `_breakpoints.scss` — pixel literals inside mixins → **(c)** stay SCSS.
-- `_grid.scss`, `_built-in-classes.scss`, `_text.scss`, `_reset.scss`, `_flex.scss`, `_fonts.scss`, components, icon class partials, font-face partials — consume vars or emit static CSS.
-
-**Additional / edge cases**
-
-- **`_fonts.scss` mixins** use `$h2-font-size`, `$body-font-size`, etc. from `_variables.scss`. Once those exist as CSS vars, mixins can emit `font-size: var(--h2-font-size)` (with optional media-query wrappers where desktop sizes differ).
-- **`darken()` / `lighten()`** in dark-mode and `btnStyles` — cannot run on CSS vars at build time. Mitigation: pre-compute hover/dark variants as separate tokens, or use `color-mix()` / fixed semantic tokens in CSS.
-- **Duplicate color naming:** `_colors.scss` has both new scale (e.g. `$color-red-100`) and legacy (`$color-red1`). CSS vars can mirror SCSS names 1:1 (`--color-red-100`, `--color-red1`) or alias legacy to the new scale in one pass.
-
----
-
-## 2. Naming convention (recommendation)
-
-Use **direct mirrors of SCSS token names**: replace the leading `$` with `--` so designers and devs map variables without an extra prefix layer. No Bootstrap-style framework in stack, so namespace collision risk is acceptable.
-
-| Layer | Pattern | SCSS example → CSS var |
-|-------|---------|-------------------------|
-| Palette | `--color-{name}` | `$color-dark-purple-500` → `--color-dark-purple-500` |
-| Legacy palette | `--color-{legacy-id}` | `$color-red1` → `--color-red1` (or alias to new scale) |
-| A11y / BC | Same as SCSS | `$color-a11y-blue` → `--color-a11y-blue`, `$color-bc-green` → `--color-bc-green` |
-| Spacing | `--spacing-{token}` | `$spacing-sm` → `--spacing-sm` |
-| Radius | `--radius-{token}` | `$radius-md` → `--radius-md` |
-| Typography / base | Same as SCSS | `$base-font-family` → `--base-font-family`, `$h2-font-size` → `--h2-font-size`, `$body-line-height` → `--body-line-height`, `$base-transition` → `--base-transition` |
-| Semantic theme (dark) | `--theme-*` | e.g. `--theme-bg`, `--theme-text`, `--theme-accent`, `--theme-interactive` — map from current mixin params / globals |
-
-**Dark mode:** Prefer **semantic** `--theme-*` inside the dark block so one block swaps the whole theme; palette vars can stay literal for light-only pages or duplicate semantic assignment in dark.
-
-**Overrides:** Document that consumers may override any token on `:root` or a site wrapper (e.g. `.site-root { --h2-font-size: 1.5rem; }`) for theming.
-
----
-
-## 3. Consumption impact
-
-**Inferred from mod-base (validate on 2–3 S3 repos)**
-
-| Pattern today | Likely frequency | CSS var equivalent |
-|---------------|------------------|--------------------|
-| Set `$base-font-family`, `$h2-font-size`, etc. **before** importing base (because of `!default`) | Common for typography | `:root { --base-font-family: …; --h2-font-size: …; }` **after** token file or in site layer |
-| Import only colors + breakpoints | Common | Import `--color-*` definitions + keep SCSS breakpoints |
-| `@include dark-mode(...)` with site-specific params | Opt-in | Same mixin, but params map to `--theme-*` assignments |
-
-**Breaking risks**
-
-- Any consumer **reading SCSS variables in their own SCSS** after importing mod-base (e.g. `color: $color-grey-500`) must either keep importing `_colors.scss` or switch to `var(--color-grey-500)` and ensure the token stylesheet is loaded.
-- **Dual path:** Legacy import keeps `$color-*`; new import path documents “use `var(--color-*)` in site SCSS.”
-
-**Action for epic:** Spike on 1–2 production sites to list real overrides.
-
----
-
-## 4. Dark mode — current vs proposed
-
-**Current behavior**
-
-1. Site calls `@include dark-mode($accent-color: …, $background: …, …)`.
-2. Mixin sets **SCSS globals** (`$background-color`, `$text-color`, `$theme`, `$color-button`, …) with `!global`.
-3. Under `@media (prefers-color-scheme: dark)` and `body[data-color-scheme='system']`, a large ruleset applies **concrete colors** from those globals and params to many selectors (`$content-selectors`, `$background-selectors`, plus nested rules for partners, TCPA, radios, etc.).
-4. Uses **Sass color functions** (`darken`, `lighten`) on params — not compatible with raw CSS vars without `color-mix()` or pre-defined tokens.
-
-**Proposed direction**
-
-1. **Phase 1 (minimal churn):** Emit the same selectors but replace values with `var(--theme-*, …)`; mixin **sets variables** on the dark root:
-   ```scss
-   body[data-color-scheme='system'] {
-     --theme-bg: #{$background};
-     --theme-text: #{$foreground};
-     // …
-   }
-   ```
-   (Interpolation keeps compile-time hex for phase 1; hover/darken still from SCSS where params are known at compile time.)
-
-2. **Phase 2:** Move fully to CSS — define hover/active as explicit `--theme-*-hover` params or use `color-mix(in srgb, var(--theme-accent) 90%, black)`.
-
-**Opt-in contract:** Unchanged — still “import template + call mixin.” Implementation detail shifts from globals to CSS custom properties.
-
----
-
-## 5. Coexistence strategy — decision
-
-| Option | Verdict |
-|--------|---------|
-| **A — Dual entry** | **Recommended.** Same semver; sites switch import when ready; clearest batch migration. |
-| **B — v2 package** | Valid if org wants a hard cut and less dual-path maintenance; higher coordination cost. |
-| **C — Two builds** | Overlaps with A if “build” means two entry SCSS files; full flag-based dual output adds complexity without much gain over A. |
-
-**Rationale:** Option A matches “migrate by batches” without forcing every site onto a new major at once. Option B remains a future consolidation after most sites adopt the new entry.
-
----
-
-## 6. Batch migration steps (site teams)
-
-1. Add import of **new token layer** (e.g. `mod-base/.../tokens.scss` or `index-tokens.scss`) early in the bundle so `:root` (or agreed scope) defines design tokens (`--color-*`, `--spacing-*`, etc.).
-2. Optionally add **new base entry** that uses those vars in output; run visual / a11y regression.
-3. Replace SCSS `!default` overrides with **CSS** on `:root` or a wrapper class using the same names as SCSS tokens (with `--` prefix).
-4. If using dark mode: migrate to new mixin signature or ensure theme CSS vars are set; test `prefers-color-scheme` + `data-color-scheme`.
-5. Remove redundant SCSS variable overrides when no longer importing legacy-only partials.
-
----
-
-## 7. Epic and child tickets (ready for tracker)
-
-### Epic
-
-**Title:** Migrate mod-base design tokens from SCSS variables to native CSS custom properties (batch-friendly, coexistence with current version)
-
-**Description:**  
-Introduce native CSS custom properties for colors, spacing, radius, typography, and dark-mode theme tokens. Keep `src/styles/base/index.scss` behavior and output stable for existing consumers. Add a second import path for token definitions and var-based styling. Dark mode stays opt-in via mixin. Document naming, overrides, deprecation timeline, and site migration steps.
-
-### Child tickets
-
-1. **Define CSS variable naming and scope** — Adopt §2 (mirror SCSS names + `--theme-*` for dark); document `:root` vs scoped overrides.
-2. **Color tokens as CSS variables** — Generate/maintain palette + legacy + a11y + BC as `--color-*`; keep `_colors.scss` for legacy entry.
-3. **Spacing and radius as CSS variables** — `--spacing-*`, `--radius-*` from existing SCSS values.
-4. **Typography / base tokens** — Map all `_variables.scss` `!default` fields to matching `--*` names (e.g. `--base-transition`).
-5. **Wire base styles (new entry only)** — Duplicate or branch partials so new entry uses `var(--…)`; do not change legacy compiled output until deprecation.
-6. **Dark mode + CSS variables** — Refactor `@mixin dark-mode` to drive layout via `--theme-*`; address `darken`/`lighten` (tokens or `color-mix`).
-7. **Ratings / icons** — CSS vars for star heights if desired; keep `$icons-folder` / `$rating-icons-folder` as SCSS.
-8. **Entry point + documentation** — Ship second entry; README + CHANGELOG migration guide.
-9. **Deprecation + rollout** — Sunset plan for legacy path; batch checklist for S3 sites.
-
----
-
-## 8. Risks and mitigations
-
-| Risk | Mitigation |
-|------|------------|
-| Bundle size (duplicate rules) if both entries ship long-term | Target deprecation window; share token partial between entries |
-| `darken`/`lighten` vs CSS vars | Semantic tokens + `color-mix()` or precomputed steps |
-| Sites forget to load token file before var-based CSS | Document import order; optional build-time check |
-| Browser support for `color-mix` | Provide fallbacks or stay on interpolated hex in mixin for older targets |
-
----
-
-## 9. Follow-ups outside this doc
-
-- [ ] Survey 2–3 S3 repos for real mod-base override patterns.  
-- [ ] Decide browser support floor for `color-mix()` vs SCSS-only dark mode values.  
-- [ ] PM: target quarters for legacy entry deprecation.