@flytedan/flytebot-design-system 0.49.2 → 0.50.0

package/package.json

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

package/styles/components.css

@@ -2052,6 +2052,14 @@
   color: var(--text);
   vertical-align: middle;
 }
+/* SMS-50: a link-variant Button in a cell (a name that acts on its row) is text, not a control:
+   it wraps like the text around it and reads left-aligned. A Button on its own never wraps
+   (`white-space: nowrap`), so a long name kept its row on one line and stretched the table
+   past its card. */
+.fd-table td .fd-btn-link {
+  white-space: normal;
+  text-align: left;
+}
 .fd-table td.is-num {
   text-align: right;
   font-variant-numeric: tabular-nums lining-nums;
@@ -2965,22 +2973,67 @@
   transform: rotate(180deg);
 }
 
-/* ============ FilterBar (MP-243) ============ */
-/* The bar itself: a wrapping row of chips plus the trailing "Filter" trigger. Kept as its
-   own class (rather than composing .fd-row/.fd-wrap utilities) because inline-flex, not
-   flex, is load-bearing here — a consumer drops FilterBar into a toolbar row alongside
-   other inline elements, and a flex (block-level) root would claim the full row width. */
+/* ============ FilterBar (MP-243, SMS-50) ============ */
+/* The bar is two columns on one wrapping row: the MAIN column, which is the "Filter" trigger
+   (its own column, always first) beside the chips (a wrapping area of their own, taking the room
+   left over), and an optional `actions` slot pinned to the right edge (`margin-left: auto`).
+   The columns top-align, so however many lines the chips wrap onto, the trigger and the actions
+   never move. The main column never wraps its two children under each other, at any width; when
+   the row is too narrow for main and actions together (main keeps a floor of
+   --filterbar-main-min), the actions wrap onto a row of their own and stay right-aligned.
+
+   It is a block-level flex box that fills the row it is put in, and `min-width: 0` lets it
+   shrink inside a flex parent instead of forcing that parent wider. (Until SMS-50 it was
+   inline-flex with `max-width: 100%`: an inline-flex box's shrink-to-fit width comes from its
+   UNWRAPPED content, so wrapping only worked once something capped it. A block-level flex box
+   takes its width from its container, which is what makes wrapping, and the chips column's
+   own width, well defined.) */
 .fd-filterbar {
-  display: inline-flex;
+  --filterbar-main-min: 20rem;
+  /* The most a chip may take. A longer value is shortened in the middle (MiddleEllipsis). */
+  --filterbar-chip-max: 15rem;
+  display: flex;
+  flex: 1 1 auto;
+  flex-wrap: wrap;
+  align-items: flex-start;
+  gap: var(--s-sm) var(--s-md);
+  min-width: 0;
+}
+.fd-filterbar-main {
+  flex: 1 1 var(--filterbar-main-min);
+  min-width: 0;
+  display: flex;
+  align-items: flex-start;
+  gap: var(--s-sm) var(--s-md);
+}
+/* A bar with nothing to show in it (no Filter button, no chips: the options have not loaded yet)
+   gives up its main column entirely, so the actions are not pushed onto a row of their own by a
+   column that holds nothing. */
+.fd-filterbar-main:not(:has(.fd-filterbar-trigger, .fd-tag)) {
+  display: none;
+}
+.fd-filterbar-trigger {
+  flex: none;
+}
+.fd-filterbar-chips {
+  flex: 1 1 0;
+  min-width: 0;
+  display: flex;
   flex-wrap: wrap;
   align-items: center;
+  align-content: center;
   gap: var(--s-sm);
-  /* MP-243: an inline-flex box's shrink-to-fit width is computed from its UNWRAPPED
-     content first — flex-wrap only kicks in once something already caps the box's own
-     width, which an inline-flex element does not get for free from its containing block
-     the way a block-level flex does. Without this, enough chips run the bar past the
-     viewport edge instead of wrapping onto a second line, at any width narrow enough to
-     matter (found opening three fields' chips on a 375px viewport). */
+  /* One chip row centres on the Filter button (a control-h-md button) beside it. */
+  min-height: var(--control-h-md);
+}
+.fd-filterbar-actions {
+  flex: none;
+  margin-left: auto;
+  display: flex;
+  flex-wrap: wrap;
+  align-items: flex-start;
+  justify-content: flex-end;
+  gap: var(--s-sm) var(--s-md);
   max-width: 100%;
 }
 /* MP-282: seen live at 375px — a chip whose value is long (a full campaign name) painted
@@ -2994,26 +3047,19 @@
    short, already-bounded-by-their-own-layout content where this bug was never observed and
    a forced max-width + ellipsis would only truncate text that fits today for no reason.
 
-   A `max-width: 100%` on `.fd-tag` ALONE does nothing here — tried first, and it left the
-   chip at its full 633px (proven by this card's own failing-first browser test): the actual
-   flex item .fd-filterbar-chip wraps `.fd-tag` in for select/multiSelect/range/date's chip
-   (the extra <span> FilterBar.tsx keeps around so React preserves one stable DOM node across
-   the editing/non-editing transition — see FilterBar.tsx's own comment on it) has `width:
-   auto` (shrink-to-fit) with a default `min-width: auto`, which for non-wrapping text (`.fd-
-   tag`'s inherited `white-space: nowrap`) equals the label's full intrinsic width — so the
-   flex algorithm's shrink never actually engages, `.fd-filterbar-chip` sizes itself to fit
-   the (unclamped) content, and a percentage `max-width` on the button THEN resolves against
-   that same content-derived size: a circular dependency (CSS2.1 §10.2's "if the containing
-   block's width depends on this element's width... the resulting layout is undefined"),
-   which real browsers resolve by ignoring the percentage rather than clamping anything.
-   `min-width: 0` on the actual flex item is what breaks the cycle: it lets the shrink
-   algorithm bring `.fd-filterbar-chip` down to whatever room is actually left in the row —
-   a value the flex layout itself computes from `.fd-filterbar`'s own (non-circular, genuinely
-   definite once its own ancestor has a real width) size — and ONLY once that ancestor box has
-   a real, non-content-derived width does `.fd-tag`'s `max-width: 100%` below have anything
-   sound to resolve against. */
+   The bound goes on .fd-filterbar-chip, the actual flex item of the chips column (the extra
+   <span> FilterBar.tsx wraps `.fd-tag` in for select/multiSelect/range/date's chip, so React
+   keeps one stable DOM node across the editing/non-editing transition). A percentage
+   `max-width` on the button ALONE does nothing: this item's own width is shrink-to-fit
+   (`auto`) with a default `min-width: auto`, which for non-wrapping text equals the label's
+   full intrinsic width, so the percentage would resolve against a size derived from the very
+   content it is meant to clamp (CSS2.1 §10.2: undefined; real browsers ignore it).
+   `min-width: 0` on the flex item breaks that cycle, and `max-width` here is a plain length
+   bounded by the row, so the chip is never wider than --filterbar-chip-max nor than the row
+   it wraps in (SMS-50: was "the row" only, so a long value ran the whole row wide). */
 .fd-filterbar-chip {
   min-width: 0;
+  max-width: min(100%, var(--filterbar-chip-max));
 }
 .fd-filterbar .fd-tag {
   max-width: 100%;
@@ -3021,21 +3067,32 @@
 }
 /* Tag.tsx always wraps its children in this span (see Tag.tsx's own MP-282 comment) so
    there is something block-level (flex items are blockified, .fd-tag is inline-flex) to
-   hang `text-overflow: ellipsis` off. Unscoped, this rule would do nothing: no width is
-   ever constrained on a bare .fd-tag-label outside FilterBar, so there is nothing for
-   `white-space: nowrap` (inherited from .fd-tag either way) to need to ellipsise — a Tag
-   used anywhere else keeps exactly its current look. `min-width: 0` is the same override
-   as above, needed a second time because this label is itself a flex item of .fd-tag. The
-   full text stays as this span's actual text content regardless of the visual ellipsis —
-   that's what keeps the button's accessible name (computed from content, not from what's
-   painted) the whole value; Tag's `title` prop (FilterBar passes the same full value)
+   hang the ellipsis off. `min-width: 0` is needed because this label is itself a flex item
+   of .fd-tag. The full text stays as the label's actual text content regardless of what is
+   painted — that's what keeps the button's accessible name (computed from content, not from
+   what's painted) the whole value; Tag's `title` prop (FilterBar passes the same full value)
    covers the hover-tooltip half of that same requirement. */
 .fd-filterbar .fd-tag-label {
   overflow: hidden;
-  text-overflow: ellipsis;
   white-space: nowrap;
   min-width: 0;
 }
