origam 2.18.5 → 2.18.7

package/CHANGELOG.md

@@ -18,6 +18,282 @@ This project follows [Semantic Versioning](https://semver.org).
 
 ## [Unreleased]
 
+### Fixed — #607 / #569 : 19 canaux de thème confisqués par le bloc du composant
+
+Un composant qui redéclare un token que les feuilles déclarent déjà rend ce
+canal **inatteignable par tout `IOrigamTheme` de marque**. Une custom property
+est substituée sur l'élément **qui la déclare**, et l'héritage depuis
+`[data-theme="brand-x"]` perd contre n'importe quelle déclaration directe — la
+spécificité n'entre même pas en jeu.
+
+**Le motif dominant, mesuré, n'est pas celui que les tickets décrivaient.** Sur
+les 503 déclarations scopées visant un token de feuille, **434 sont portées par
+un modificateur que le consommateur doit demander** (`&--rounded-large`,
+`&--density-compact`) : `useRounded` / `useDensity` n'émettent rien quand la
+prop est absente, donc ces règles ne confisquent rien — c'est la logique
+PROPS-FIRST du DS en train de fonctionner. La vraie cause commune est plus
+étroite : **un modificateur dont la valeur est aussi le défaut de la prop dans
+`withDefaults`** (`&--size-default` sur `size: SIZES.DEFAULT`,
+`&--density-default` sur `density: DENSITY.DEFAULT`). La classe est alors posée
+sur **chaque** instance, et la règle épingle le token à vie.
+
+Les 19 déclarations retirées résolvent toutes **exactement** la valeur de la
+feuille, chaîne de `var()` déroulée — `12px` = `var(--origam-space---3)`,
+`0.875rem` = `var(--origam-font__size---md)`, `48px` = `var(--origam-space---12)`.
+Le rendu par défaut est donc inchangé ; seul le canal redevient atteignable.
+(3 seulement sont littéralement identiques : une comparaison de chaînes ne voit
+rien, d'où le résolveur.)
+
+- `OrigamAlert`, `OrigamBtn`, `OrigamList`, `OrigamTable`, `OrigamTabs`,
+  `OrigamToolbar` — `&--density-default`
+- `OrigamBtn`, `OrigamStepper` — `&--size-default`
+- `OrigamKbd` — `&--variant-outlined` (`border-color`)
+- `OrigamChip` — second bloc `<style scoped>` entier, qui épinglait `density`
+- `OrigamTabs` — plus son bloc `<style>:root{}` (#569)
+
+**Preuve navigateur, A/B contre le commit parent** (Chromium, Histoire statique,
+thème de marque injecté par `addInitScript` avant le document). Même story, même
+liste de classes, sur `--origam-btn---density` que `.origam-btn--density-default`
+épinglait à `0px` :
+
+| | avant | après |
+|---|---|---|
+| `--origam-btn---density` | `0px` | **`24px`** |
+| hauteur calculée | 28px | **52px** |
+
+**Changed** — `--origam-btn---height` et `--origam-toolbar---height` lisent
+désormais leur échelon (`…---height-md` / `…---height-default`) depuis les
+feuilles, dans les quatre fichiers miroirs css/scss. Sans ça l'échelon restait
+sans lecteur après le retrait et `token-var-channels` rougissait ; les deux
+canaux sont vivants.
+
+**Added** — garde 29 `theme-channel-confiscation` : il ne lève que
+l'intersection « règle toujours active » × « valeur identique après résolution
+des `var()` », les deux discriminants pinnés par 13 témoins de rappel **et de
+précision**. Baseline à **37** entrées : 14 blocs `<style>:root{}` restants
+(#569) et 22 surcharges parent→enfant où le canal est **renommé** et non mort
+(`OrigamSnackbarGroup` expose `--origam-snackbar-group__item---*` depuis #436,
+la famille Media configure ses `.origam-btn` imbriqués). Livraison
+**volontairement partielle** : chacune de ces deux familles demande une
+migration de feuille composant par composant, avec risque de rendu — donc un
+arbitrage, pas un correctif.
+
+### Fixed — #829 : `geek` ET `glass` déclaraient `surface.sunken` PLUS CLAIR que `surface.default` (mode clair)
+
+`sunken` et `default` ne sont pas deux couleurs interchangeables, ce sont des
+**rôles** : `sunken` promet une surface encaissée. En mode **clair**, `geek`
+déclarait `#fbf5ff` — un ton plus clair que son `default` `#f6f0ff` — donc
+tout consommateur demandant un creux recevait un ton **surélevé**.
+
+Mesuré en navigateur réel (Chromium, `/installation`, `data-theme="geek"`,
+valeur peinte sur une sonde, pas le littéral du fichier) :
+
+| | avant | après |
+|---|---|---|
+| `surface---default` | `rgb(246, 240, 255)` L=0.891 | inchangé |
+| `surface---sunken` | `rgb(251, 245, 255)` **L=0.930** | `rgb(239, 232, 252)` **L=0.831** |
+| relation | **surélevé** ❌ | **encaissé** ✅ |
+
+**Valeur choisie par la grammaire du dépôt, pas à l'œil.** Sur les 5 autres
+thèmes clairs corrects, la « profondeur du creux » — contrast(default,
+sunken) — va de 1.0487 (`material`) à 1.1001 (`editorial`). `#efe8fc` place
+`geek` à **1.0686**, dans cette bande, conserve la teinte lavande et
+respecte l'ordre `disabled < sunken < default`.
+
+**Consommateurs** : 41 occurrences de `surface---sunken` dans 20 fichiers de
+`packages/marketing/src` (le ticket annonçait « ~30 » ; recompté). La plus
+large est `assets/css/themes/_shared.css:88`, qui alimente
+`--origam-code---background-color` : vérifié sur les **13** blocs
+`.origam-code` de `/installation`, qui passent de `rgb(251,245,255)` à
+`rgb(239,232,252)`.
+
+⛔ **La moitié « mode sombre » du ticket n'est pas reproduite, et rien n'y a
+été changé.** En mode sombre un creux se lit plus CLAIR que la page, et c'est
+déjà le cas : `sunken` L=0.009 > `default` L=0.002. Le ticket la signalait au
+motif que `sunken` y dépasse `raised` ; sur cette relation le dépôt n'est pas
+uniforme (`apple`, `cartoon`, `editorial`, `material` et `geek` font ainsi,
+seuls `ecom` et `glass` l'inversent), donc elle ne constitue pas une règle.
+
+`overlay` n'a **pas** suivi `sunken` : c'est un rôle de remplissage de
+composant (chip, avatar, kbd, btn tonal, lignes survolées — 58 occurrences),
+pas une surface encaissée, et le bloc sombre de `geek` découplait déjà les
+deux.
+
+#### `glass` — même défaut, même mode
+
+Trouvé en relevant les 7 marques pour choisir la valeur de `geek`. `glass`
+déclarait `sunken: rgba(255, 255, 255, 0.85)` — **la même valeur que son
+`overlay`**. Mesure des pixels **rendus** (capture relue via canvas, donc
+compositing réel) :
+
+| | avant | après |
+|---|---|---|
+| `default` | `rgb(233, 236, 255)` L=0.8453 | inchangé |
+| `raised` | `rgb(247, 248, 255)` L=0.9413 | inchangé |
+| `sunken` | `rgb(252, 252, 255)` **L=0.9754** | `rgb(226, 229, 249)` **L=0.7905** |
+
+⛔ **« Un verre dépoli éclaircit ce qu'il couvre » ne l'excusait pas, et c'est
+le mode SOMBRE de `glass` lui-même qui le prouve.** En sombre, l'identité place
+déjà `sunken` (blanc 4 %) ENTRE `default` et `raised` (blanc 5 %) — une
+élévation plus faible. En clair elle le plaçait AU-DELÀ de `raised` (blanc 85 %
+contre 65 %). La thèse prédirait le même sens dans les deux modes : l'identité
+se contredisait elle-même. Ce n'est pas un idiome assumé.
+
+Le correctif **garde la translucidité** sur laquelle l'identité est bâtie (les
+consommateurs de `backdrop-filter` voient toujours au travers) et remplace le
+blanc par l'encre de la palette à 3 % : `rgba(26, 21, 56, 0.03)`. Profondeur
+rendue **1.0653**, contre **1.0591** pour le mode sombre de `glass` lui-même —
+la valeur est celle que l'identité utilise déjà, et elle est dans la bande du
+dépôt. `overlay` garde le blanc dépoli : c'est un rôle de remplissage de
+composant, où « plus opaque qu'une carte » est la bonne lecture glassmorphism.
+
+Non-régression : `audit:dark-contrast` reste à **0 / 1 664**.
+
+Ajouté `packages/tests/TU/marketing/brand-surface-elevation.spec.ts` — **14 cas
+(7 marques × 2 modes), tous arbitrés**, aucun sauté : les surfaces translucides
+sont **compositées** sur le `default` de leur propre thème, avec l'opération
+`over()` de `audit/dark-contrast.audit.mjs`. Accord avec le navigateur à 3
+décimales (composite 0.9757 contre pixel rendu 0.9754). Vérifiée ROUGE sur les
+valeurs du commit parent, une fois par marque : `geek/light` puis `glass/light`.
+
+### Fixed — #818 baseline shrink : les 8 `color-contrast` du DS (8 → 0)
+
+⚠️ **Ce lot porte sur le DS lui-même, pas sur une palette marketing** : il
+part dans le paquet npm publié, un consommateur le reçoit.
+
+Recompté sur `a11y-violations.baseline.json` (aucun chiffre repris
+d'ailleurs) : **18 violations / 17 clés**, dont **8 `color-contrast`**.
+Mesurées par axe-core en navigateur réel (Playwright + Histoire statique,
+thème `origamTheme` — celui que `histoire.setup.ts` installe via
+`createOrigam()`), elles valaient **15 nœuds** en défaut. Ce ne sont pas 8
+défauts : ce sont **3 causes**.
+
+**Cause 1 — une `opacity` décorative délave le TEXTE qu'elle contient**
+(3 entrées : `OrigamNumberField`, `OrigamDatePickerField`,
+`OrigamDataTableRows`). `opacity` crée un groupe de composition qui
+s'applique à tout le sous-arbre, pas au seul trait qu'on visait.
+- `OrigamField` : le label flottant est monté DANS
+  `.origam-field__outline--notch`, dont l'`opacity: .38` ne visait que la
+  bordure. Mesuré : `#6d28d9` à .38 sur blanc → `#c8adf1`, soit **1.96:1**.
+  L'alpha passe sur `border-color` (`color-mix`) — trait identique, label à
+  pleine opacité : **7.10:1**. Appliqué aux trois variantes (`outlined`,
+  `underlined`, `filled`).
+- `OrigamDataTable` : `.origam-data-table--loading .origam-data-table-cell`
+  voilait aussi les en-têtes. Mesuré : `#6d28d9` à .5 → `#b694ec`,
+  **2.38:1**. Remonter l'opacité ne sauve pas la règle (il faudrait ≥ .82,
+  ce n'est plus un voile) : le voile épargne désormais les en-têtes, qui
+  sont la structure du tableau et non la donnée rafraîchie → **6.52:1**.
+
+**Cause 2 — un premier plan choisi sans regarder la surface réellement
+peinte** (4 entrées : `OrigamPicker`, `OrigamDatePicker`,
+`OrigamUtilities` ×2). Même famille que #777 (Card) et #514.
+- `--origam-picker-title---color` épinglait `text---secondary` (`#525252`)
+  quel que soit le fond ; sur un en-tête `bgColor="primary"` (`#7c3aed`)
+  cela donnait **1.37:1**. Le token vaut désormais `currentColor` : le
+  titre suit le premier plan de sa surface → **5.70:1** sur primary, et il
+  s'aligne visuellement sur le reste de l'en-tête.
+- `.origam--color-{intent}` lisait `---fg`, le premier plan *sur* la
+  couleur (blanc) — donc `.origam--color-primary` peignait blanc sur
+  `#fafafa`, **1.04:1** : 5 des 7 pastilles étaient littéralement
+  invisibles. Ces classes miroitent désormais `tokenForegroundForIntent()`
+  (`---fgSubtle`), c'est-à-dire **la valeur que la déclaration inline du
+  même prop `color="{intent}"` applique déjà et qui l'emporte sur la
+  classe** : la correction fait converger les deux canaux (cf. #514, « 7
+  intents sur 8 rendaient une couleur différente »). 4.81:1 à 6.81:1 selon
+  l'intention.
+- `.origam--bg-{intent}` porte désormais son premier plan apparié
+  (`---fg`), l'appariement que `useColor()` effectue déjà sur le canal
+  inline pour `bgColor`. Sans lui, du markup nu héritait de l'encre de la
+  page. Les 7 paires sont ≥ 4.5:1 (4.83 → 19.80).
+
+**Cause 3 — un couple en dur réellement insuffisant** (1 entrée :
+`OrigamChartRangeSelector`). Le bouton actif peignait blanc sur `#3b82f6`,
+**3.68:1**. `#3b82f6` n'appartient à **aucune échelle du DS** (bleu
+Tailwind) : c'était une valeur isolée, et c'est elle qui produisait la
+violation. Corriger le contraste en gardant une valeur hors échelle aurait
+réglé le symptôme en laissant la cause — l'état actif rejoint donc la
+convention que `chip--selected`, `pagination__item---active` et `stepper`
+appliquent déjà, **la paire complète** :
+`--origam-color__action--primary---bg` + `---fg` (**5.70:1**), survol
+`---bgHover` + `---fg` (**7.10:1**). Le premier plan passe du token brut
+`--origam-color---white` au sémantique `---fg` : l'état sélectionné
+devient **atteignable par le theming**, ce qu'un `#3b82f6` en dur ne serait
+jamais. Mesuré rendu : `rgb(124, 58, 237)` sur `rgb(255, 255, 255)`.
+
+Baseline : **18 → 10 violations, 17 → 10 clés, zéro `color-contrast`**.
+Aucune autre entrée touchée. Formule de contraste reprise telle quelle de
+`packages/tests/e2e/token-intent-contrast.spec.ts` (témoins rejoués :
+noir/blanc **21.00**, `#767676` **4.54**, `#777777` **4.48**).
+
+⚠️ **Rupture visuelle assumée** (les ruptures sont gratuites sur ce dépôt,
+mais celles-ci se voient) : `.origam--color-{intent}` passe du blanc à la
+couleur de l'intention ; `.origam--bg-{intent}` impose son premier plan ;
+le titre de Picker suit sa surface (sur un Picker neutre il passe du gris
+`#525252` à l'encre héritée) ; le bouton actif de `OrigamChartRangeSelector`
+passe du bleu au violet de l'identité (`action--primary`), comme tout autre
+état sélectionné du DS.
+
+### Fixed — #818 baseline shrink : structure ARIA — `aria-required-parent`/`aria-required-children`/`listitem`/`aria-prohibited-attr` (4 entrées)
+
+Recompté sur `a11y-violations.baseline.json` **après rebase sur `develop`**
+(le lot `button-name`/`scrollable-region-focusable` ci-dessous, #892, est
+passé pendant ce travail et a déjà fait bouger le compteur : 18/17 → 12/12
+avant ce commit) : **12 violations / 12 clés → 8 violations / 8 clés** avec
+ce lot. Les quatre entrées traitées ici sont la même famille de défaut vue
+sous quatre angles : un rôle ARIA exigeant un parent ou des enfants d'un
+rôle précis, et l'arbre rendu ne les fournissait pas.
+
+- **`OrigamCalendar` — `aria-required-parent`** (`role="row"` sans parent
+  `grid`/`rowgroup`/`table`/`treegrid`). La ligne d'en-tête des jours
+  (`.origam-calendar__weekdays`, `role="row"`) était un SIBLING de
+  `.origam-calendar__month-grid` (qui seul portait `role="grid"`), jamais un
+  descendant. `role="grid"` + l'`aria-label` du mois sont montés d'un cran,
+  sur `.origam-calendar__body--month` (qui enveloppe déjà les deux) ; la
+  grille interne redevient un simple conteneur de mise en page. Les lignes du
+  mois (`role="row"`, déjà correctement rattachées) ne changent pas de statut.
+- **`OrigamListGroup` — `aria-required-children`** (`<origam-list>` /
+  `role="list"` ou `"listbox"` sans AUCUN `listitem`/`option` descendant
+  lorsque le groupe est fermé — l'activateur porte délibérément aucun rôle,
+  ce n'est pas une ligne de la liste). Le groupe entier (activateur + sous-
+  liste) est désormais lui-même compté comme UNE ligne de la liste ambiante,
+  via un nouveau `groupRole` calculé sur `list.itemRole` : `listitem` en mode
+  `list` (seul rôle que `list` autorise comme enfant — vérifié empiriquement
+  contre `axe-core@4.13`, `role="group"` y est refusé), `group` en mode
+  `listbox` (rôle explicitement autorisé là). Sans liste ambiante (composant
+  autonome), aucun rôle n'est posé — un `listitem` hors de tout `list`
+  aurait simplement déplacé la violation vers `aria-required-parent`.
+  `OrigamListGroupActivator.story.vue` plaçait ses lignes hors du slot
+  `#items` (bug de story pré-existant, invisible tant que le wrapper ne
+  portait aucun rôle) ; corrigé dans le même commit — sans quoi le nouveau
+  rôle aurait cassé la ligne réelle imbriquée (`aria-required-parent` par
+  ricochet, capturé en re-testant la suite complète après le fix).
+- **`OrigamFileFieldListItem` — `listitem`** (un `<li>` isolé sans `<ul>`
+  parent). Le composant réel est toujours monté par `OrigamFileField` dans
+  un vrai `<ul>` — la violation venait uniquement de la story qui démontre
+  le sous-composant seul, enveloppé dans un `<div>`. Les six Variants de
+  `OrigamFileFieldListItem.story.vue` enveloppent désormais le `<li>` dans un
+  `<ul role="list">` (le `role="list"` explicite est une marge de sécurité
+  contre le bug WebKit qui retire la sémantique de liste implicite quand
+  `list-style: none` est appliqué — présent aussi sur le vrai
+  `OrigamFileField.vue`, non corrigé ici, aucun outil de la suite ne le
+  détecte).
+- **`OrigamChartMap` — `aria-prohibited-attr`** (`aria-label` sur un
+  `<path>` SVG sans rôle). `:role="country.hasData ? 'button' : undefined"`
+  gérait déjà le cas « pays sans donnée », mais `:aria-label` restait posé
+  sans condition — un `<path>` sans rôle a un rôle implicite `generic`, qui
+  interdit `aria-label`. `aria-label` suit désormais la même condition que
+  `role`.
+
+**Preuve** : porte a11y ciblée (`OrigamCalendar`/`OrigamListGroup`/
+`OrigamFileFieldListItem`/`OrigamChartMap`/`OrigamListGroupActivator`
+Default Variant) verte, `axe-core` réel via Playwright + Histoire statique
+(`E2E_STATIC=1`). Contrôle positif exécuté sur `OrigamListGroup` : rôle
+retiré → `aria-required-children` NOUVELLE (non baselinée) → `exit 1` réel ;
+rôle restauré → vert. Suite a11y complète (218 stories + 8 Variants
+d'intention) rejouée après le lot : **226 passed, 0 failed**. Suite unitaire
+complète : **7149 passed**. `pnpm -F origam guards` 28/28, `guards:self`
+15/15, `type-check` et `pnpm audit` propres.
+
 ### Fixed — #818 baseline shrink : `aria-allowed-attr`/`aria-prohibited-attr`/`aria-valid-attr-value` (12 des 25 entrées)
 
 Recompté sur `a11y-violations.baseline.json` (pas repris d'un chiffre cité