origam 2.18.1 → 2.18.2

package/CHANGELOG.md

@@ -177,10 +177,52 @@ conclure qu'elle ne l'est plus par défaut.
 
   Rejoué sur 30 composants × 8 identités × 2 modes × 2 portées (racine ET
   sous-arbre), soit **1 664 instances**, Chromium, contrôles positif et négatif
-  verts : **189 → 11 violations AA**, dont sombre **184 → 6** et clair
-  **5 → 5** (aucune régression). Les 11 restantes appartiennent toutes aux
-  palettes de marque de `packages/marketing`, aucune au DS. Harnais :
-  `pnpm -F @origam/tests audit:dark-contrast`.
+  verts : **185 → 7 violations AA**, dont sombre **182 → 4** et clair
+  **3 → 3** (aucune régression). Les 7 restantes appartiennent toutes aux
+  palettes de marque de `packages/marketing`, aucune au DS, et aucune ne
+  descend sous 2:1. Harnais : `pnpm -F @origam/tests audit:dark-contrast`.
+
+  ⚠️ **Ces bornes ont d'abord été publiées à `189 → 11`, et les deux étaient
+  fausses de 4.** Le parseur de couleurs du harnais ne connaissait pas
+  `color(srgb …)`, que la palette `apple` émet : le fond translucide du
+  tooltip était pris pour « pas de fond », la remontée d'ancêtres sautait
+  jusqu'à la surface opaque et rapportait du noir sur noir à 1.00 — quatre
+  violations **fabriquées**, présentes des DEUX côtés de la mesure. Le
+  **delta de 178 n'a jamais été faux** ; seules les bornes l'étaient. Détail
+  et garde de non-récidive plus bas.
+
+- **#871 — le harnais de contraste ne savait pas lire `color(srgb …)`, et
+  FABRIQUAIT donc des violations.** Son `parse()` ne reconnaissait que
+  `rgb()` / `rgba()`. Un fond qu'il ne sait pas lire n'est pas « ignoré » : il
+  est traité comme **non peint**, la remontée d'ancêtres saute l'élément et
+  composite contre une couche qui n'est pas celle que voit l'œil. Sur le
+  tooltip `apple` — `color(srgb 0.898 0.898 0.906 / 0.94)` sur une surface
+  noire — cela donnait du noir sur noir à **1.00** là où le rendu réel est
+  ~`rgb(215,215,217)` sur noir. 4 instances (root + sous-arbre × clair +
+  sombre), des deux côtés de la mesure.
+
+  `parse()` reconnaît désormais `color(srgb r g b [/ a])`, avec **la même
+  expression régulière que `srgbToRgb` dans `contrast.directive.ts`** — la
+  vraie directive gérait déjà cette forme, et son commentaire le disait :
+  *« design tokens resolve to exactly this form in several themes »*.
+
+  ⛔ **Un quatrième contrôle, parce que le correctif ponctuel ne suffit pas.**
+  Le harnais échoue maintenant (`$? = 1`) dès qu'une chaîne de couleur non
+  vide lui est illisible, en listant les formes rencontrées. Sans lui, la
+  prochaine syntaxe (`oklch()`, `lab()`, résidu de `color-mix()`) décalerait
+  le chiffre en silence exactement de la même façon. Contrôle positif du
+  garde lui-même : branche `srgb` désactivée → `$? = 1`, 8 formes listées, et
+  le compte réaffiche l'ancien **11** ; branche active → `$? = 0`, tout lu,
+  **7**.
+
+  ⚠️ #871 listait déjà ce risque sous « non vérifié » — *« les couleurs
+  `oklch()` / `color(srgb …)` — aucun token actuel n'en emploie, mais un futur
+  thème invaliderait l'instrumentation »*. Un thème le faisait **déjà** au
+  moment où la phrase a été écrite. Écart signalé en marge de la **PR #882**
+  (#869, `v-contrast`) par l'agent qui rejouait ce harnais avec la vraie
+  directive au lieu du stub ; reproduit, remesuré et corrigé ici. Aucun ticket
+  propre n'a été ouvert : le défaut est dans l'instrumentation de #871, donc
+  il se règle sous #871.
 
 - **#871 — `system-bar` et `tooltip` illisibles en sombre.** Les deux peignent
   une surface sombre dans les DEUX modes (`neutral---700` / `neutral---800`)
@@ -220,6 +262,43 @@ conclure qu'elle ne l'est plus par défaut.
   chacun. L'affirmation décrivait un état antérieur à #794 que plus rien ne
   remesurait.
 
+### Fixed
+
+- **#371 (point 3) — le sélecteur « Items per page » du footer
+  DataTable n'avait aucun nom accessible**, déjà corrigé par `3f063d727`
+  (2026-09-10) — ce commit **citait #371 sans le fermer**, sixième
+  occurrence cette semaine du même motif (cf. #570, #682, #537, #371
+  point 1, #371 point 2/ADR-005). Re-mesuré ici avant tout travail sur les
+  points restants du ticket : le `<span>` visible est désormais associé au
+  `<origam-select>` via `aria-labelledby`, et la suite unitaire complète
+  reste verte (7120/7120) — aucun code de production retouché sur ce point,
+  seule la mesure manquait au tableau.
+
+- **`<OrigamDataTableRow>` ne fuit plus `index` / `mobile` en attributs DOM**
+  (#371, point 4). `itemSlotProps()` (`OrigamDataTableRows.vue`) construisait
+  la ligne d'item avec deux clés qu'`IDataTableRowProps` ne déclare pas —
+  `index`, jamais lu par le composant, et `mobile`, un résidu d'avant
+  l'ajout du forwarding de `mobileBreakpoint` (chaque ligne calcule déjà son
+  propre `mobile` à partir de ce dernier). Une clé non déclarée tombe dans
+  `$attrs`, et le `v-bind="$attrs"` du `<tr>` racine la posait en attribut
+  DOM littéral sur **chaque** ligne rendue — `index="0" mobile="false"`.
+  Même mécanisme que le point 1 de ce ticket (déjà corrigé, `08c30693a`),
+  une famille plus loin. `aria-rowindex`, seul attribut voulu de ce canal,
+  continue de passer.
+
+### Added
+
+- **`mobileBreakpoint` a désormais un contrôle de story sur
+  `<OrigamDataTable>`** (#371, point 5). La prop — dont le défaut `'xs'`
+  corrige un bug de production documenté en commentaire
+  (`OrigamDataTable.vue:190-199` : sans lui, `useDisplay` retombait sur le
+  seuil global `'lg'` et forçait le rendu mobile empilé sur tout viewport
+  sous 1280px) — n'apparaissait dans aucune des 30 Variants de
+  `OrigamDataTable.story.vue`. Ajout de la Variant « Prop —
+  mobileBreakpoint » (même jeu d'options que celui déjà utilisé par
+  `OrigamDataTableRow.story.vue`) et d'une section « Responsive » +
+  ligne de table dans `OrigamDataTable.md`.
+
 ---
 
 ## [2.18.0] - 2026-09-19

package/dist/src/components/DataTable/OrigamDataTableRows.vue

@@ -136,7 +136,6 @@
 import OrigamDataTableGroupHeaderRow from "./OrigamDataTableGroupHeaderRow.vue";
 import OrigamDataTableRow from "./OrigamDataTableRow.vue";
 import OrigamSkeleton from "../Skeleton/OrigamSkeleton.vue";
-import { useDisplay } from "../../composables/Commons/display.composable";
 import { useExpanded } from "../../composables/DataTable/expand.composable";
 import { useGroupBy } from "../../composables/DataTable/group.composable";
 import { useHeaders } from "../../composables/DataTable/headers.composable";
@@ -186,7 +185,6 @@ const { columns } = useHeaders();
 const { expandOnClick, toggleExpand, isExpanded } = useExpanded();
 const { isSelected, toggleSelect } = useSelection();
 const { toggleGroup, isGroupOpen } = useGroupBy();
-const { mobile } = useDisplay(props);
 const { startIndex } = usePagination();
 const slotProps = (item, index) => {
   return {
@@ -235,20 +233,32 @@ const itemSlotProps = (item, index) => {
         onClick: expandOnClick.value ? () => {
           toggleExpand(item);
         } : void 0,
-        index,
         item,
         cellProps: props.cellProps,
-        // Forward `mobileBreakpoint` so each row's own
-        // `useDisplay(props)` resolves to the SAME
-        // threshold the table-level resolved. Pre-fix
-        // only `mobile: mobile.value` was passed but the
-        // row's interface declares `mobileBreakpoint`,
-        // not `mobile` — so the row fell back to the
-        // global `'lg'` (1280px), forcing mobile mode
-        // on every viewport <1280px regardless of what
-        // the consumer set on the DataTable.
+        /*********************************************************
+         * Forward `mobileBreakpoint` — never `mobile` (#371)
+         *
+         * @description
+         * `IDataTableRowProps` (extends `IDisplayProps`)
+         * declares `mobileBreakpoint`, not `index` or
+         * `mobile`. Each row resolves its OWN `mobile` from
+         * `mobileBreakpoint` via its own `useDisplay(props)`
+         * call — passing a precomputed `mobile` here was
+         * always dead weight, and passing `index` was never
+         * read by the row at all. Both fell through
+         * `<OrigamDataTableRow>`'s undeclared-key path
+         * straight into `$attrs`, which its
+         * `v-bind="$attrs"` root then serialised as literal
+         * DOM attributes on every rendered `<tr>`:
+         * `index="0" mobile="false"`.
+         *
+         * @description
+         * A prior fix (mobileBreakpoint forwarding) added
+         * the correct key without removing the stale one it
+         * replaced — same shape as the point-1 closure leak
+         * in this same file's `groupHeaderRowProps()`.
+         ********************************************************/
         mobileBreakpoint: props.mobileBreakpoint,
-        mobile: mobile.value,
         "aria-rowindex": startIndex.value + index + 2
       },
       getPrefixedEventHandlers(attrs, ":row", () => slotPropsLocal),

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "origam",
-  "version": "2.18.1",
+  "version": "2.18.2",
   "type": "module",
   "description": "origam — a Vue 3 design system with multi-theme design tokens, CSS-first components and TypeScript types.",
   "keywords": [