origam 2.18.6 → 2.18.8

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.
package/CHANGELOG.md CHANGED
@@ -18,6 +18,195 @@ This project follows [Semantic Versioning](https://semver.org).
18
18
 
19
19
  ## [Unreleased]
20
20
 
21
+ ### Fixed — #901 `OrigamBtn` — `calc(auto + 0px)` ramenait `min-width` à `0` sur tous les boutons
22
+
23
+ `OrigamBtn.vue`, second bloc `<style scoped>`, déclarait sans condition sur
24
+ `.origam-btn` `--origam-btn---min-width: calc(var(--origam-btn---width, 36px)
25
+ + var(--origam-btn---density, 0px))`. La feuille (`light.css`/`dark.css`)
26
+ déclare `--origam-btn---width: auto`, donc le repli `36px` n'était jamais
27
+ atteint et la valeur devenait `calc(auto + 0px)` — invalide au moment de la
28
+ substitution dans `min-width` (ligne 563), pas au parse : la propriété
29
+ retombait sur sa valeur initiale (`auto` → `0` hors flex), jamais sur le
30
+ repli `64px`. Même spécificité `(0,2,0)` que les modificateurs `&--size-*`,
31
+ mais déclaré APRÈS eux : les 5 échelons de `size` et `&--icon` étaient donc
32
+ tous écrasés — famille de la garde 29 `unitless-zero-in-calc` / #607.
33
+
34
+ Mesuré en navigateur réel (Playwright + Histoire statique, chromium) :
35
+
36
+ | | avant | après |
37
+ |---|---|---|
38
+ | `size=x-small` | `0px` | `36px` |
39
+ | `size=small` | `0px` | `50px` |
40
+ | `size=default` | `0px` | `64px` |
41
+ | `size=large` | `0px` | `78px` |
42
+ | `size=x-large` | `0px` | `92px` |
43
+ | `density=comfortable` (size=default) | `0px` | `72px` |
44
+ | `icon=true` | `28px` (dépendait de `--origam-btn---height` résolue, pas de 0 voulu) | `0px` |
45
+
46
+ Correctif : `min-width` (l.563) lit désormais directement
47
+ `--origam-btn---min-width` (repli `64px`) plutôt que `--origam-btn---width`,
48
+ et le second bloc `<style scoped>` ne réécrit plus ce canal (ni
49
+ `--origam-btn---min-height`, strictement identique au repli déjà présent
50
+ l.566 et jamais déclaré par aucune feuille — retrait vérifié sans effet).
51
+
52
+ ⛔ **Corollaire découvert en réparant** : le nouveau `calc(var(--origam-
53
+ btn---min-width, 64px) + var(--origam-btn---density, 0px))` fait
54
+ maintenant participer `--origam-btn---min-width` à une addition — et
55
+ `&--icon` le posait à `0` NU (`<number>`, pas `<length>`), le même défaut
56
+ que celui réparé ici. `OrigamCode.vue` déclarait le même canal en `0` nu
57
+ pour son bouton de copie compact (`.origam-code__copy`,
58
+ `.origam-code__copy--compact`). Les trois déclarations passent à `0px` —
59
+ changement sémantiquement neutre (`0` == `0px` en CSS), guard
60
+ `unitless-zero-in-calc` self-testé vert. `token-var-channels` gagne 1 entrée
61
+ « canal mort connu » pour `--origam-btn---min-height` (jamais alimenté par
62
+ le pipeline de tokens, extension locale volontaire — baseline mise à jour).
63
+
64
+ **VRT** : mesuré (pas supposé) via `pnpm -F @origam/tests test:vrt:docker`
65
+ (image `mcr.microsoft.com/playwright:v1.59.1-jammy` pinnée, seule verdict
66
+ valable — cf. `vrt/VRT.md`) — `vrt/btn-variant.spec.ts`, 7/7 verts, **aucune
67
+ capture ne bouge**. Les 7 libellés de la matrice (`Text` … `Outlined`, 4 à
68
+ 8 caractères) dépassent déjà le plancher `size=small` (`50px`) une fois le
69
+ padding `12px`×2 ajouté, donc le nouveau plancher ne change la largeur
70
+ d'aucun bouton de ce pilote. Aucune baseline à régénérer dans cette PR.
71
+
72
+ ### Fixed — #607 / #569 : 19 canaux de thème confisqués par le bloc du composant
73
+
74
+ Un composant qui redéclare un token que les feuilles déclarent déjà rend ce
75
+ canal **inatteignable par tout `IOrigamTheme` de marque**. Une custom property
76
+ est substituée sur l'élément **qui la déclare**, et l'héritage depuis
77
+ `[data-theme="brand-x"]` perd contre n'importe quelle déclaration directe — la
78
+ spécificité n'entre même pas en jeu.
79
+
80
+ **Le motif dominant, mesuré, n'est pas celui que les tickets décrivaient.** Sur
81
+ les 503 déclarations scopées visant un token de feuille, **434 sont portées par
82
+ un modificateur que le consommateur doit demander** (`&--rounded-large`,
83
+ `&--density-compact`) : `useRounded` / `useDensity` n'émettent rien quand la
84
+ prop est absente, donc ces règles ne confisquent rien — c'est la logique
85
+ PROPS-FIRST du DS en train de fonctionner. La vraie cause commune est plus
86
+ étroite : **un modificateur dont la valeur est aussi le défaut de la prop dans
87
+ `withDefaults`** (`&--size-default` sur `size: SIZES.DEFAULT`,
88
+ `&--density-default` sur `density: DENSITY.DEFAULT`). La classe est alors posée
89
+ sur **chaque** instance, et la règle épingle le token à vie.
90
+
91
+ Les 19 déclarations retirées résolvent toutes **exactement** la valeur de la
92
+ feuille, chaîne de `var()` déroulée — `12px` = `var(--origam-space---3)`,
93
+ `0.875rem` = `var(--origam-font__size---md)`, `48px` = `var(--origam-space---12)`.
94
+ Le rendu par défaut est donc inchangé ; seul le canal redevient atteignable.
95
+ (3 seulement sont littéralement identiques : une comparaison de chaînes ne voit
96
+ rien, d'où le résolveur.)
97
+
98
+ - `OrigamAlert`, `OrigamBtn`, `OrigamList`, `OrigamTable`, `OrigamTabs`,
99
+ `OrigamToolbar` — `&--density-default`
100
+ - `OrigamBtn`, `OrigamStepper` — `&--size-default`
101
+ - `OrigamKbd` — `&--variant-outlined` (`border-color`)
102
+ - `OrigamChip` — second bloc `<style scoped>` entier, qui épinglait `density`
103
+ - `OrigamTabs` — plus son bloc `<style>:root{}` (#569)
104
+
105
+ **Preuve navigateur, A/B contre le commit parent** (Chromium, Histoire statique,
106
+ thème de marque injecté par `addInitScript` avant le document). Même story, même
107
+ liste de classes, sur `--origam-btn---density` que `.origam-btn--density-default`
108
+ épinglait à `0px` :
109
+
110
+ | | avant | après |
111
+ |---|---|---|
112
+ | `--origam-btn---density` | `0px` | **`24px`** |
113
+ | hauteur calculée | 28px | **52px** |
114
+
115
+ **Changed** — `--origam-btn---height` et `--origam-toolbar---height` lisent
116
+ désormais leur échelon (`…---height-md` / `…---height-default`) depuis les
117
+ feuilles, dans les quatre fichiers miroirs css/scss. Sans ça l'échelon restait
118
+ sans lecteur après le retrait et `token-var-channels` rougissait ; les deux
119
+ canaux sont vivants.
120
+
121
+ **Added** — garde 29 `theme-channel-confiscation` : il ne lève que
122
+ l'intersection « règle toujours active » × « valeur identique après résolution
123
+ des `var()` », les deux discriminants pinnés par 13 témoins de rappel **et de
124
+ précision**. Baseline à **37** entrées : 14 blocs `<style>:root{}` restants
125
+ (#569) et 22 surcharges parent→enfant où le canal est **renommé** et non mort
126
+ (`OrigamSnackbarGroup` expose `--origam-snackbar-group__item---*` depuis #436,
127
+ la famille Media configure ses `.origam-btn` imbriqués). Livraison
128
+ **volontairement partielle** : chacune de ces deux familles demande une
129
+ migration de feuille composant par composant, avec risque de rendu — donc un
130
+ arbitrage, pas un correctif.
131
+
132
+ ### Fixed — #829 : `geek` ET `glass` déclaraient `surface.sunken` PLUS CLAIR que `surface.default` (mode clair)
133
+
134
+ `sunken` et `default` ne sont pas deux couleurs interchangeables, ce sont des
135
+ **rôles** : `sunken` promet une surface encaissée. En mode **clair**, `geek`
136
+ déclarait `#fbf5ff` — un ton plus clair que son `default` `#f6f0ff` — donc
137
+ tout consommateur demandant un creux recevait un ton **surélevé**.
138
+
139
+ Mesuré en navigateur réel (Chromium, `/installation`, `data-theme="geek"`,
140
+ valeur peinte sur une sonde, pas le littéral du fichier) :
141
+
142
+ | | avant | après |
143
+ |---|---|---|
144
+ | `surface---default` | `rgb(246, 240, 255)` L=0.891 | inchangé |
145
+ | `surface---sunken` | `rgb(251, 245, 255)` **L=0.930** | `rgb(239, 232, 252)` **L=0.831** |
146
+ | relation | **surélevé** ❌ | **encaissé** ✅ |
147
+
148
+ **Valeur choisie par la grammaire du dépôt, pas à l'œil.** Sur les 5 autres
149
+ thèmes clairs corrects, la « profondeur du creux » — contrast(default,
150
+ sunken) — va de 1.0487 (`material`) à 1.1001 (`editorial`). `#efe8fc` place
151
+ `geek` à **1.0686**, dans cette bande, conserve la teinte lavande et
152
+ respecte l'ordre `disabled < sunken < default`.
153
+
154
+ **Consommateurs** : 41 occurrences de `surface---sunken` dans 20 fichiers de
155
+ `packages/marketing/src` (le ticket annonçait « ~30 » ; recompté). La plus
156
+ large est `assets/css/themes/_shared.css:88`, qui alimente
157
+ `--origam-code---background-color` : vérifié sur les **13** blocs
158
+ `.origam-code` de `/installation`, qui passent de `rgb(251,245,255)` à
159
+ `rgb(239,232,252)`.
160
+
161
+ ⛔ **La moitié « mode sombre » du ticket n'est pas reproduite, et rien n'y a
162
+ été changé.** En mode sombre un creux se lit plus CLAIR que la page, et c'est
163
+ déjà le cas : `sunken` L=0.009 > `default` L=0.002. Le ticket la signalait au
164
+ motif que `sunken` y dépasse `raised` ; sur cette relation le dépôt n'est pas
165
+ uniforme (`apple`, `cartoon`, `editorial`, `material` et `geek` font ainsi,
166
+ seuls `ecom` et `glass` l'inversent), donc elle ne constitue pas une règle.
167
+
168
+ `overlay` n'a **pas** suivi `sunken` : c'est un rôle de remplissage de
169
+ composant (chip, avatar, kbd, btn tonal, lignes survolées — 58 occurrences),
170
+ pas une surface encaissée, et le bloc sombre de `geek` découplait déjà les
171
+ deux.
172
+
173
+ #### `glass` — même défaut, même mode
174
+
175
+ Trouvé en relevant les 7 marques pour choisir la valeur de `geek`. `glass`
176
+ déclarait `sunken: rgba(255, 255, 255, 0.85)` — **la même valeur que son
177
+ `overlay`**. Mesure des pixels **rendus** (capture relue via canvas, donc
178
+ compositing réel) :
179
+
180
+ | | avant | après |
181
+ |---|---|---|
182
+ | `default` | `rgb(233, 236, 255)` L=0.8453 | inchangé |
183
+ | `raised` | `rgb(247, 248, 255)` L=0.9413 | inchangé |
184
+ | `sunken` | `rgb(252, 252, 255)` **L=0.9754** | `rgb(226, 229, 249)` **L=0.7905** |
185
+
186
+ ⛔ **« Un verre dépoli éclaircit ce qu'il couvre » ne l'excusait pas, et c'est
187
+ le mode SOMBRE de `glass` lui-même qui le prouve.** En sombre, l'identité place
188
+ déjà `sunken` (blanc 4 %) ENTRE `default` et `raised` (blanc 5 %) — une
189
+ élévation plus faible. En clair elle le plaçait AU-DELÀ de `raised` (blanc 85 %
190
+ contre 65 %). La thèse prédirait le même sens dans les deux modes : l'identité
191
+ se contredisait elle-même. Ce n'est pas un idiome assumé.
192
+
193
+ Le correctif **garde la translucidité** sur laquelle l'identité est bâtie (les
194
+ consommateurs de `backdrop-filter` voient toujours au travers) et remplace le
195
+ blanc par l'encre de la palette à 3 % : `rgba(26, 21, 56, 0.03)`. Profondeur
196
+ rendue **1.0653**, contre **1.0591** pour le mode sombre de `glass` lui-même —
197
+ la valeur est celle que l'identité utilise déjà, et elle est dans la bande du
198
+ dépôt. `overlay` garde le blanc dépoli : c'est un rôle de remplissage de
199
+ composant, où « plus opaque qu'une carte » est la bonne lecture glassmorphism.
200
+
201
+ Non-régression : `audit:dark-contrast` reste à **0 / 1 664**.
202
+
203
+ Ajouté `packages/tests/TU/marketing/brand-surface-elevation.spec.ts` — **14 cas
204
+ (7 marques × 2 modes), tous arbitrés**, aucun sauté : les surfaces translucides
205
+ sont **compositées** sur le `default` de leur propre thème, avec l'opération
206
+ `over()` de `audit/dark-contrast.audit.mjs`. Accord avec le navigateur à 3
207
+ décimales (composite 0.9757 contre pixel rendu 0.9754). Vérifiée ROUGE sur les
208
+ valeurs du commit parent, une fois par marque : `geek/light` puis `glass/light`.
209
+
21
210
  ### Fixed — #818 baseline shrink : les 8 `color-contrast` du DS (8 → 0)
22
211
 
23
212
  ⚠️ **Ce lot porte sur le DS lui-même, pas sur une palette marketing** : il