@fusion.dev/helix 0.33.5 → 0.34.1

package/custom-elements.json

@@ -131881,6 +131881,20 @@
                 "module": "src/tree/root/tree-root.ts"
               }
             },
+            {
+              "kind": "field",
+              "name": "nesting",
+              "type": {
+                "text": "'heading' | 'peer' | 'subordinate' | undefined"
+              },
+              "description": "What a step inward means: nothing, a rank, or a heading over what follows.\n\nAll three answers are right, for different trees, which is why this is\nasked rather than decided. `peer` is a file explorer: every row is the same\nkind of thing, a name that may hold more names, and the indent alone says\nwhere one sits. `subordinate` is side navigation or a categorization: a\nsection holds pages and a facet holds values, so a step inward is a change\nof kind and the rows say so. `heading` is a documentation sidebar, where\nthe change is at the *parent*: \"Getting started\" is not a lesser page than\nthe pages under it and not a page at all, it is the name of the list, so\nthe branch takes the rail-heading treatment and its children stay at the\nsize every other row is.\n\n`subordinate` and `heading` are not the same answer said twice. One keys on\ndepth and quiets the child; the other keys on holding children and relabels\nthe parent, so a top-level leaf beside a branch is untouched by the first\nand untouched by the second for opposite reasons.\n\nOn the root rather than the item, because it is a fact about the tree. Set\nper row it would make a tree writable in which one branch ranks its\nchildren and the next does not, and it would have to be repeated on every\nrow to say one thing.\n\nHere rather than on the styled tier, because it is not about paint: with\nevery stylesheet deleted it is still true that this tree ranks its depths,\nthat this one heads them, and that a file explorer does neither. The styled\ntier steps a subordinate row once down the type scale and sets a heading\nbranch as a label; a headless consumer reads the attribute and the\n`--tree-level` each row carries, and draws either however they like.\n\n**Optional, with no default**, per the reflected-property rule: a value\nwritten here appears in the served markup of every tree anybody renders.\nThe resting state is the absence of the attribute, which is `peer`.",
+              "attribute": "nesting",
+              "reflects": true,
+              "inheritedFrom": {
+                "name": "HelixHeadlessTree",
+                "module": "src/tree/root/tree-root.ts"
+              }
+            },
             {
               "kind": "field",
               "name": "watcher",
@@ -132465,6 +132479,18 @@
                 "name": "HelixHeadlessTree",
                 "module": "src/tree/root/tree-root.ts"
               }
+            },
+            {
+              "name": "nesting",
+              "type": {
+                "text": "'heading' | 'peer' | 'subordinate' | undefined"
+              },
+              "description": "What a step inward means: nothing, a rank, or a heading over what follows.\n\nAll three answers are right, for different trees, which is why this is\nasked rather than decided. `peer` is a file explorer: every row is the same\nkind of thing, a name that may hold more names, and the indent alone says\nwhere one sits. `subordinate` is side navigation or a categorization: a\nsection holds pages and a facet holds values, so a step inward is a change\nof kind and the rows say so. `heading` is a documentation sidebar, where\nthe change is at the *parent*: \"Getting started\" is not a lesser page than\nthe pages under it and not a page at all, it is the name of the list, so\nthe branch takes the rail-heading treatment and its children stay at the\nsize every other row is.\n\n`subordinate` and `heading` are not the same answer said twice. One keys on\ndepth and quiets the child; the other keys on holding children and relabels\nthe parent, so a top-level leaf beside a branch is untouched by the first\nand untouched by the second for opposite reasons.\n\nOn the root rather than the item, because it is a fact about the tree. Set\nper row it would make a tree writable in which one branch ranks its\nchildren and the next does not, and it would have to be repeated on every\nrow to say one thing.\n\nHere rather than on the styled tier, because it is not about paint: with\nevery stylesheet deleted it is still true that this tree ranks its depths,\nthat this one heads them, and that a file explorer does neither. The styled\ntier steps a subordinate row once down the type scale and sets a heading\nbranch as a label; a headless consumer reads the attribute and the\n`--tree-level` each row carries, and draws either however they like.\n\n**Optional, with no default**, per the reflected-property rule: a value\nwritten here appears in the served markup of every tree anybody renders.\nThe resting state is the absence of the attribute, which is `peer`.",
+              "fieldName": "nesting",
+              "inheritedFrom": {
+                "name": "HelixHeadlessTree",
+                "module": "src/tree/root/tree-root.ts"
+              }
             }
           ],
           "superclass": {
@@ -132505,6 +132531,10 @@
                 "description": "A node told its own depth, for a tree built from a flat list rather than by nesting.",
                 "slug": "flattened"
               },
