@fusion.dev/helix-headless 0.0.0-dev → 0.0.3

package/dist/bar-chart/root/bar-chart-root.d.ts

@@ -6,15 +6,12 @@ declare const HelixHeadlessBarChart_base: typeof HelixElement & (new (...args: a
  * @summary Categories as columns, read from a table.
  *
  * @description
- * The chart most often asked for and the one most often drawn wrongly, so two
- * decisions are made here rather than left to a consumer.
+ * Two decisions are made here rather than left to a consumer.
  *
  * **It measures from zero and there is no property to change that.** A bar's
  * length *is* its value, so a baseline anywhere else makes the lengths
- * proportional to nothing. That is the oldest misleading chart there is, and a
- * design system that ships the switch has shipped the mistake. A reader who
- * wants the differences between values rather than the values should be drawing
- * a line, which claims only a shape.
+ * proportional to nothing. A reader who wants the differences between values
+ * rather than the values should be drawing a line, which claims only a shape.
  *
  * **The labels are HTML beside the drawing rather than `<text>` inside it.** An
  * `<svg>` that fills its box scales everything in it, including type: the same
@@ -26,10 +23,9 @@ declare const HelixHeadlessBarChart_base: typeof HelixElement & (new (...args: a
  * A reader who wants the numbers gets the numbers, not a described picture of
  * them.
  *
- * The properties below are written by this component and read by whoever draws
- * it. A consumer sets none of them: they carry a number this element computed
- * and CSS cannot, which is what lets a stylesheet on this tier draw the thing
- * without measuring anything itself.
+ * The custom properties below are written by this component and read by whoever
+ * draws it. A consumer sets none of them: they carry a number this element
+ * computed and CSS cannot.
  *
  * @since 0.1.0
  * @status experimental
@@ -83,12 +79,11 @@ export declare class HelixHeadlessBarChart extends HelixHeadlessBarChart_base {
      * group, and `both` draws both. Which of those is horizontal turns with
      * `direction`, because a rule belongs to an axis and not to a screen edge.
      *
-     * **A bare `gridlines` means `value`**, and so does anything unrecognised: an
-     * unrecognised value that draws nothing is indistinguishable from the
+     * **A bare `gridlines` means `value`**, and so does anything unrecognized: an
+     * unrecognized value that draws nothing is indistinguishable from the
      * attribute being absent, which is the one thing a reader cannot debug.
      *
-     * `category` is the quieter half of this on a bar chart and is here for
-     * completeness rather than because it is usually right: columns already
+     * `category` is the quieter half of this on a bar chart: columns already
      * divide the categories by being separate columns, and a rule through each
      * one is a second statement of the same fact. It earns its place on a chart
      * of many thin bars, where the eye has stopped counting.
@@ -115,9 +110,7 @@ export declare class HelixHeadlessBarChart extends HelixHeadlessBarChart_base {
      * and the reader has no way to see it happening.
      *
      * A line among columns still measures from zero, because the columns do and
-     * they share the axis. That is the trade for comparability, and it is why
-     * this is a bar chart that can carry a line rather than a line chart that can
-     * carry columns.
+     * they share the axis.
      */
     lines?: string;
     /**
@@ -140,7 +133,7 @@ export declare class HelixHeadlessBarChart extends HelixHeadlessBarChart_base {
      * measured against each other and a reader needs no numbers to do that. With
      * two, a reader has no way of knowing there are two, let alone which series
      * is on which, so both scales are labeled the moment this is set. An
-     * unlabelled second axis is the deceptive case rather than the tidy one.
+     * unlabeled second axis is the deceptive case rather than the tidy one.
      *
      * The grid stays on the primary axis, since a rule measured against two
      * scales at once is a rule that means nothing. The tooltip is unaffected: it
@@ -162,8 +155,7 @@ export declare class HelixHeadlessBarChart extends HelixHeadlessBarChart_base {
      * In `willUpdate` because `direction` is a property a consumer can change at
      * any time, and the controller resolves a reading from whichever axis it was
      * last told about: set once at connect, a chart turned sideways after that
-     * would go on reading x and answer with the same row wherever the pointer
-     * went. That is the bug this pair was written for, one step later.
+     * goes on reading x and answers with the same row wherever the pointer goes.
      *
      * `willUpdate` and not `updated`, because SSR calls the first and not the
      * second, and a value the server and the client disagree about is worse than
@@ -189,13 +181,13 @@ export declare class HelixHeadlessBarChart extends HelixHeadlessBarChart_base {
      * recover either from the picture. So this appears with `secondary` and never
      * without it.
      *
-     * **Beside the plot and not inside it**, which is the second thing this got
-     * wrong. Inside, the numbers are drawn over the drawing, and a horizontal
-     * chart shows it immediately: its value axis runs along the bottom, which is
-     * where the last row of bars is. The vertical case has the same fault and
-     * enough slack to hide it. The plot is also the pointer's catchment and the
-     * tooltip's containing block, both measured from its box, so padding it to
-     * make room would move every reading half an axis to the right.
+     * **Beside the plot and not inside it.** Inside, the numbers are drawn over
+     * the drawing, and a horizontal chart shows it immediately: its value axis
+     * runs along the bottom, which is where the last row of bars is. The vertical
+     * case has the same fault and enough slack to hide it. The plot is also the
+     * pointer's catchment and the tooltip's containing block, both measured from
+     * its box, so padding it to make room would move every reading half an axis
+     * to the right.
      *
      * A column of the host grid instead, which the stylesheet grows only when
      * `secondary` is set. That is what the property reflects for.
@@ -229,8 +221,8 @@ export declare class HelixHeadlessBarChart extends HelixHeadlessBarChart_base {
      * thing by lighting the region the pointer is actually in, and the region is
      * the whole slot, because that is the catchment the pointer resolves against.
      *
-     * Both are kept. The fade separates the active group from its neighbours and
-     * the band says where the neighbourhood is, and on a chart of two categories
+     * Both are kept. The fade separates the active group from its neighbors and
+     * the band says where the neighborhood is, and on a chart of two categories
      * the fade alone is ambiguous about which half is lit.
      */
     protected renderBand(count: number, sideways: boolean): TemplateResult | typeof nothing;

package/dist/bar-chart/root/bar-chart-root.js

@@ -14,15 +14,12 @@ const HEIGHT = 100;
  * @summary Categories as columns, read from a table.
  *
  * @description
- * The chart most often asked for and the one most often drawn wrongly, so two
- * decisions are made here rather than left to a consumer.
+ * Two decisions are made here rather than left to a consumer.
  *
  * **It measures from zero and there is no property to change that.** A bar's
  * length *is* its value, so a baseline anywhere else makes the lengths
- * proportional to nothing. That is the oldest misleading chart there is, and a
- * design system that ships the switch has shipped the mistake. A reader who
- * wants the differences between values rather than the values should be drawing
- * a line, which claims only a shape.
+ * proportional to nothing. A reader who wants the differences between values
+ * rather than the values should be drawing a line, which claims only a shape.
  *
  * **The labels are HTML beside the drawing rather than `<text>` inside it.** An
  * `<svg>` that fills its box scales everything in it, including type: the same
@@ -34,10 +31,9 @@ const HEIGHT = 100;
  * A reader who wants the numbers gets the numbers, not a described picture of
  * them.
  *
- * The properties below are written by this component and read by whoever draws
- * it. A consumer sets none of them: they carry a number this element computed
- * and CSS cannot, which is what lets a stylesheet on this tier draw the thing
- * without measuring anything itself.
+ * The custom properties below are written by this component and read by whoever
+ * draws it. A consumer sets none of them: they carry a number this element
+ * computed and CSS cannot.
  *
  * @since 0.1.0
  * @status experimental
@@ -102,8 +98,7 @@ let HelixHeadlessBarChart = class HelixHeadlessBarChart extends MixinChartSource
      * In `willUpdate` because `direction` is a property a consumer can change at
      * any time, and the controller resolves a reading from whichever axis it was
      * last told about: set once at connect, a chart turned sideways after that
-     * would go on reading x and answer with the same row wherever the pointer
-     * went. That is the bug this pair was written for, one step later.
+     * goes on reading x and answers with the same row wherever the pointer goes.
      *
      * `willUpdate` and not `updated`, because SSR calls the first and not the
      * second, and a value the server and the client disagree about is worse than
@@ -143,9 +138,9 @@ let HelixHeadlessBarChart = class HelixHeadlessBarChart extends MixinChartSource
            growing upward needs `[HEIGHT, 0]`; a bar growing rightward is already
            going the way x counts, so it takes `[0, HEIGHT]`.
          *
-         * Reusing the inverted scale for both was the first version. It put the
-           longest bar at x=0 and every shorter one hard against the right edge,
-           growing away from the baseline instead of out of it. */
+         * Reusing the inverted scale for both puts the longest bar at x=0 and every
+           shorter one hard against the right edge, growing away from the baseline
+           instead of out of it. */
         const domain = [Math.min(0, low), Math.max(0, high)];
         const range = this.direction === 'horizontal' ? [0, HEIGHT] : [HEIGHT, 0];
         const y = linear(domain, range);
@@ -168,13 +163,12 @@ let HelixHeadlessBarChart = class HelixHeadlessBarChart extends MixinChartSource
         /* The second axis wears its series' color when exactly one series is on it,
            which is the case worth helping and the only one a single color can
            describe honestly: with two sharing it, painting the axis either of their
-           colours says it belongs to that one.
+           colors says it belongs to that one.
          *
-           **Written onto the axis and not onto the plot**, which is where it went
-           first and where it did nothing. The axis is the plot's sibling now that it
-           is a column of the host grid, and a custom property inherits down and
-           never sideways. Measured: both axes came out the neutral, which is the
-           same mistake `--donut-chart-stroke` made one component over. */
+           **Written onto the axis and not onto the plot.** The axis is the plot's
+           sibling, being a column of the host grid, and a custom property inherits
+           down and never sideways: written onto the plot, both axes come out the
+           neutral. */
         const lone = series.filter(own);
         const tint = lone.length === 1 && lone[0] !== undefined
             ? `--bar-chart-secondary: var(--chart-series-${seriesIndex(series.indexOf(lone[0]))})`
@@ -192,7 +186,7 @@ let HelixHeadlessBarChart = class HelixHeadlessBarChart extends MixinChartSource
         const slot = 100 / categories.length;
         /* Split first, because the columns share the slot between themselves and a
            line takes none of it. Sized by every series instead, a chart of two
-           columns and one line drew both columns two thirds as wide and left a
+           columns and one line draws both columns two thirds as wide and leaves a
            third of every slot empty, for a mark that is not in the slot at all. */
         const lined = this.lined;
         /* Kept with the index it has among *all* the series, because a column needs
@@ -201,10 +195,10 @@ let HelixHeadlessBarChart = class HelixHeadlessBarChart extends MixinChartSource
            stand shoulder to shoulder with no gap where a line was; `tone` is its
            place in the palette, so it keeps the color the legend gives it.
          *
-           Passing the first for both is what the first version did, and it was
-           visible: with `Target` drawn as a line, `Forecast` moved up into its slot
-           *and* into its color, so a chart of four series painted three columns in
-           the first three colours and the line in the third one as well. */
+           Passing the first for both moves a series into its neighbor's color as
+           well as its slot: with `Target` drawn as a line, a chart of four series
+           paints three columns in the first three colors and the line in the third
+           one as well. */
         const scaled = this.scaled;
         const own = (one) => scaled.has(one.name.trim().toLowerCase());
         /* The scale a series is measured against, resolved once per series rather
@@ -215,12 +209,11 @@ let HelixHeadlessBarChart = class HelixHeadlessBarChart extends MixinChartSource
             .map((one, index) => ({ one, tone: index }))
             .filter(({ one }) => !lined.has(one.name.trim().toLowerCase()));
         /* **The stride is what the columns share and the thickness is what they
-           draw**, and the difference between them is why they had none. Back to
-           back, two columns meet on one coordinate and each one's edge is the
-           other's: an outlined chart showed a single line between them rather than
-           two, and a bar looked as though it were missing a side. A gap is also just
-           the right way to draw a group, which is why the split stays whether
-           anything is outlined or not.
+           draw.** Back to back, two columns meet on one coordinate and each one's
+           edge is the other's: an outlined chart then shows a single line between
+           them rather than two, and a bar looks as though it were missing a side.
+           A gap is also just the right way to draw a group, which is why the split
+           stays whether anything is outlined or not.
     
            Centered in the stride rather than flush against it, so the gap between two
            columns is the same size everywhere and the group sits where it did. One
@@ -229,11 +222,11 @@ let HelixHeadlessBarChart = class HelixHeadlessBarChart extends MixinChartSource
         const gap = columns.length > 1 ? stride * 0.08 : 0;
         const thickness = stride - gap;
         /* **The geometry is computed for the axis it is drawn on, not rotated onto
-           it.** The first version turned the whole plot with `rotate: 90deg`, which
-           is the shorter CSS and does not work: a rotation is about the element's
-           own center, so the drawing left its grid cell entirely and the labels,
-           which are a separate row, stayed where they were. What it produced was
-           one column floating beside a list of names.
+           it.** Turning the whole plot with `rotate: 90deg` is the shorter CSS and
+           does not work: a rotation is about the element's own center, so the
+           drawing leaves its grid cell entirely while the labels, which are a
+           separate row, stay where they were. What that produces is one column
+           floating beside a list of names.
          *
          * Swapping the two axes here costs one branch and keeps every other fact
          * about the chart the same. `value` runs along x when the bars are
@@ -280,11 +273,10 @@ let HelixHeadlessBarChart = class HelixHeadlessBarChart extends MixinChartSource
            tier's: `wash="gradient"` there switches `fill` to
            `--chart-bar-wash` and this is what it would find.
 
-           Coloured through the series property rather than an attribute, so
+           Colored through the series property rather than an attribute, so
            the stops read a token this tier never names. The id resolves
            within the shadow root, so two charts on a page carrying the same
-           ids stay independent, which the sparkline measured before relying
-           on it. */
+           ids stay independent. */
         svg `<defs>
             ${series.map((_, index) => svg `<linearGradient
                 id="helix-bar-wash-${seriesIndex(index)}"
@@ -334,13 +326,13 @@ let HelixHeadlessBarChart = class HelixHeadlessBarChart extends MixinChartSource
      * recover either from the picture. So this appears with `secondary` and never
      * without it.
      *
-     * **Beside the plot and not inside it**, which is the second thing this got
-     * wrong. Inside, the numbers are drawn over the drawing, and a horizontal
-     * chart shows it immediately: its value axis runs along the bottom, which is
-     * where the last row of bars is. The vertical case has the same fault and
-     * enough slack to hide it. The plot is also the pointer's catchment and the
-     * tooltip's containing block, both measured from its box, so padding it to
-     * make room would move every reading half an axis to the right.
+     * **Beside the plot and not inside it.** Inside, the numbers are drawn over
+     * the drawing, and a horizontal chart shows it immediately: its value axis
+     * runs along the bottom, which is where the last row of bars is. The vertical
+     * case has the same fault and enough slack to hide it. The plot is also the
+     * pointer's catchment and the tooltip's containing block, both measured from
+     * its box, so padding it to make room would move every reading half an axis
+     * to the right.
      *
      * A column of the host grid instead, which the stylesheet grows only when
      * `secondary` is set. That is what the property reflects for.
@@ -364,13 +356,6 @@ let HelixHeadlessBarChart = class HelixHeadlessBarChart extends MixinChartSource
           >`)}
     </div>`;
     }
-    /*
-     * The category names, as HTML beside the drawing rather than inside it.
-     *
-     * Inside, they would scale with the box: an `<svg>` that fills its container
-     * scales its type along with everything else, and there is no non-scaling
-     * equivalent for a font the way `vector-effect` is one for a stroke.
-     */
     /**
      * The grid, behind everything, or nothing at all.
      *
@@ -413,8 +398,8 @@ let HelixHeadlessBarChart = class HelixHeadlessBarChart extends MixinChartSource
      * thing by lighting the region the pointer is actually in, and the region is
      * the whole slot, because that is the catchment the pointer resolves against.
      *
-     * Both are kept. The fade separates the active group from its neighbours and
-     * the band says where the neighbourhood is, and on a chart of two categories
+     * Both are kept. The fade separates the active group from its neighbors and
+     * the band says where the neighborhood is, and on a chart of two categories
      * the fade alone is ambiguous about which half is lit.
      */
     renderBand(count, sideways) {
@@ -451,7 +436,7 @@ let HelixHeadlessBarChart = class HelixHeadlessBarChart extends MixinChartSource
             const along = y(point.value);
             return sideways ? [along, across] : [across, along];
         });
-        /* Straight between the category centres, and no `curve` property to change
+        /* Straight between the category centers, and no `curve` property to change
            it. A bar chart's other axis is categorical: there is nothing between
            Gateway and Billing, so a curve through them draws values at positions
            that do not exist and bulges past the readings on the way. `LineChart`

package/dist/breadcrumbs/breadcrumb/breadcrumb.d.ts

@@ -7,12 +7,10 @@ import { type PropertyValues, type TemplateResult } from 'lit';
  * Contributes the separator, the list-item role, and the link itself where one
  * is wanted.
  *
- * **`href` makes the crumb the link.** *Added 19 Aug 2026, reversing the note
- * that said an anchor could not be rendered here.* That note was right that a
- * router cannot reach an anchor inside a shadow root, and wrong that this
- * settles it: the consumer restores the soft navigation by intercepting the
- * click on the way out, which is what `Tree.Item` and `List.Item` both do.
- * What the anchor buys is the whole crumb as a target, Enter, middle click, the
+ * **`href` makes the crumb the link.** A router cannot reach an anchor inside a
+ * shadow root, and the consumer restores the soft navigation by intercepting the
+ * click on the way out, which is what `Tree.Item` and `List.Item` both do. What
+ * the anchor buys is the whole crumb as a target, Enter, middle click, the
  * status bar, and a trail that works before any JavaScript runs.
  *
  * **And the parent needs it.** A trail that collapses has to rebuild its hidden
@@ -62,29 +60,25 @@ export declare class HelixHeadlessBreadcrumb extends HelixElement {
      * the property, rendered the anchor, and left the host looking unlinked: the
      * crumb drew at 20px where a markup twin drew at 28.
      *
-     * *This said the opposite until 27 Aug 2026*, and named the reason as
-     * "nothing selects on it", which was not true when it was written. The
-     * paragraph is worth keeping because the rest of it is right and is what makes
-     * this optional rather than defaulted: an `href` written onto every host would
-     * be a link to the current page on every crumb nobody asked to be one. That is
-     * the general rule as well, that a reflected property takes no default, so the
-     * two agree.
+     * Optional rather than defaulted, which is the general rule that a reflected
+     * property takes no default: an `href` written onto every host would be a link
+     * to the current page on every crumb nobody asked to be one.
      *
-     * Found by the picture comparison rather than by reading: React assigns a
+     * Reading cannot catch this and the picture comparison can. React assigns a
      * matching property instead of an attribute, so every crumb in the React twin
      * of `breadcrumbs/links` lost its padding at once.
      */
     href?: string;
-    /**
-     * Where the link opens, for the rare crumb that leaves the site.
-     */
-    target: string;
     /**
      * What the link declares about where it goes.
      *
      * The consumer's decision.
      */
     rel: string;
+    /**
+     * Where the link opens, for the rare crumb that leaves the site.
+     */
+    target: string;
     protected willUpdate(changed: PropertyValues): void;
     /**
      * The mark between one crumb and the next.

package/dist/breadcrumbs/breadcrumb/breadcrumb.js

@@ -16,12 +16,10 @@ import { unsafeSVG } from 'lit/directives/unsafe-svg.js';
  * Contributes the separator, the list-item role, and the link itself where one
  * is wanted.
  *
- * **`href` makes the crumb the link.** *Added 19 Aug 2026, reversing the note
- * that said an anchor could not be rendered here.* That note was right that a
- * router cannot reach an anchor inside a shadow root, and wrong that this
- * settles it: the consumer restores the soft navigation by intercepting the
- * click on the way out, which is what `Tree.Item` and `List.Item` both do.
- * What the anchor buys is the whole crumb as a target, Enter, middle click, the
+ * **`href` makes the crumb the link.** A router cannot reach an anchor inside a
+ * shadow root, and the consumer restores the soft navigation by intercepting the
+ * click on the way out, which is what `Tree.Item` and `List.Item` both do. What
+ * the anchor buys is the whole crumb as a target, Enter, middle click, the
  * status bar, and a trail that works before any JavaScript runs.
  *
  * **And the parent needs it.** A trail that collapses has to rebuild its hidden
@@ -63,16 +61,16 @@ let HelixHeadlessBreadcrumb = class HelixHeadlessBreadcrumb extends HelixElement
          * Whether this item is the page the reader is on.
          */
         this.current = false;
-        /**
-         * Where the link opens, for the rare crumb that leaves the site.
-         */
-        this.target = '';
         /**
          * What the link declares about where it goes.
          *
          * The consumer's decision.
          */
         this.rel = '';
+        /**
+         * Where the link opens, for the rare crumb that leaves the site.
+         */
+        this.target = '';
     }
     willUpdate(changed) {
         super.willUpdate(changed);
@@ -101,10 +99,9 @@ let HelixHeadlessBreadcrumb = class HelixHeadlessBreadcrumb extends HelixElement
         /* The label and whatever flanks it, which is the same content whether or
            not it is a link. Built once so the two branches below cannot drift. */
         const label = html `<slot name="start"></slot><slot></slot><slot name="end"></slot>`;
-        /* The current page is text, not a link, whatever it was given: linking a
-           page to itself is a known screen-reader annoyance and `aria-current` is
-           what conveys position. So `current` wins over `href` rather than the two
-           contradicting each other in the markup. */
+        /* The current page is text, not a link, whatever it was given, so `current`
+           wins over `href` rather than the two contradicting each other in the
+           markup. */
         const linked = (this.href ?? '') !== '' && !this.current;
         return html `<span part="separator" aria-hidden="true"
         >${this.renderSeparator()}</span
@@ -127,10 +124,10 @@ __decorate([
 ], HelixHeadlessBreadcrumb.prototype, "href", void 0);
 __decorate([
     property()
-], HelixHeadlessBreadcrumb.prototype, "target", void 0);
+], HelixHeadlessBreadcrumb.prototype, "rel", void 0);
 __decorate([
     property()
-], HelixHeadlessBreadcrumb.prototype, "rel", void 0);
+], HelixHeadlessBreadcrumb.prototype, "target", void 0);
 HelixHeadlessBreadcrumb = __decorate([
     customElement('helix-headless-breadcrumb')
 ], HelixHeadlessBreadcrumb);

package/dist/breadcrumbs/root/breadcrumbs-root.d.ts

@@ -15,27 +15,13 @@ import { type PropertyValues, type TemplateResult } from 'lit';
  * Items are slotted rather than wrapped, so they are `<ol>` children in the flat
  * tree and each carries `role="listitem"` itself.
  *
- * **The trail does not measure itself, and the overflow is markup.** It held a
- * `collapse` property, a `ResizeObserver` through `CollapseController`, an
- * `overflowed` getter and a `helix-change` event, all to answer one question:
- * how many crumbs fit. Removed 20 Aug 2026, because the question is the wrong
- * one and answering it cost more than it returned.
- *
- * - **It can never reach the server.** There is no width without a DOM, so the
- *   server shipped every crumb and the client removed some after hydrating. A
- *   trail that collapses therefore painted wrong on every single load, and the
- *   SSR spec asserting "hides no crumb, whatever collapse says" was recording
- *   that as correct behavior rather than as the cost it is.
- * - **The consumer already wrote the crumbs.** The measurement hid some, then
- *   announced which, so that the consumer could read them back off the element
- *   and clone them into menu items. The overflow example spent 32 lines of
- *   JavaScript making a round trip out of data that started in its own markup.
- * - **Nobody specifies a breadcrumb in units of fit.** Designs say "keep the
- *   root and the current page, fold the middle", which is a fact about depth,
- *   or "fold below this width", which is a fact CSS knows. The arithmetic was
- *   the only thing that needed a width, and it was wrong three times in one day:
- *   the observer watched a container that did not exist yet, the gap between
- *   items went uncounted, and the result was still wrong at 34rem.
+ * **The trail does not measure itself, and the overflow is markup.** Measuring
+ * how many crumbs fit can never reach the server: there is no width without a
+ * DOM, so the server ships every crumb and the client removes some after
+ * hydrating, and a trail that collapses paints wrong on every single load. Nor
+ * does anybody specify a breadcrumb in units of fit. Designs say "keep the root
+ * and the current page, fold the middle", which is a fact about depth, or "fold
+ * below this width", which is a fact CSS knows.
  *
  * So the trail lays out crumbs and separators, and the consumer writes what
  * folds: a `helix-menu` of `helix-menu-item`s in a crumb, where the gap
@@ -44,13 +30,8 @@ import { type PropertyValues, type TemplateResult } from 'lit';
  * container query in the consumer's own sheet, which is theirs to write and
  * theirs to leave out.
  *
- * **And the crumbs carry no marker for any of it.** There was an `overflow`
- * property on the crumb, which existed so the controller could tell a control
- * from a step and so the trail could size it. With the controller gone the
- * first use went with it, and the second is better answered by the crumb
- * sizing whatever is slotted into it, which is true of every crumb rather than
- * of one a consumer remembered to mark. What is left is a fact CSS can already
- * see: the crumb with the menu in it is `:has(helix-menu)`, and the middle is
+ * **And the crumbs carry no marker for any of it.** CSS can already see it: the
+ * crumb with the menu in it is `:has(helix-menu)`, and the middle is
  * `:not(:first-child, [current])`. A marker would be the design rule written
  * twice, once in the HTML and once in the sheet, with nothing keeping the two
  * honest.

package/dist/breadcrumbs/root/breadcrumbs-root.js

@@ -21,27 +21,13 @@ import { html } from 'lit';
  * Items are slotted rather than wrapped, so they are `<ol>` children in the flat
  * tree and each carries `role="listitem"` itself.
  *
- * **The trail does not measure itself, and the overflow is markup.** It held a
- * `collapse` property, a `ResizeObserver` through `CollapseController`, an
- * `overflowed` getter and a `helix-change` event, all to answer one question:
- * how many crumbs fit. Removed 20 Aug 2026, because the question is the wrong
- * one and answering it cost more than it returned.
- *
- * - **It can never reach the server.** There is no width without a DOM, so the
- *   server shipped every crumb and the client removed some after hydrating. A
- *   trail that collapses therefore painted wrong on every single load, and the
- *   SSR spec asserting "hides no crumb, whatever collapse says" was recording
- *   that as correct behavior rather than as the cost it is.
- * - **The consumer already wrote the crumbs.** The measurement hid some, then
- *   announced which, so that the consumer could read them back off the element
- *   and clone them into menu items. The overflow example spent 32 lines of
- *   JavaScript making a round trip out of data that started in its own markup.
- * - **Nobody specifies a breadcrumb in units of fit.** Designs say "keep the
- *   root and the current page, fold the middle", which is a fact about depth,
- *   or "fold below this width", which is a fact CSS knows. The arithmetic was
- *   the only thing that needed a width, and it was wrong three times in one day:
- *   the observer watched a container that did not exist yet, the gap between
- *   items went uncounted, and the result was still wrong at 34rem.
+ * **The trail does not measure itself, and the overflow is markup.** Measuring
+ * how many crumbs fit can never reach the server: there is no width without a
+ * DOM, so the server ships every crumb and the client removes some after
+ * hydrating, and a trail that collapses paints wrong on every single load. Nor
+ * does anybody specify a breadcrumb in units of fit. Designs say "keep the root
+ * and the current page, fold the middle", which is a fact about depth, or "fold
+ * below this width", which is a fact CSS knows.
  *
  * So the trail lays out crumbs and separators, and the consumer writes what
  * folds: a `helix-menu` of `helix-menu-item`s in a crumb, where the gap
@@ -50,13 +36,8 @@ import { html } from 'lit';
  * container query in the consumer's own sheet, which is theirs to write and
  * theirs to leave out.
  *
- * **And the crumbs carry no marker for any of it.** There was an `overflow`
- * property on the crumb, which existed so the controller could tell a control
- * from a step and so the trail could size it. With the controller gone the
- * first use went with it, and the second is better answered by the crumb
- * sizing whatever is slotted into it, which is true of every crumb rather than
- * of one a consumer remembered to mark. What is left is a fact CSS can already
- * see: the crumb with the menu in it is `:has(helix-menu)`, and the middle is
+ * **And the crumbs carry no marker for any of it.** CSS can already see it: the
+ * crumb with the menu in it is `:has(helix-menu)`, and the middle is
  * `:not(:first-child, [current])`. A marker would be the design rule written
  * twice, once in the HTML and once in the sheet, with nothing keeping the two
  * honest.