@flytedan/flytebot-design-system 0.12.9 → 0.12.11

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@flytedan/flytebot-design-system",
-  "version": "0.12.9",
+  "version": "0.12.11",
   "description": "flytedesk Design System — shared component library, tokens, and business-logic kits for flytedesk apps.",
   "type": "module",
   "license": "UNLICENSED",

package/styles/components.css

@@ -176,13 +176,23 @@
   background: var(--surface);
   box-shadow: var(--e-1);
 }
-/* Tone on a quiet (ghost/outline) icon button: the glyph carries it, on hover too. */
-.fd-btn-icon.is-ok:not(.fd-btn-icon-solid),
-.fd-btn-icon.is-ok:not(.fd-btn-icon-solid):hover {
+/* Tone on a quiet (ghost/outline) icon button: the glyph carries it, on hover too.
+   MP-114 follow-up: also excludes .fd-btn-icon-soft, which was never meant to match
+   here (it isn't ghost or outline — it has its own real fill, see .fd-btn-icon-soft
+   below) but did, at (0,3,0) beating the soft rule's own un-toned (0,1,0)/toned
+   (0,2,0) color rules at rest. That stomped --btn-soft-ok-ink/--btn-soft-danger-ink
+   (chosen to clear 4.5:1 against the soft fill) with --ok-text/--danger-text (chosen
+   to clear 4.5:1 against a plain card instead) — a real fill behind the wrong ink,
+   e2e-measured at 2.04:1. The soft rule's own `:hover`/`:active` restatements already
+   won their own specificity fight against this same rule's `:hover` (both (0,3,0),
+   soft declared later so it wins the tie) — only the REST state, where soft never
+   restated color at all, actually lost. */
+.fd-btn-icon.is-ok:not(.fd-btn-icon-solid):not(.fd-btn-icon-soft),
+.fd-btn-icon.is-ok:not(.fd-btn-icon-solid):not(.fd-btn-icon-soft):hover {
   color: var(--ok-text);
 }
-.fd-btn-icon.is-danger:not(.fd-btn-icon-solid),
-.fd-btn-icon.is-danger:not(.fd-btn-icon-solid):hover {
+.fd-btn-icon.is-danger:not(.fd-btn-icon-solid):not(.fd-btn-icon-soft),
+.fd-btn-icon.is-danger:not(.fd-btn-icon-solid):not(.fd-btn-icon-soft):hover {
   color: var(--danger-text);
 }
 /* Solid: a real fill in the tone's colour. The fills and inks are the --btn-solid-*
@@ -231,6 +241,41 @@
 .fd-btn-icon-solid:focus-visible {
   box-shadow: var(--focus-ring);
 }
+/* Soft: a lighter fill than solid, with a visibly darker border drawn around it (MP-52's
+   "lighter fill, darker border" row action). Same --btn-soft-* tokens (tokens.css), same
+   per-theme measurement discipline as solid, and the same pressed-selector-specificity
+   fix baked in from the start (see the comment on .fd-btn-icon-solid:active above). */
+.fd-btn-icon-soft {
+  background: var(--btn-soft-bg);
+  color: var(--btn-soft-ink);
+  border-color: var(--btn-soft-border);
+  box-shadow: var(--e-1);
+}
+.fd-btn-icon-soft.is-ok {
+  --btn-soft-bg: var(--btn-soft-ok-bg);
+  --btn-soft-border: var(--btn-soft-ok-border);
+  --btn-soft-ink: var(--btn-soft-ok-ink);
+}
+.fd-btn-icon-soft.is-danger {
+  --btn-soft-bg: var(--btn-soft-danger-bg);
+  --btn-soft-border: var(--btn-soft-danger-border);
+  --btn-soft-ink: var(--btn-soft-danger-ink);
+}
+.fd-btn-icon-soft:hover,
+.fd-btn-icon-soft.is-ok:hover,
+.fd-btn-icon-soft.is-danger:hover {
+  filter: brightness(1.08);
+  color: var(--btn-soft-ink);
+}
+.fd-btn-icon-soft:active,
+.fd-btn-icon-soft.is-ok:active,
+.fd-btn-icon-soft.is-danger:active {
+  filter: brightness(0.92);
+  box-shadow: none;
+}
+.fd-btn-icon-soft:focus-visible {
+  box-shadow: var(--focus-ring);
+}
 .fd-btn-icon-sm {
   width: var(--control-h-sm);
   height: var(--control-h-sm);
@@ -4054,8 +4099,20 @@
    itself uses (--r-md here rather than Card's --r-lg — a compact list row reads
    better with the tighter radius; --e-1/--e-2 are the same elevation tokens). */
 .fd-erow {
+  /* display/align-items/gap/padding live here, not on the component's inline style
+     (where they used to be, MP-114 follow-ups) — an inline style always wins over a
+     stylesheet rule, which would make it impossible for the narrow-container rule
+     below to ever switch this row from a flex row to a grid. gap/padding/border-width
+     read the shared --erow-* custom properties (declared once on .fd-tlist above)
+     rather than carrying their own literals, which is also what lets
+     .fd-tlist-footer's indent stay correct by construction instead of by two
+     numbers happening to agree. */
+  display: flex;
+  align-items: center;
+  gap: var(--erow-gap);
+  padding: 0 var(--erow-pad-x);
   background: var(--surface-2);
-  border: 1px solid var(--erow-border);
+  border: var(--erow-border-w) solid var(--erow-border);
   border-radius: var(--r-md);
   box-shadow: var(--e-1);
   transition:
@@ -4126,6 +4183,43 @@
   overflow: hidden;
   text-overflow: ellipsis;
 }
+/* The title-icon Tooltip trigger (MP-52): icon and title share one hoverable/focusable
+   region rather than two, so hovering either opens the same explanation. Carries the same
+   flex floor .fd-erow-title has on its own (see the comment above it) so wrapping the
+   title in a button never changes how the titleline shares space with `meta`. Reset to a
+   plain inline button — no border/background/font change — because visually this must
+   read exactly like a title with an icon in front of it, not a control. */
+.fd-erow-title-icon {
+  display: inline-flex;
+  align-items: center;
+  gap: 4px;
+  flex: 1 1 auto;
+  min-width: 45%;
+  border: 0;
+  background: none;
+  padding: 0;
+  margin: 0;
+  font: inherit;
+  color: inherit;
+  text-align: left;
+  cursor: pointer;
+}
+.fd-erow-title-icon .fd-erow-title {
+  min-width: 0;
+}
+.fd-erow-title-icon > .ph {
+  flex: none;
+  font-size: 14px;
+  color: var(--text-muted);
+}
+.fd-erow-title-icon.is-danger > .ph {
+  color: var(--danger-solid);
+}
+.fd-erow-title-icon:focus-visible {
+  outline: none;
+  box-shadow: var(--focus-ring);
+  border-radius: var(--r-sm);
+}
 .fd-erow-strip {
   display: flex;
   align-items: center;
@@ -4227,6 +4321,12 @@ button.fd-erow-metric:focus-visible {
   display: inline-flex;
   align-items: center;
 }
+/* Size lives here, not on the component's inline style (MP-114 third follow-up,
+   same reasoning as .fd-erow's own padding above): .fd-tlist-footer's indent reads
+   it back as --erow-grip-size. */
+.fd-erow-grip {
+  font-size: var(--erow-grip-size);
+}
 .fd-erow[draggable="true"]:active {
   cursor: grabbing;
 }
@@ -4256,49 +4356,182 @@ button.fd-erow-metric:focus-visible {
    screen's. */
 .fd-tlist {
   container-type: inline-size;
+  /* A row's own geometry, declared ONCE here rather than as literals wherever
+     something needs to line up with it (MP-114, third follow-up: the totals
+     footer's indent restated these as bare numbers in two places while the real
+     values lived as inline styles on EntityRow.tsx's row and its drag grip — a
+     change to either drifted the footer's indent silently, which is exactly what
+     the second follow-up's 24px misalignment was). `.fd-erow` and `.fd-erow-grip`
+     read these instead of carrying their own inline padding/font-size, and
+     `.fd-tlist-footer`'s two indents (below) are `calc()` of the same four
+     properties — a row and the totals line can only drift apart now if one of
+     THESE four values changes, and both readers change with it. Declared on
+     `.fd-tlist` (the one ancestor common to both a row and the footer, which are
+     otherwise unrelated siblings under `.fd-tlist-side`) rather than on `.fd-erow`
+     itself, so the footer — which is never a descendant of any `.fd-erow` — can
+     still read them by ordinary custom-property inheritance. */
+  --erow-border-w: 1px;
+  --erow-pad-x: 12px;
+  --erow-grip-size: 14px;
+  --erow-gap: 10px;
 }
 .fd-tlist-panes {
   display: flex;
   gap: 16px;
   align-items: flex-start;
 }
+/* TransferList's per-side slots. The footer is where a running totals line goes;
+   it sits on the panel, not on a card, and is separated by a rule rather than a
+   gap so it reads as a summary OF the list rather than another row IN it.
+   Declared here, BEFORE the narrow @container block below, deliberately: CSS
+   cascade order for two rules of equal specificity is source order regardless of
+   which one sits inside an at-rule, so a base rule declared AFTER a narrow
+   override for the same property would silently win at every width, override
+   included — this is what actually happened to this rule's own `padding-left`
+   for two follow-ups running (the override was textually correct and had a
+   passing stylesheet-contract test, but the base rule used to be declared further
+   down the file, after the @container block, and always won the tie). */
+.fd-tlist-header {
+  display: flex;
+  align-items: center;
+  gap: 8px;
+  min-width: 0;
+}
+.fd-tlist-footer {
+  display: flex;
+  align-items: center;
+  gap: 10px;
+  min-width: 0;
+  padding-top: 8px;
+  /* Indented to the x a row's own body starts at, so a totals strip in here lands
+     under the columns it totals rather than a card's width to the left of them: the
+     card's border, the row's own padding, the drag grip and its gap — every row in
+     a TransferList is a drag source, so it is the same on all of them. Written as
+     calc() of the shared --erow-* custom properties (.fd-tlist's own comment)
+     rather than as separate literals that merely happened to equal the same
+     numbers EntityRow.tsx's row/grip carried inline — a change to any one of those
+     four properties now moves this indent with it instead of silently drifting out
+     of alignment, which is exactly how this went wrong at the narrow breakpoint
+     (see that rule's own comment). */
+  padding-left: calc(var(--erow-border-w) + var(--erow-pad-x) + var(--erow-grip-size) + var(--erow-gap));
+  border-top: 1px solid var(--border);
+  font-size: var(--overline-size);
+  color: var(--text-2);
+}
 @container (max-width: 600px) {
   .fd-tlist-panes {
     flex-direction: column;
     align-items: stretch;
   }
-  /* MP-114 (follow-up — the `width: auto` version of this rule regressed the
-     alignment it was supposed to preserve): below this width EntityRow's metric strip
-     stops having room to keep every column at the desktop's fixed --erow-metric-w (set
-     so rows line up with a multi-digit totals footer, see EntityRowMetrics/.fd-erow-cell
-     above) — even each cell's own un-wrapped figure (`.fd-erow-metric`'s
-     `white-space: nowrap` makes its min-content equal its full width) no longer fits
-     together in the strip, and `.fd-erow-metrics`'s `overflow: hidden` was clipping the
-     ones that didn't.
-     The first fix let `.fd-erow-cell` go `width: auto` — but "auto" means "size to your
-     own content", and a row's own figures and TransferList's footer totals almost never
-     have the same digit counts, so the row's strip and the totals strip (the SAME
-     component, at the SAME nominal column widths) drifted apart the moment either one's
-     content did — audience-builder.spec.ts caught this: a row 14px narrower than the
-     totals line under it. A fixed-width cell has to stay fixed-width EVERYWHERE for
-     "the same column lands at the same x on every row and on the totals line" (see
-     .fd-erow-metrics's own comment above) to mean anything, including here. So instead:
-     `flex-shrink: 0` keeps every cell at its exact declared width even when the strip
-     has less room than the three columns need, which the row and the footer both still
-     agree on regardless of what either one's figures say — and `.fd-erow-metrics`
-     scrolls that overflow horizontally instead of clipping it, the same "wide content
-     gets its own scroll container, nothing else has to give" rule DataTable's
-     `.fd-table-wrap` already follows (and the layout auditor already treats an
-     `overflow: auto` ancestor as fine by design). A phone-width row keeps every figure
-     reachable, one swipe away, rather than losing it or drifting out of line with the
-     total it belongs under. */
+  /* MP-114 (second follow-up). The first follow-up kept every `.fd-erow-cell` at its
+     exact fixed `--erow-metric-w` down here (never `width: auto` — see the alignment
+     argument in EntityRowMetrics/.fd-erow-metrics's own comments above, which this
+     still honours) and let `.fd-erow-metrics` scroll instead of clip when the strip ran
+     out of room. That satisfied the alignment contract, but media-planner's
+     audience-list-affordances.spec.ts (375px, touch) caught what it traded away: a
+     scrollable strip still HIDES figures behind a scroll a touch user has no reason to
+     discover, which the spec's `stripClipsNothing` check treats as no better than
+     clipping — at phone width every figure has to be actually, fully visible.
+
+     The real room was never in the strip itself — it was in the REST of the row.
+     EntityRow is `title (+ titleIcon/meta)` above `metrics (+ accessory)` beside
+     `action`, with a drag grip down the side: at desktop width that two-line-plus-rail
+     shape is what lets metrics and a school's name and its preference-meter accessory
+     and its +/- action all fit on a compact row. At a stacked phone pane that shape is
+     the problem — cramming metrics onto the SAME line as an accessory (media-planner's
+     TransferList rows carry a ScoreMeter accessory) leaves the strip a fraction of the
+     row's own width even though the row has plenty of width overall.
+
+     So below this width the row becomes a two-row GRID instead: name (+ its icon/meta)
+     with the accessory and the +/- action all on row one, and the metric strip ALONE
+     spanning the full row width on row two — the same width `.fd-tlist-footer`'s totals
+     line gets (see below), which is what keeps the two aligned. `.fd-erow-body` and
+     `.fd-erow-strip` contribute no box of their own any more here (`display: contents`
+     unwraps them, MDN's own documented way to let a grid reach through a wrapper
+     without changing the component's DOM/JSX) — every element that actually needs a
+     grid position (title line, grip, accessory, metrics, action) becomes a direct
+     grid child by that unwrapping alone. `grid-template-areas` uses one row with no
+     "strip" cell in it for a plain row that has neither metrics nor an accessory (an
+     unfilled `auto` grid row is 0-height), so a name-only row still stays one line
+     tall exactly as `.fd-erow-body`'s own base-rule comment describes.
+
+     Even spanning the full row, three columns this wide (media-planner: 96/82/92px)
+     can still be tight once the row also loses width to its drag grip and a 44px
+     touch-target action button — so `--erow-metric-w` itself also shrinks by a flat,
+     modest 15% here, identically for a row's own cells and the totals footer's (both
+     read the SAME custom property, so both shrink the same and stay aligned). 15% is a
+     deliberate buffer, not a measured minimum: it keeps real figures (media-planner's
+     own test data reaches "958,000") comfortably clear of `.fd-erow-metric-value`'s
+     own `text-overflow: ellipsis` floor rather than sizing to the exact edge of it. */
+  .fd-erow {
+    display: grid;
+    grid-template-columns: auto minmax(0, 1fr) auto auto;
+    grid-template-areas:
+      "grip title accessory action"
+      "strip strip strip strip";
+    /* Row-gap is a new number (there was no vertical gap to preserve — the old
+       layout never had two grid rows), but the column-gap is the same --erow-gap
+       the wide flex row uses, not a second literal 10px that could drift from it. */
+    gap: 4px var(--erow-gap);
+  }
+  .fd-erow-body,
+  .fd-erow-strip {
+    display: contents;
+  }
+  .fd-erow-grip {
+    grid-area: grip;
+  }
+  .fd-erow-titleline {
+    grid-area: title;
+  }
+  .fd-erow-accessory {
+    grid-area: accessory;
+  }
+  .fd-erow-action {
+    grid-area: action;
+  }
   .fd-erow-cell {
     flex-shrink: 0;
+    width: calc(var(--erow-metric-w) * 0.85);
   }
   .fd-erow-metrics {
+    /* Row context (.fd-erow is the grid above): claims the whole second grid row.
+       Footer context (.fd-tlist-footer is a plain flex row, see below): `grid-area`
+       is a no-op there since its parent isn't a grid, and `flex: 1 1 100%` is what
+       does the equivalent job — combined with that flex row's own `flex-wrap: wrap`,
+       claiming the full line pushes the "Totals · N schools" caption after it onto
+       a second line, the same shape the row now has. Only one of the two rules ever
+       actually applies in a given parent, so both can live on this one selector. */
+    grid-area: strip;
+    flex: 1 1 100%;
+    /* Belt-and-suspenders, not the primary mechanism any more: if some OTHER
+       consumer's columns still don't fit even the whole row's width after the 15%
+       reduction above, this scrolls that overflow rather than clipping it (the same
+       "wide content gets its own scroll container" rule DataTable's `.fd-table-wrap`
+       follows, and the layout auditor already treats an `overflow: auto` ancestor as
+       fine by design) — never reached by media-planner's own audience columns, which
+       the full-width row and the 15% reduction together already fit. */
     overflow-x: auto;
     overflow-y: hidden;
   }
+  .fd-tlist-footer {
+    flex-wrap: wrap;
+    /* The wide-width padding-left (see the base rule's own comment) indents the
+       totals strip to where a row's metric strip used to start: AFTER the card border,
+       the row's own padding, the drag grip and its gap. Down here the row's strip no
+       longer starts there — it's `.fd-erow`'s own full-width second grid row (see
+       `.fd-erow`'s own comment above), which starts at the row's own left padding
+       edge, before the grip rather than after it. audience-builder.spec.ts caught the
+       mismatch this left behind: a row's strip and the totals strip 24px apart at the
+       SAME breakpoint that made the grid switch active in the first place (any
+       TransferList pane under 600px, which an ordinary 1280px desktop window reaches
+       easily — see that rule's own comment). The totals strip needs the SAME new
+       origin: just the card's border and the row's own padding, with the grip/gap
+       terms dropped since they no longer apply to either strip — both terms of the
+       SAME --erow-* properties (.fd-tlist's own comment) the base rule below uses,
+       not separately-guessed numbers, so the two can't drift apart again. */
+    padding-left: calc(var(--erow-border-w) + var(--erow-pad-x));
+  }
 }
 .fd-tlist-side {
   flex: 1;
@@ -4346,32 +4579,6 @@ button.fd-erow-metric:focus-visible {
   box-shadow: var(--e-2);
   color: var(--brand);
 }
-/* TransferList's per-side slots. The footer is where a running totals line goes;
-   it sits on the panel, not on a card, and is separated by a rule rather than a
-   gap so it reads as a summary OF the list rather than another row IN it. */
-.fd-tlist-header {
-  display: flex;
-  align-items: center;
-  gap: 8px;
-  min-width: 0;
-}
-.fd-tlist-footer {
-  display: flex;
-  align-items: center;
-  gap: 10px;
-  min-width: 0;
-  padding-top: 8px;
-  /* Indented to the x a row's own body starts at, so a totals strip in here lands
-     under the columns it totals rather than a card's width to the left of them.
-     The sum is the card's border and padding-left plus the drag grip and its gap
-     — every row in a TransferList is a drag source, so it is the same on all of
-     them. Spelled out rather than collapsed to 37px so it stays checkable against
-     .fd-erow if that padding ever moves. */
-  padding-left: calc(1px + 12px + 14px + 10px);
-  border-top: 1px solid var(--border);
-  font-size: var(--overline-size);
-  color: var(--text-2);
-}
 
 /* --- ScoreMeter — a small categorical 0-100 bar, optionally a trigger ------ */
 .fd-scoremeter {

package/styles/tokens.css

@@ -100,6 +100,20 @@
   --btn-solid-ok-bg:#1E7A4C;--btn-solid-ok-bg-hover:#18663F;--btn-solid-ok-bg-active:#145A38;--btn-solid-ok-ink:#FFFFFF;
   --btn-solid-danger-bg:#B93A31;--btn-solid-danger-bg-hover:#9E2F27;--btn-solid-danger-bg-active:#862720;--btn-solid-danger-ink:#FFFFFF;
 
+  /* Soft icon button (IconButton variant="soft") — MP-52's "lighter fill, darker border"
+     row action. A lighter, less saturated fill than --btn-solid-* with a visibly darker
+     border drawn around it, so the button still reads as a button rather than a solid
+     colour chip. Measured exactly like --btn-solid-* above, against the same two grounds
+     (--surface-2 #F7F8FA and --erow-danger-fill #FCE9E6): white ink on the fill is 4.53:1
+     or better and the fill itself is 3.87:1 or better against either ground. Going any
+     lighter breaks one of those two floors — a fill light enough to read as "soft" in the
+     usual badge sense (e.g. --ok-fill/--danger-fill) is only ~1.05:1 from --erow-danger-fill
+     and fails outright; this is the lightest fill that still clears the bar next to a red
+     row. The border reuses the darker --btn-solid-*-bg-active token, 1.8-2:1 off the new
+     fill and 7:1+ off both grounds, so it reads even where hue alone would not. */
+  --btn-soft-ok-bg:#557F6A;--btn-soft-ok-border:#145A38;--btn-soft-ok-ink:#FFFFFF;
+  --btn-soft-danger-bg:#C84E43;--btn-soft-danger-border:#862720;--btn-soft-danger-ink:#FFFFFF;
+
   --ok-fill:#DFF3E8;--ok-border:#A8DDC2;--ok-text:#0E5233;--ok-solid:#34A26B;--ok-emph:#57C68C;
   --warn-fill:#FDF1DA;--warn-border:#F0D49A;--warn-text:#6B4A05;--warn-solid:#C8890B;
   --danger-fill:#FCE7E5;--danger-border:#F2BDB8;--danger-text:#7A241D;--danger-solid:#D0473D;
@@ -256,6 +270,19 @@
   --btn-solid-ok-bg:#3FB37A;--btn-solid-ok-bg-hover:#57C68C;--btn-solid-ok-bg-active:#35A26D;--btn-solid-ok-ink:#0B2A1B;
   --btn-solid-danger-bg:#E8776D;--btn-solid-danger-bg-hover:#F08A80;--btn-solid-danger-bg-active:#D9685E;--btn-solid-danger-ink:#2A0B08;
 
+  /* Soft icon button — see the :root block above. On dark ground the direction flips the
+     same way --btn-solid-* already does: a lighter fill cannot separate from a near-black
+     card by luminance, so the soft fill goes DARKER and saturated (not lighter, the way
+     light theme reads "lighter") with a light ink and a lighter border drawn around it —
+     the same "still a button, one step down from --btn-solid-*" relationship, expressed in
+     whichever direction actually clears the floor on this ground. Measured against
+     --surface-2 (#1B1F27) and --erow-danger-fill (#331813): white ink is 5.4:1 or better,
+     the fill is 3.0:1 or better against either ground, and the border (the theme's own
+     --btn-solid-*-bg, already proven legible here) is 1.9:1+ off the fill and 5.7:1+ off
+     both grounds. */
+  --btn-soft-ok-bg:#007A3D;--btn-soft-ok-border:#3FB37A;--btn-soft-ok-ink:#FFFFFF;
+  --btn-soft-danger-bg:#D41200;--btn-soft-danger-border:#E8776D;--btn-soft-danger-ink:#FFFFFF;
+
   /* chat kit — see the :root block above */
   --chat-code-bg:#12151B;
   --code-kw:#B3A6F0;--code-str:#E9C377;--code-num:#EFA8BE;--code-com:#6C7686;