@bicharts/chart-host 0.5.69 → 0.5.71

package/dist/index.mjs

@@ -640,8 +640,8 @@ function launchGenerates(outcome) {
 function launchFavorStyle(outcome, autoSentinel) {
   return outcome.kind === "pick" ? outcome.chartType : autoSentinel;
 }
-var CHOOSER_MIN_WIDTH_PX = 400;
-var CHOOSER_MIN_HEIGHT_PX = 240;
+var CHOOSER_MIN_WIDTH_PX = 320;
+var CHOOSER_MIN_HEIGHT_PX = 220;
 function chooserFitsViewport(width, height) {
   if (!isFinite(width) || !isFinite(height)) return false;
   return width >= CHOOSER_MIN_WIDTH_PX && height >= CHOOSER_MIN_HEIGHT_PX;

package/dist/types/qualifyFilter.d.ts

@@ -105,14 +105,11 @@ export declare const FILTER_ROW_PX = 32;
  * THE SMALLEST CARD THE FILTER BOX IS USABLE IN - measured 2026-09-03, and NOT arithmetic off
  * `CHOOSER_MIN_*`.
  *
- * The chooser's own floor (400 x 240) was measured with three pinned elements. The filter row is
- * a FOURTH, in a card that clips, so the old envelope does not survive the addition and could not
- * be adjusted by adding 32px to it - the coupling between the two dimensions moves too.
+ * The chooser's floor was measured with three pinned elements. The filter row is a FOURTH, in a
+ * card that clips, so that envelope does not survive the addition and could not be adjusted by
+ * adding 32px to it - the coupling between the two dimensions moves too.
  *
- * Same harness as the 2026-09-01 chooser sweep, re-run over 195 sizes with the row present. The
- * run reproduces the chooser's published coupling exactly when the row is hidden (320-340 wide
- * needs 280 tall, 360-380 needs 260, 400+ needs 220), which is what says the harness is measuring
- * the same card and not a different one.
+ * Same harness as the 2026-09-01 chooser sweep, re-run over 195 sizes with the row present.
  *
  * ONE CRITERION IS TIGHTER, and it is the reason this is a separate floor rather than a bigger
  * version of the old one: the chooser sweep asked for TWO visible list rows, this asks for
@@ -126,6 +123,28 @@ export declare const FILTER_ROW_PX = 32;
  * height for the reason `CHOOSER_MIN_*` states: the measurement used one font stack and one
  * string, every host localizes the title, and a longer translation wraps sooner than the sample.
  *
+ * ⚠ THIS FLOOR INHERITED THE CHOOSER SWEEP'S DEFECT, AND HAS NOT BEEN RE-MEASURED (2026-09-04).
+ * This comment used to argue that reproducing the chooser's published coupling when the row is
+ * hidden (320-340 wide needs 280 tall, 360-380 needs 260, 400+ needs 220) proved the harness was
+ * measuring the same card. It proved the two sweeps SHARED A CARD, which is a different claim,
+ * and the re-measure behind `CHOOSER_MIN_*` shows the card they shared was not the one the
+ * product draws: rows were sized without the DESCRIPTION each one carries, so a row measured
+ * ~22px against a real 48. Every "N visible rows" number on both sweeps is therefore about twice
+ * as generous as the screen, and this floor's criterion is the tighter one, so it is the more
+ * affected of the two.
+ *
+ * IT IS LEFT ALONE ON PURPOSE, because the fix is not a re-run. Re-measuring "three visible rows"
+ * against 48px rows pushes this floor past any tile a report actually uses, which would retire a
+ * just-shipped control rather than place it. THE OPEN QUESTION IS THE CRITERION, NOT THE NUMBER:
+ * "three visible rows" was a proxy for "the reader can still skim the list", and on a card whose
+ * rows are twice as tall it no longer describes that. A plausible replacement is its inverse -
+ * offer the filter precisely once the list has STOPPED being skimmable, which is nearer to what
+ * a reader reaches for a filter box for. Settle that before re-deriving this constant.
+ *
+ * NOTE THE FRAME, when comparing the two numbers: this floor is measured on the CARD, and
+ * `CHOOSER_MIN_*` on the CONTAINER. The card is 95% of the container less 32px of padding, so
+ * 420 here is about a 476px tile - the two floors are further apart than the bare numbers read.
+ *
  * ERRING HIGH IS THE CHEAP DIRECTION, exactly as it is for the chooser. Below this floor the
  * reader gets the chooser they have today, unchanged; above it wrongly, they get a clipped
  * control in a card that cannot scroll to reveal it.

package/dist/types/qualifyLaunch.d.ts

@@ -41,25 +41,57 @@ export declare function launchGenerates(outcome: QualifyLaunchOutcome): boolean;
  */
 export declare function launchFavorStyle<T>(outcome: QualifyLaunchOutcome, autoSentinel: T): string | T;
 /**
- * THE SMALLEST TILE THE CHOOSER IS USABLE IN, measured rather than guessed (2026-09-01).
- *
- * A sweep of 168 tile sizes in headless Chromium, rendering the real card DOM and CSS, asking
- * three questions of each: do the three launch buttons sit on one line inside the card, are at
- * least two list rows visible, and is nothing in the pinned chrome clipped. The measured floor
- * is 320 x 220 - but the two dimensions are COUPLED, because under 400 px the card's title
- * wraps to a second line and eats the list's height: at 320-340 wide the height floor rises to
- * 280, at 360-380 to 260, and only at 400+ does 220 hold.
- *
- * 400 x 240 is that envelope with one sweep step of margin on the height. The margin is not
- * decoration: the measurement used one font stack and one string, and every host localizes the
- * title, so a longer translation wraps sooner than the sample did.
- *
- * ERRING HIGH IS THE CHEAP DIRECTION. Below the floor the host generates immediately, which is
- * the behaviour it had before the chooser existed - so a tile wrongly judged too small costs a
- * feature, while one wrongly judged big enough costs a dialog whose buttons are off the card.
+ * THE SMALLEST TILE THE CHOOSER IS USABLE IN, measured rather than guessed - and RE-MEASURED on
+ * 2026-09-04, because the first measurement was taken on a card the product does not draw.
+ *
+ * WHAT THE FIRST SWEEP GOT WRONG (it shipped 400 x 240). It asked three questions of 168 tile
+ * sizes - do the three launch buttons sit on one line inside the card, are at least two list
+ * rows visible, is nothing in the pinned chrome clipped - and found that two rows fit at
+ * 400 x 220. Two rows only fit there if a row is ~22px tall, and a real row is 48: every row
+ * carries its type's DESCRIPTION, which wraps to a second line at any width this dialog will
+ * ever open at. That text has been in the list since 2026-07-11, seven weeks BEFORE the floor
+ * was measured. So the sweep sized the card against a list half the height of the one on
+ * screen, and the coupling it inferred from the wrapping TITLE, though real, is not what binds.
+ *
+ * WHAT THE RE-MEASURE SAYS. 4,050 layouts - 675 sizes (280-520 x 160-420 in 10px steps) x three
+ * description lengths (p25 / p50 / p75 over the 108 active types) x two base font sizes (14 and
+ * 16px) - same DOM, same compiled CSS. The structure is identical at both font sizes:
+ *
+ *     not trapped (buttons on one line, pinned chrome unclipped, card not overflowing)  300 x 190
+ *     >= 1 full list row visible                                                        330 x 330
+ *     >= 2 full list rows visible                          340 x 420, and UNREACHABLE below 410
+ *                                                          wide once a description runs to p75
+ *
+ * 400 x 240 satisfies NEITHER - fifty pixels too tall to be about escapability, ninety too short
+ * to be about legibility. A 400 x 240 tile leaves 77px of list; two rows and their group heading
+ * need 126.
+ *
+ * SO THE FLOOR ANSWERS THE ONLY QUESTION A FLOOR CAN ANSWER HERE: can the reader get out of this
+ * card. The list is `overflow-y: auto` with `min-height: 0` and scrolls at every size, so "how
+ * much of it do I see at once" is not a thing a gate decides - scrolling handles it. What
+ * scrolling cannot handle is a card that CLIPS its own buttons, and that is precisely the pair
+ * of questions that hold from 300 x 190 down.
+ *
+ * 320 x 220 is that floor with one sweep step of margin on both dimensions - and it is also,
+ * exactly, the absolute floor the FIRST sweep reported before inflating it for the coupling.
+ * Two independent measurements agreeing on the escapability floor is the part of the original
+ * that survived. The margin is not decoration: both sweeps used one font stack and one English
+ * title, and every host localizes it.
+ *
+ * THIS IS THE ARGUMENT THE EXCEL PANE ALREADY MAKES, which is why the two hosts now differ by a
+ * card rather than by a philosophy - see shouldOpenInlineChooserOnGenerate below, whose whole
+ * reason for having no size clause is that a scrolling panel cannot trap anyone. The modal's
+ * list scrolls too; its CARD is the part that clips, and this floor is about the card.
+ *
+ * ERRING HIGH IS STILL THE CHEAP DIRECTION where it is genuinely cheap - below the floor the
+ * host generates immediately, which is what it did before this feature existed, so a tile
+ * wrongly judged too small costs a feature while one wrongly judged big enough costs a dialog
+ * with its buttons off the card. What the re-measure changes is the band over which that trade
+ * was being made blind: at 400 x 240 the chooser was withheld from tiles that show MORE of the
+ * list than tiles it was being offered on.
  */
-export declare const CHOOSER_MIN_WIDTH_PX = 400;
-export declare const CHOOSER_MIN_HEIGHT_PX = 240;
+export declare const CHOOSER_MIN_WIDTH_PX = 320;
+export declare const CHOOSER_MIN_HEIGHT_PX = 220;
 /**
  * Is there room to DRAW the chooser here?
  *
@@ -99,13 +131,23 @@ export declare function shouldOpenChooserOnGenerate(i: ChooserGateInput): boolea
  * a card that CLIPS, so past a certain smallness its buttons are simply not on screen and the
  * reader is trapped. A panel that flows inside a scrolling pane, with a wrapping button row,
  * cannot reach that state: swept across 63 pane sizes down to 200x120, every one stayed usable
- * - the footer wrapped from one line to three (38px to 86px) and stayed inside the panel, and
- * the list kept four or more rows because it carries its own max-height and scrolls.
+ * - the footer wrapped from one line to three (38px to 86px) and stayed inside the panel.
+ *
+ * So a size clause here would not protect anybody. Two hosts, two layouts, two honest answers -
+ * written next to each other so the difference reads as a decision rather than as one of them
+ * having forgotten.
+ *
+ * TWO CLAIMS THIS COMMENT USED TO MAKE HAVE BEEN WITHDRAWN (2026-09-04), because the modal's
+ * re-measure discredits the sweep they came from rather than this function:
  *
- * So a size clause here would not protect anybody; it would only switch the feature off for a
- * default task pane, which is narrower than the modal's floor. Two hosts, two layouts, two
- * honest answers - written next to each other so the difference reads as a decision rather than
- * as one of them having forgotten.
+ *   * "a default task pane is narrower than the modal's floor" - it no longer is. The floor moved
+ *     to 320x220 and an ordinary task pane clears it, so the two gates now agree on the pane that
+ *     used to be the whole argument. The asymmetry survives only below the card's drawable
+ *     minimum, which is the only place it ever described something real.
+ *   * "the list kept four or more rows" - measured the same way the modal's rows were, which is
+ *     to say without the DESCRIPTION every row carries. Whatever that number is, it is not four,
+ *     and no claim is made here in its place. It was never the reason for having no size clause:
+ *     the panel scrolls and the footer wraps, and THAT is the reason.
  */
 export declare function shouldOpenInlineChooserOnGenerate(i: {
     enabled: boolean;

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@bicharts/chart-host",
-  "version": "0.5.69",
+  "version": "0.5.71",
   "description": "Run a BIC-generated D3 chart in any web host: compiles the generated render() function, applies the shared option defaults, resolves mark clicks (through tooltip overlays), owns the selection affordance, and translates row indices between cross-filtered charts. The same contract the BIC Power BI visual implements, minus Power BI. React bindings at @bicharts/chart-host/react.",
   "license": "Apache-2.0",
   "type": "module",