@fusion.dev/helix-headless 0.18.0 → 0.19.0

package/custom-elements.json

@@ -26648,7 +26648,7 @@
       "declarations": [
         {
           "kind": "class",
-          "description": "**The tokens are the consumer's own elements, slotted.** What a filter narrows\nby belongs to the consumer's model rather than to this element: a facet with a\nprefix, a saved query, a range. So they are slotted rather than rendered from\na list of strings, and removing one is a request this element makes rather\nthan a change it applies. Combobox is the other way round, and that is the\ndifference between the two: its tokens are a view of a selection it owns,\ndrawn from options it was handed.\n\n**`value` is the text being typed, not the tokens**, which is what makes this\na field a consumer can listen to. Every keystroke announces `input` with the\ntext on the element, so a table narrows as the reader types. The tokens need\nno reporting back, being markup the consumer already holds.\n\nBackspace on an empty field asks the last token to go, through the same\n`helix-dismiss` its own remove control fires, so a consumer who handled the\npointer has already handled the keyboard.\n\n**It can suggest what to type next, and it never learns the grammar.** Slot\n`helix-option` elements into `suggestions` and the field shows them, moves\nthrough them with the arrows, and lets Enter press one; the option fires its\nown `helix-select` and the consumer decides what choosing meant. Deciding\n*what* to suggest is theirs too: keys before a colon and values after it are\nthe same panel with different contents, which is all a two-level filter is,\nand the parse that tells them apart belongs where the domain does.\n\n**The panel opens when there is something in it and closes when there is\nnot**, rather than on a choice. A reader who picks a key wants its values\nnext, and closing on the choice would shut the panel between two renders. Use\n`selectionStart` and `setSelectionRange` to write a completion back and put\nthe caret after it, or the next parse reads the wrong term.",
+          "description": "**The tokens are the consumer's own elements, slotted.** What a filter narrows\nby belongs to the consumer's model rather than to this element: a facet with a\nprefix, a saved query, a range. So they are slotted rather than rendered from\na list of strings, and removing one is a request this element makes rather\nthan a change it applies. Combobox is the other way round, and that is the\ndifference between the two: its tokens are a view of a selection it owns,\ndrawn from options it was handed.\n\n**`value` is the text being typed, not the tokens**, which is what makes this\na field a consumer can listen to. Every keystroke announces `input` with the\ntext on the element, so a table narrows as the reader types. The tokens need\nno reporting back, being markup the consumer already holds.\n\nBackspace on an empty field asks the last token to go, through the same\n`helix-dismiss` its own remove control fires, so a consumer who handled the\npointer has already handled the keyboard.\n\n**It can suggest what to type next, and it never learns the grammar.** Slot\n`helix-option` elements into `suggestions` and the field shows them, moves\nthrough them with the arrows, and lets Enter press one; the option fires its\nown `helix-select` and the consumer decides what choosing meant. Deciding\n*what* to suggest is theirs too: keys before a colon and values after it are\nthe same panel with different contents, which is all a two-level filter is,\nand the parse that tells them apart belongs where the domain does.\n\n**The panel opens when there is something in it and closes when there is\nnot**, rather than on a choice. A reader who picks a key wants its values\nnext, and closing on the choice would shut the panel between two renders. Use\n`selectionStart` and `setSelectionRange` to write a completion back and put\nthe caret after it, or the next parse reads the wrong term.\n\n**Three things here have three different owners, and only one of them is a\ncontrolled property.**\n\n`value` is the text, and it is uncontrolled by default: the reader types, the\nelement applies it, and `input` says so. **Writing `value` does not take that\nover.** It is a seed and a correction, so a consumer who sets it and then\nexpects the field to hold still will watch the next keystroke overwrite them.\nOwnership is taken by refusing `helix-before-change` and writing the value\nyou want, which is the same shape every field in this library uses and is\nworth saying out loud here because the property looks like React's.\n`default-value` seeds the field without claiming anything.\n\n`open` is the suggestions panel, and it is the ordinary controlled pair:\nrefuse `helix-before-open` or `helix-before-close` to take the decision, and\n`default-open` to seed it.\n\nThe tokens are neither, because they are not state. They are the consumer's\nown elements in a slot, so there is nothing for this to own and nothing to\nreport back: a token goes when the consumer removes it from their markup,\nhaving been asked by `helix-dismiss`.",
           "name": "HelixHeadlessFilterInput",
           "cssParts": [
             {

package/dist/filter-input/root/filter-input-root.d.ts

@@ -36,6 +36,27 @@ declare const HelixHeadlessFilterInput_base: (new (...args: any[]) => import("@f
  * `selectionStart` and `setSelectionRange` to write a completion back and put
  * the caret after it, or the next parse reads the wrong term.
  *
+ * **Three things here have three different owners, and only one of them is a
+ * controlled property.**
+ *
+ * `value` is the text, and it is uncontrolled by default: the reader types, the
+ * element applies it, and `input` says so. **Writing `value` does not take that
+ * over.** It is a seed and a correction, so a consumer who sets it and then
+ * expects the field to hold still will watch the next keystroke overwrite them.
+ * Ownership is taken by refusing `helix-before-change` and writing the value
+ * you want, which is the same shape every field in this library uses and is
+ * worth saying out loud here because the property looks like React's.
+ * `default-value` seeds the field without claiming anything.
+ *
+ * `open` is the suggestions panel, and it is the ordinary controlled pair:
+ * refuse `helix-before-open` or `helix-before-close` to take the decision, and
+ * `default-open` to seed it.
+ *
+ * The tokens are neither, because they are not state. They are the consumer's
+ * own elements in a slot, so there is nothing for this to own and nothing to
+ * report back: a token goes when the consumer removes it from their markup,
+ * having been asked by `helix-dismiss`.
+ *
  * @since 0.1.0
  * @status experimental
  * @category forms

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.18.0",
+  "version": "0.19.0",
   "license": "MIT",
   "author": "Ross Sheppard <ross.sheppard@fusion.dev>",
   "repository": {
@@ -45,14 +45,14 @@
   },
   "bugs": "https://github.com/project-fusion/fusion/issues",
   "dependencies": {
-    "@fusion.dev/helix-core": "0.18.0",
-    "@fusion.dev/helix-icons": "0.18.0",
+    "@fusion.dev/helix-core": "0.19.0",
+    "@fusion.dev/helix-icons": "0.19.0",
     "uqr": "^0.1.3"
   },
   "devDependencies": {
     "@custom-elements-manifest/analyzer": "^0.11.0",
-    "@fusion.dev/helix-cem": "0.18.0",
-    "@fusion.dev/helix-testing": "0.18.0",
+    "@fusion.dev/helix-cem": "0.19.0",
+    "@fusion.dev/helix-testing": "0.19.0",
     "@fusion.dev/scripts": "0.0.0-dev",
     "@happy-dom/global-registrator": "^20.0.0",
     "@lit-labs/ssr": "^3.3.0",

package/types/jsx.d.ts

@@ -20707,6 +20707,27 @@ export type CustomElements = {
    * `selectionStart` and `setSelectionRange` to write a completion back and put
    * the caret after it, or the next parse reads the wrong term.
    *
+   * **Three things here have three different owners, and only one of them is a
+   * controlled property.**
+   *
+   * `value` is the text, and it is uncontrolled by default: the reader types, the
+   * element applies it, and `input` says so. **Writing `value` does not take that
+   * over.** It is a seed and a correction, so a consumer who sets it and then
+   * expects the field to hold still will watch the next keystroke overwrite them.
+   * Ownership is taken by refusing `helix-before-change` and writing the value
+   * you want, which is the same shape every field in this library uses and is
+   * worth saying out loud here because the property looks like React's.
+   * `default-value` seeds the field without claiming anything.
+   *
+   * `open` is the suggestions panel, and it is the ordinary controlled pair:
+   * refuse `helix-before-open` or `helix-before-close` to take the decision, and
+   * `default-open` to seed it.
+   *
+   * The tokens are neither, because they are not state. They are the consumer's
+   * own elements in a slot, so there is nothing for this to own and nothing to
+   * report back: a token goes when the consumer removes it from their markup,
+   * having been asked by `helix-dismiss`.
+   *
    * ## Attributes & Properties
    *
    * Component attributes and properties that can be applied to the element or by using JavaScript.
@@ -35221,6 +35242,27 @@ export type CustomElementsSolidJs = {
    * `selectionStart` and `setSelectionRange` to write a completion back and put
    * the caret after it, or the next parse reads the wrong term.
    *
+   * **Three things here have three different owners, and only one of them is a
+   * controlled property.**
+   *
+   * `value` is the text, and it is uncontrolled by default: the reader types, the
+   * element applies it, and `input` says so. **Writing `value` does not take that
+   * over.** It is a seed and a correction, so a consumer who sets it and then
+   * expects the field to hold still will watch the next keystroke overwrite them.
+   * Ownership is taken by refusing `helix-before-change` and writing the value
+   * you want, which is the same shape every field in this library uses and is
+   * worth saying out loud here because the property looks like React's.
+   * `default-value` seeds the field without claiming anything.
+   *
+   * `open` is the suggestions panel, and it is the ordinary controlled pair:
+   * refuse `helix-before-open` or `helix-before-close` to take the decision, and
+   * `default-open` to seed it.
+   *
+   * The tokens are neither, because they are not state. They are the consumer's
+   * own elements in a slot, so there is nothing for this to own and nothing to
+   * report back: a token goes when the consumer removes it from their markup,
+   * having been asked by `helix-dismiss`.
+   *
    * ## Attributes & Properties
    *
    * Component attributes and properties that can be applied to the element or by using JavaScript.

package/types/vue.d.ts

@@ -8390,7 +8390,7 @@ export interface WcToolkitVueGlobalComponents {
     HelixHeadlessFileInputVueProps,
     HelixHeadlessFileInputVueEvents
   >;
-  /** **The tokens are the consumer's own elements, slotted.** What a filter narrows by belongs to the consumer's model rather than to this element: a facet with a prefix, a saved query, a range. So they are slotted rather than rendered from a list of strings, and removing one is a request this element makes rather than a change it applies. Combobox is the other way round, and that is the difference between the two: its tokens are a view of a selection it owns, drawn from options it was handed.  **'value' is the text being typed, not the tokens**, which is what makes this a field a consumer can listen to. Every keystroke announces 'input' with the text on the element, so a table narrows as the reader types. The tokens need no reporting back, being markup the consumer already holds.  Backspace on an empty field asks the last token to go, through the same 'helix-dismiss' its own remove control fires, so a consumer who handled the pointer has already handled the keyboard.  **It can suggest what to type next, and it never learns the grammar.** Slot 'helix-option' elements into 'suggestions' and the field shows them, moves through them with the arrows, and lets Enter press one; the option fires its own 'helix-select' and the consumer decides what choosing meant. Deciding *what* to suggest is theirs too: keys before a colon and values after it are the same panel with different contents, which is all a two-level filter is, and the parse that tells them apart belongs where the domain does.  **The panel opens when there is something in it and closes when there is not**, rather than on a choice. A reader who picks a key wants its values next, and closing on the choice would shut the panel between two renders. Use 'selectionStart' and 'setSelectionRange' to write a completion back and put the caret after it, or the next parse reads the wrong term. */
+  /** **The tokens are the consumer's own elements, slotted.** What a filter narrows by belongs to the consumer's model rather than to this element: a facet with a prefix, a saved query, a range. So they are slotted rather than rendered from a list of strings, and removing one is a request this element makes rather than a change it applies. Combobox is the other way round, and that is the difference between the two: its tokens are a view of a selection it owns, drawn from options it was handed.  **'value' is the text being typed, not the tokens**, which is what makes this a field a consumer can listen to. Every keystroke announces 'input' with the text on the element, so a table narrows as the reader types. The tokens need no reporting back, being markup the consumer already holds.  Backspace on an empty field asks the last token to go, through the same 'helix-dismiss' its own remove control fires, so a consumer who handled the pointer has already handled the keyboard.  **It can suggest what to type next, and it never learns the grammar.** Slot 'helix-option' elements into 'suggestions' and the field shows them, moves through them with the arrows, and lets Enter press one; the option fires its own 'helix-select' and the consumer decides what choosing meant. Deciding *what* to suggest is theirs too: keys before a colon and values after it are the same panel with different contents, which is all a two-level filter is, and the parse that tells them apart belongs where the domain does.  **The panel opens when there is something in it and closes when there is not**, rather than on a choice. A reader who picks a key wants its values next, and closing on the choice would shut the panel between two renders. Use 'selectionStart' and 'setSelectionRange' to write a completion back and put the caret after it, or the next parse reads the wrong term.  **Three things here have three different owners, and only one of them is a controlled property.**  'value' is the text, and it is uncontrolled by default: the reader types, the element applies it, and 'input' says so. **Writing 'value' does not take that over.** It is a seed and a correction, so a consumer who sets it and then expects the field to hold still will watch the next keystroke overwrite them. Ownership is taken by refusing 'helix-before-change' and writing the value you want, which is the same shape every field in this library uses and is worth saying out loud here because the property looks like React's. 'default-value' seeds the field without claiming anything.  'open' is the suggestions panel, and it is the ordinary controlled pair: refuse 'helix-before-open' or 'helix-before-close' to take the decision, and 'default-open' to seed it.  The tokens are neither, because they are not state. They are the consumer's own elements in a slot, so there is nothing for this to own and nothing to report back: a token goes when the consumer removes it from their markup, having been asked by 'helix-dismiss'. */
   "helix-headless-filter-input": DefineCustomElement<
     HelixHeadlessFilterInput,
     HelixHeadlessFilterInputVueProps,