@fusion.dev/helix-headless 0.33.5 → 0.34.1

package/custom-elements.json

@@ -102607,6 +102607,16 @@
               "description": "Accessible name for the tree.",
               "attribute": "label"
             },
+            {
+              "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
+            },
             {
               "kind": "field",
               "name": "watcher",
@@ -103324,6 +103334,14 @@
               "description": "Accessible name for the tree.",
               "fieldName": "label"
             },
+            {
+              "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"
+            },
             {
               "name": "empty-text",
               "type": {
@@ -103420,6 +103438,10 @@
               {
                 "description": "The same tree on the headless tier, with every rule written by hand.",
                 "slug": "preview"
+              },
+              {
+                "description": "Depth as a position, depth as a rank, and a branch that is a heading, with every rule written by hand.",
+                "slug": "nesting"
               }
             ],
             "source": "helix/headless/src/tree"

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

@@ -34,6 +34,42 @@ export declare class HelixHeadlessTree extends HelixHeadlessTree_base {
      * Accessible name for the tree.
      */
     label: string;
+    /**
+     * 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?: 'heading' | 'peer' | 'subordinate';
     private watcher;
     /**
      * Every item, in the order a reader moving down would meet them.

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

@@ -176,6 +176,9 @@ let HelixHeadlessTree = class HelixHeadlessTree extends MixinCollection(MixinCon
 __decorate([
     property()
 ], HelixHeadlessTree.prototype, "label", void 0);
+__decorate([
+    property({ reflect: true })
+], HelixHeadlessTree.prototype, "nesting", void 0);
 HelixHeadlessTree = __decorate([
     customElement('helix-headless-tree')
 ], HelixHeadlessTree);

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@fusion.dev/helix-headless",
   "description": "Headless component tier. Structure, accessibility, state, and form participation. No styling.",
-  "version": "0.33.5",
+  "version": "0.34.1",
   "license": "MIT",
   "author": "Ross Sheppard <ross.sheppard@fusion.dev>",
   "repository": {
@@ -46,14 +46,14 @@
   },
   "bugs": "https://github.com/project-fusion/fusion/issues",
   "dependencies": {
-    "@fusion.dev/helix-core": "0.33.5",
-    "@fusion.dev/helix-icons": "0.33.5",
+    "@fusion.dev/helix-core": "0.34.1",
+    "@fusion.dev/helix-icons": "0.34.1",
     "uqr": "^0.1.3"
   },
   "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

@@ -16069,6 +16069,40 @@ export type HelixHeadlessTreeHelixSelectElementEvent =
 export type HelixHeadlessTreeProps = {
   /** Accessible name for the tree. */
   label?: (HelixHeadlessTree["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?: (HelixHeadlessTree["nesting"]) | undefined;
   /** What is said where there are none, and none are coming. */
   "empty-text"?: (HelixHeadlessTree["emptyText"]) | undefined;
   /** What is said where there are none, and none are coming. */
@@ -16114,6 +16148,40 @@ Ignored once `active` is written. */
 export type HelixHeadlessTreeSolidJsProps = {
   /** Accessible name for the tree. */
   "prop:label"?: (HelixHeadlessTree["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"?: (HelixHeadlessTree["nesting"]) | undefined;
   /** What is said where there are none, and none are coming. */
   "attr:empty-text"?: (HelixHeadlessTree["emptyText"]) | undefined;
   /** What is said where there are none, and none are coming. */
@@ -33486,6 +33554,39 @@ export type CustomElements = {
    * Component attributes and properties that can be applied to the element or by using JavaScript.
    *
    * - `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`.
    * - `empty-text`/`emptyText`: What is said where there are none, and none are coming.
    * - `loading`: Whether the rows are still on their way.
    *
@@ -51128,6 +51229,39 @@ export type CustomElementsSolidJs = {
    * Component attributes and properties that can be applied to the element or by using JavaScript.
    *
    * - `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`.
    * - `empty-text`/`emptyText`: What is said where there are none, and none are coming.
    * - `loading`: Whether the rows are still on their way.
    *

package/types/vue.d.ts

@@ -8257,6 +8257,40 @@ export type HelixHeadlessTreeHelixSelectElementEvent =
 export type HelixHeadlessTreeVueProps = {
   /** Accessible name for the tree. */
   label?: (HelixHeadlessTree["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?: (HelixHeadlessTree["nesting"]) | undefined;
   /** What is said where there are none, and none are coming. */
   "empty-text"?: (HelixHeadlessTree["emptyText"]) | undefined;
   /** What is said where there are none, and none are coming. */