+              {
+                "description": "Depth as a position, depth as a rank, and a branch that is a heading.",
+                "slug": "nesting"
+              },
               {
                 "description": "The same tree with a glyph on each node.",
                 "slug": "with-icons"

package/dist/tree/item/tree-item.css.js

@@ -18,7 +18,7 @@ color: var(--helix-color-foreground-muted);
 cursor: pointer;
 display: flex;
 
-font-size: var(--helix-text-sm);
+font-size: var(--_tree-text, var(--helix-text-sm));
 gap: var(--helix-space-2xs);
 
 margin-block-end: var(--tree-gap, var(--helix-space-2xs));
@@ -50,13 +50,20 @@ var(--_tree-reserve, calc(var(--_tree-chevron) + var(--helix-space-2xs)))
 }
 
 [part="row"]:has([part="toggle"]) {
+color: var(--_tree-heading-ink, var(--helix-color-foreground-muted));
+font-size: var(--_tree-heading-text, var(--_tree-text, var(--helix-text-sm)));
 font-weight: var(--helix-weight-medium);
+letter-spacing: var(--_tree-heading-tracking, var(--helix-tracking-normal));
 }
 
 [part="row"]:not(:has([part="toggle"])) {
 font-weight: var(--helix-weight-medium);
 }
 
+slot[name="children"]::slotted(*) {
+--_tree-text: var(--_tree-nested-text, var(--helix-text-sm));
+}
+
 [part="row"]:hover {
 background-color: var(--helix-color-surface-raised);
 color: var(--helix-color-foreground);

package/dist/tree/root/tree-root.css.js

@@ -20,6 +20,16 @@ flex-direction: column;
 --_tree-reserve: var(--helix-space-none);
 }
 
+:host([nesting="subordinate"]) {
+--_tree-nested-text: var(--helix-text-xs);
+}
+
+:host([nesting="heading"]) {
+--_tree-heading-ink: var(--helix-color-foreground-subtle);
+--_tree-heading-text: var(--helix-text-xs);
+--_tree-heading-tracking: var(--helix-tracking-wide);
+}
+
 :host([loading]) [part="tree"] {
 opacity: 0.5;
 }

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@fusion.dev/helix",
   "description": "Styled component tier. Extends the headless tier with token-driven presentation.",
