@bsuite/theme 0.7.2 → 0.8.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bsuite/theme",
-  "version": "0.7.2",
+  "version": "0.8.0",
   "type": "module",
   "license": "UNLICENSED",
   "publishConfig": {

package/src/css/braden.css

@@ -113,6 +113,64 @@
   --role-success:     var(--braden-aqua);
   --role-info:        var(--braden-teal-deep);
 
+  /* ═══ INFORMATIONAL SCALE — categorical, NOT semantic ═══
+     Added 2026-08-03 by operator ruling: "informational hues might be handy
+     to stand out against the style colour palette."
+
+     Role tokens describe STATE. They cannot describe CATEGORY — which
+     pipeline stage, which user role, which product tile. Apps that needed a
+     category reached for raw Tailwind instead, which is how one role-badge
+     table came to use purple, indigo, blue, violet and sky as its only
+     distinguishing signal.
+
+     NUMBERED, NOT NAMED, deliberately. Call one of these "moss green" and
+     it will be used for success within a week. A number says what these
+     are: interchangeable slots carrying no meaning of their own.
+     NEVER use an --info-* for state. State has role tokens.
+
+     Derived, not picked by eye: Vienot-Brettel-Mollon dichromat simulation,
+     DeltaE in OKLab, scored as the WORST case across normal, deuteranope and
+     protanope vision. Two constraints — perceptual distance keeps them
+     DISTINGUISHABLE, a >=28 degree hue gap keeps them looking CATEGORICAL
+     rather than like a light/dark pair of one colour. Every one is also
+     held away from the brand roles, which is what "stand out against the
+     style palette" requires: an informational badge must not read as a
+     primary action or an error.
+     Reproduce with scripts/design-informational-hues.py
+
+     LIMIT: worst-case separation is ~0.06-0.07, against >=0.156 for the
+     semantic pairs. That is 10x better than the purple-vs-blue pairing this
+     system rejected (0.006), but it is NOT the semantic standard and cannot
+     be — 8 mutually-distinct categories that also avoid 6 reserved brand
+     colours is a harder problem than 6 roles. So: colour is never the sole
+     signifier for a category. Always pair with a label or an icon. Past 8
+     categories, stop adding hues and add a second dimension. */
+  --info-1: oklch(0.660 0.120   0.0);
+  --info-2: oklch(0.660 0.120  30.0);
+  --info-3: oklch(0.620 0.120  72.0);
+  --info-4: oklch(0.460 0.120 132.0);
+  --info-5: oklch(0.780 0.120 162.0);
+  --info-6: oklch(0.740 0.120 222.0);
+  --info-7: oklch(0.660 0.120 252.0);
+  --info-8: oklch(0.620 0.120 324.0);
+
+  /* ═══ STAGE RAMP — progression, one hue, ascending lightness ═══
+     For an ORDERED sequence (pipeline stages), not a category set. A ramp
+     encodes direction: "further along" is visible at a glance, and it
+     survives greyscale and both dichromacies because lightness carries it.
+     Arbitrary per-stage hues cannot do that — a reader has to LEARN that
+     sky comes after amber.
+
+     Progression only. OUTCOMES are state, not stage: a hired candidate is
+     --role-success, a rejected one --role-error, a withdrawn one muted.
+     Do not extend this ramp to cover them. */
+  --stage-1: oklch(0.860 0.090 249.0);
+  --stage-2: oklch(0.780 0.090 249.0);
+  --stage-3: oklch(0.700 0.090 249.0);
+  --stage-4: oklch(0.620 0.090 249.0);
+  --stage-5: oklch(0.540 0.090 249.0);
+  --stage-6: oklch(0.460 0.090 249.0);
+
 /* ============================================================
    LAYER 3 — AA-SAFE TEXT RENDERINGS OF THE SATURATED ROLES
    A saturated fill colour is not a legible text colour.

package/src/css/vars.css

@@ -127,6 +127,64 @@
   --role-success:     var(--neon-electric-teal);    /* was green — 0.043 from red */
   --role-info:        var(--neon-electric-cyan);    /* oklch(0.769 0.132 191.7) */
 
+  /* ═══ INFORMATIONAL SCALE — categorical, NOT semantic ═══
+     Added 2026-08-03 by operator ruling: "informational hues might be handy
+     to stand out against the style colour palette."
+
+     Role tokens describe STATE. They cannot describe CATEGORY — which
+     pipeline stage, which user role, which product tile. Apps that needed a
+     category reached for raw Tailwind instead, which is how one role-badge
+     table came to use purple, indigo, blue, violet and sky as its only
+     distinguishing signal.
+
+     NUMBERED, NOT NAMED, deliberately. Call one of these "moss green" and
+     it will be used for success within a week. A number says what these
+     are: interchangeable slots carrying no meaning of their own.
+     NEVER use an --info-* for state. State has role tokens.
+
+     Derived, not picked by eye: Vienot-Brettel-Mollon dichromat simulation,
+     DeltaE in OKLab, scored as the WORST case across normal, deuteranope and
+     protanope vision. Two constraints — perceptual distance keeps them
+     DISTINGUISHABLE, a >=28 degree hue gap keeps them looking CATEGORICAL
+     rather than like a light/dark pair of one colour. Every one is also
+     held away from the brand roles, which is what "stand out against the
+     style palette" requires: an informational badge must not read as a
+     primary action or an error.
+     Reproduce with scripts/design-informational-hues.py
+
+     LIMIT: worst-case separation is ~0.06-0.07, against >=0.156 for the
+     semantic pairs. That is 10x better than the purple-vs-blue pairing this
+     system rejected (0.006), but it is NOT the semantic standard and cannot
+     be — 8 mutually-distinct categories that also avoid 6 reserved brand
+     colours is a harder problem than 6 roles. So: colour is never the sole
+     signifier for a category. Always pair with a label or an icon. Past 8
+     categories, stop adding hues and add a second dimension. */
+  --info-1: oklch(0.460 0.140   0.0);
+  --info-2: oklch(0.700 0.140  42.0);
+  --info-3: oklch(0.540 0.140 138.0);
+  --info-4: oklch(0.700 0.140 168.0);
+  --info-5: oklch(0.780 0.140 228.0);
+  --info-6: oklch(0.700 0.140 258.0);
+  --info-7: oklch(0.500 0.140 300.0);
+  --info-8: oklch(0.460 0.140 330.0);
+
+  /* ═══ STAGE RAMP — progression, one hue, ascending lightness ═══
+     For an ORDERED sequence (pipeline stages), not a category set. A ramp
+     encodes direction: "further along" is visible at a glance, and it
+     survives greyscale and both dichromacies because lightness carries it.
+     Arbitrary per-stage hues cannot do that — a reader has to LEARN that
+     sky comes after amber.
+
+     Progression only. OUTCOMES are state, not stage: a hired candidate is
+     --role-success, a rejected one --role-error, a withdrawn one muted.
+     Do not extend this ramp to cover them. */
+  --stage-1: oklch(0.860 0.130 262.9);
+  --stage-2: oklch(0.780 0.130 262.9);
+  --stage-3: oklch(0.700 0.130 262.9);
+  --stage-4: oklch(0.620 0.130 262.9);
+  --stage-5: oklch(0.540 0.130 262.9);
+  --stage-6: oklch(0.460 0.130 262.9);
+
   /* AA-safe text renderings of the saturated roles on light surfaces.
      A saturated fill colour is not a legible text colour; these are the
      text variants and are the ONLY correct token for coloured type. */

package/src/preset-v4.css

@@ -102,6 +102,30 @@
   --color-warning-text: var(--role-warning-text);
   --color-success-text: var(--role-success-text);
 
+  /* Informational scale — CATEGORICAL, never state. `bg-info-3`, `text-info-5`.
+     Numbered because they are interchangeable slots with no meaning of their
+     own; naming one invites it to be used as a semantic. Pair every one with a
+     label or icon — their separation is deliberately below the semantic
+     standard and cannot carry meaning alone. See --info-* in vars.css. */
+  --color-info-1: var(--info-1);
+  --color-info-2: var(--info-2);
+  --color-info-3: var(--info-3);
+  --color-info-4: var(--info-4);
+  --color-info-5: var(--info-5);
+  --color-info-6: var(--info-6);
+  --color-info-7: var(--info-7);
+  --color-info-8: var(--info-8);
+
+  /* Stage ramp — ORDERED progression. `bg-stage-1` .. `bg-stage-6`, lightness
+     descending, so "further along" reads at a glance and survives greyscale.
+     Outcomes are NOT stages: hired is --role-success, rejected --role-error. */
+  --color-stage-1: var(--stage-1);
+  --color-stage-2: var(--stage-2);
+  --color-stage-3: var(--stage-3);
+  --color-stage-4: var(--stage-4);
+  --color-stage-5: var(--stage-5);
+  --color-stage-6: var(--stage-6);
+
   /* Per-app accent (Layer 5). Resolves through [data-app] on <body>,
      falling back to the shared accent when no app is declared. */
   --color-app-accent:      var(--app-accent, var(--role-accent));