+/* MiddleEllipsis (SMS-50): the head shrinks and ends in "…"; the tail never shrinks, so the end
+   of a long value stays visible ("Flytedesk Spr…ement (na)"). `white-space: pre` keeps a space
+   at the seam between the two spans, which a flex item would otherwise strip. */
+.fd-mid-ellipsis {
+  display: flex;
+  min-width: 0;
+  white-space: pre;
+}
+.fd-mid-ellipsis-head {
+  min-width: 0;
+  overflow: hidden;
+  text-overflow: ellipsis;
+}
+.fd-mid-ellipsis-tail {
+  flex: none;
+}
 /* The text field's own inline "chip that is also an input" — its editing state reuses
    .fd-tag's box but swaps in the selected/brand treatment .fd-tag[aria-pressed] already
    defines elsewhere, and the raw <input> inside is stripped of its own chrome so it reads
@@ -3897,9 +3954,11 @@
   stroke: var(--border-strong);
   stroke-width: 1;
 }
+/* SMS-50: 10px, and it stays 10px — TrendChart draws its SVG in real pixels at the container's
+   width (viewBox === rendered size), so this is what paints, never multiplied by the card. */
 .fd-trend-axis-label {
   fill: var(--text-muted);
-  font-size: 10.5px;
+  font-size: 10px;
   font-family: var(--font-sans);
 }
 .fd-trend-line {