-  "version": "0.33.5",
+  "version": "0.34.1",
   "license": "MIT",
   "author": "Ross Sheppard <ross.sheppard@fusion.dev>",
   "repository": {
@@ -47,14 +47,14 @@
   },
   "bugs": "https://github.com/project-fusion/fusion/issues",
   "dependencies": {
-    "@fusion.dev/helix-core": "0.33.5",
-    "@fusion.dev/helix-headless": "0.33.5",
-    "@fusion.dev/helix-styles": "0.33.5"
+    "@fusion.dev/helix-core": "0.34.1",
+    "@fusion.dev/helix-headless": "0.34.1",
+    "@fusion.dev/helix-styles": "0.34.1"
   },
   "devDependencies": {
     "@custom-elements-manifest/analyzer": "^0.11.0",
-    "@fusion.dev/helix-cem": "0.33.5",
-    "@fusion.dev/helix-testing": "0.33.5",
+    "@fusion.dev/helix-cem": "0.34.1",
+    "@fusion.dev/helix-testing": "0.34.1",
     "@fusion.dev/scripts": "0.0.0-dev",
     "@happy-dom/global-registrator": "^20.0.0",
     "@lit-labs/ssr": "^4.1.0",

package/types/jsx.d.ts

@@ -18861,6 +18861,40 @@ Ignored once `active` is written. */
   defaultActive?: (HelixTree["defaultActive"]) | undefined;
   /** Accessible name for the tree. */
   label?: (HelixTree["label"]) | undefined;
+  /** What a step inward means: nothing, a rank, or a heading over what follows.
+
+All three answers are right, for different trees, which is why this is
+asked rather than decided. `peer` is a file explorer: every row is the same
+kind of thing, a name that may hold more names, and the indent alone says
+where one sits. `subordinate` is side navigation or a categorization: a
+section holds pages and a facet holds values, so a step inward is a change
+of kind and the rows say so. `heading` is a documentation sidebar, where
+the change is at the *parent*: "Getting started" is not a lesser page than
+the pages under it and not a page at all, it is the name of the list, so
+the branch takes the rail-heading treatment and its children stay at the
+size every other row is.
+
+`subordinate` and `heading` are not the same answer said twice. One keys on
+depth and quiets the child; the other keys on holding children and relabels
+the parent, so a top-level leaf beside a branch is untouched by the first
+and untouched by the second for opposite reasons.
+
+On the root rather than the item, because it is a fact about the tree. Set
+per row it would make a tree writable in which one branch ranks its
+children and the next does not, and it would have to be repeated on every
+row to say one thing.
+
+Here rather than on the styled tier, because it is not about paint: with
+every stylesheet deleted it is still true that this tree ranks its depths,
+that this one heads them, and that a file explorer does neither. The styled
+tier steps a subordinate row once down the type scale and sets a heading
+branch as a label; a headless consumer reads the attribute and the
+`--tree-level` each row carries, and draws either however they like.
+
+**Optional, with no default**, per the reflected-property rule: a value
+written here appears in the served markup of every tree anybody renders.
+The resting state is the absence of the attribute, which is `peer`. */
+  nesting?: (HelixTree["nesting"]) | undefined;
 
   /** Fired when an item is chosen. Dispatched by the item and listened for here, because the tree is what a consumer holds a reference to. Cancelable: refusing it takes the decision and nothing moves. */
   "onhelix-select"?: ((e: HelixTreeHelixSelectElementEvent) => void) | undefined;
@@ -18950,6 +18984,40 @@ Ignored once `active` is written. */
   "prop:defaultActive"?: (HelixTree["defaultActive"]) | undefined;
   /** Accessible name for the tree. */
   "prop:label"?: (HelixTree["label"]) | undefined;
+  /** What a step inward means: nothing, a rank, or a heading over what follows.
+
+All three answers are right, for different trees, which is why this is
+asked rather than decided. `peer` is a file explorer: every row is the same
+kind of thing, a name that may hold more names, and the indent alone says
+where one sits. `subordinate` is side navigation or a categorization: a
+section holds pages and a facet holds values, so a step inward is a change
+of kind and the rows say so. `heading` is a documentation sidebar, where
+the change is at the *parent*: "Getting started" is not a lesser page than
+the pages under it and not a page at all, it is the name of the list, so
+the branch takes the rail-heading treatment and its children stay at the
+size every other row is.
+
+`subordinate` and `heading` are not the same answer said twice. One keys on
+depth and quiets the child; the other keys on holding children and relabels
+the parent, so a top-level leaf beside a branch is untouched by the first
+and untouched by the second for opposite reasons.
+
+On the root rather than the item, because it is a fact about the tree. Set
+per row it would make a tree writable in which one branch ranks its
+children and the next does not, and it would have to be repeated on every
+row to say one thing.
+
+Here rather than on the styled tier, because it is not about paint: with
+every stylesheet deleted it is still true that this tree ranks its depths,
+that this one heads them, and that a file explorer does neither. The styled
+tier steps a subordinate row once down the type scale and sets a heading
+branch as a label; a headless consumer reads the attribute and the
+`--tree-level` each row carries, and draws either however they like.
+
+**Optional, with no default**, per the reflected-property rule: a value
+written here appears in the served markup of every tree anybody renders.
+The resting state is the absence of the attribute, which is `peer`. */
+  "prop:nesting"?: (HelixTree["nesting"]) | undefined;
   /** Fired when an item is chosen. Dispatched by the item and listened for here, because the tree is what a consumer holds a reference to. Cancelable: refusing it takes the decision and nothing moves. */
   "on:helix-select"?: ((e: HelixTreeHelixSelectElementEvent) => void) | undefined;
   /** Fired once the current one has moved, so the element already holds it. */
@@ -37717,6 +37785,39 @@ export type CustomElements = {
    *
    * Ignored once `active` is written.
    * - `label`: Accessible name for the tree.
+   * - `nesting`: What a step inward means: nothing, a rank, or a heading over what follows.
+   *
+   * All three answers are right, for different trees, which is why this is
+   * asked rather than decided. `peer` is a file explorer: every row is the same
+   * kind of thing, a name that may hold more names, and the indent alone says
+   * where one sits. `subordinate` is side navigation or a categorization: a
+   * section holds pages and a facet holds values, so a step inward is a change
+   * of kind and the rows say so. `heading` is a documentation sidebar, where
+   * the change is at the *parent*: "Getting started" is not a lesser page than
+   * the pages under it and not a page at all, it is the name of the list, so
+   * the branch takes the rail-heading treatment and its children stay at the
+   * size every other row is.
+   *
+   * `subordinate` and `heading` are not the same answer said twice. One keys on
+   * depth and quiets the child; the other keys on holding children and relabels
+   * the parent, so a top-level leaf beside a branch is untouched by the first
+   * and untouched by the second for opposite reasons.
+   *
+   * On the root rather than the item, because it is a fact about the tree. Set
+   * per row it would make a tree writable in which one branch ranks its
+   * children and the next does not, and it would have to be repeated on every
+   * row to say one thing.
+   *
+   * Here rather than on the styled tier, because it is not about paint: with
+   * every stylesheet deleted it is still true that this tree ranks its depths,
+   * that this one heads them, and that a file explorer does neither. The styled
+   * tier steps a subordinate row once down the type scale and sets a heading
+   * branch as a label; a headless consumer reads the attribute and the
+   * `--tree-level` each row carries, and draws either however they like.
+   *
+   * **Optional, with no default**, per the reflected-property rule: a value
+   * written here appears in the served markup of every tree anybody renders.
+   * The resting state is the absence of the attribute, which is `peer`.
    * - `whenSettled`: Resolves a frame after the first update, when transitions are switched on.
    *
    * **Named `whenSettled` because `settled` is taken four times over**, by
@@ -56885,6 +56986,39 @@ export type CustomElementsSolidJs = {
    *
    * Ignored once `active` is written.
    * - `label`: Accessible name for the tree.
+   * - `nesting`: What a step inward means: nothing, a rank, or a heading over what follows.
+   *
+   * All three answers are right, for different trees, which is why this is
+   * asked rather than decided. `peer` is a file explorer: every row is the same
+   * kind of thing, a name that may hold more names, and the indent alone says
+   * where one sits. `subordinate` is side navigation or a categorization: a
+   * section holds pages and a facet holds values, so a step inward is a change
+   * of kind and the rows say so. `heading` is a documentation sidebar, where
+   * the change is at the *parent*: "Getting started" is not a lesser page than
+   * the pages under it and not a page at all, it is the name of the list, so
+   * the branch takes the rail-heading treatment and its children stay at the
+   * size every other row is.
+   *
+   * `subordinate` and `heading` are not the same answer said twice. One keys on
+   * depth and quiets the child; the other keys on holding children and relabels
+   * the parent, so a top-level leaf beside a branch is untouched by the first
+   * and untouched by the second for opposite reasons.
+   *
+   * On the root rather than the item, because it is a fact about the tree. Set
+   * per row it would make a tree writable in which one branch ranks its
+   * children and the next does not, and it would have to be repeated on every
+   * row to say one thing.
+   *
+   * Here rather than on the styled tier, because it is not about paint: with
+   * every stylesheet deleted it is still true that this tree ranks its depths,
+   * that this one heads them, and that a file explorer does neither. The styled
+   * tier steps a subordinate row once down the type scale and sets a heading
+   * branch as a label; a headless consumer reads the attribute and the
+   * `--tree-level` each row carries, and draws either however they like.
+   *
+   * **Optional, with no default**, per the reflected-property rule: a value
+   * written here appears in the served markup of every tree anybody renders.
+   * The resting state is the absence of the attribute, which is `peer`.
    * - `whenSettled`: Resolves a frame after the first update, when transitions are switched on.
    *
    * **Named `whenSettled` because `settled` is taken four times over**, by

package/types/vue.d.ts

@@ -9717,6 +9717,40 @@ Ignored once `active` is written. */
   defaultActive?: (HelixTree["defaultActive"]) | undefined;
   /** Accessible name for the tree. */
   label?: (HelixTree["label"]) | undefined;
+  /** What a step inward means: nothing, a rank, or a heading over what follows.
+
+All three answers are right, for different trees, which is why this is
+asked rather than decided. `peer` is a file explorer: every row is the same
+kind of thing, a name that may hold more names, and the indent alone says
+where one sits. `subordinate` is side navigation or a categorization: a
+section holds pages and a facet holds values, so a step inward is a change
+of kind and the rows say so. `heading` is a documentation sidebar, where
+the change is at the *parent*: "Getting started" is not a lesser page than
+the pages under it and not a page at all, it is the name of the list, so
+the branch takes the rail-heading treatment and its children stay at the
+size every other row is.
+
+`subordinate` and `heading` are not the same answer said twice. One keys on
+depth and quiets the child; the other keys on holding children and relabels
+the parent, so a top-level leaf beside a branch is untouched by the first
+and untouched by the second for opposite reasons.
+
+On the root rather than the item, because it is a fact about the tree. Set
+per row it would make a tree writable in which one branch ranks its
+children and the next does not, and it would have to be repeated on every
+row to say one thing.
+
+Here rather than on the styled tier, because it is not about paint: with
+every stylesheet deleted it is still true that this tree ranks its depths,
+that this one heads them, and that a file explorer does neither. The styled
+tier steps a subordinate row once down the type scale and sets a heading
+branch as a label; a headless consumer reads the attribute and the
+`--tree-level` each row carries, and draws either however they like.
+
+**Optional, with no default**, per the reflected-property rule: a value
+written here appears in the served markup of every tree anybody renders.
+The resting state is the absence of the attribute, which is `peer`. */
+  nesting?: (HelixTree["nesting"]) | undefined;
 };
 
 export type HelixTreeVueEvents = {