@fusion.dev/helix-core 0.186.1 → 0.188.0

package/custom-elements.json

@@ -1758,7 +1758,7 @@
       "declarations": [
         {
           "kind": "class",
-          "description": "Pushes a group's `disabled` onto its members, on every update, unasked.\n\n**The cascade itself is `inheritDisabled`, and this is what makes it\nautomatic.** Called by hand it runs only when whichever method holds the call\nruns, so a group whose items changed by some other path leaves them holding\nthe last answer, and a group that forgets the call gets no cascade at all\nwith nothing to say so: the property exists, the attribute reflects, and the\nmembers simply ignore it. That is invisible in review and shows up only when\nsomeone disables a set.\n\nIt adds no API. A group already has `disabled`, from `HelixFormElement` or\nfrom the consumer; nothing here introduces a property or a method for anyone\nto call. By this repo's own rule that makes it a controller and not a mixin:\nit reacts to a lifecycle and nothing else.\n\nSo a group states its members once, at construction, and never thinks about\nit again:\n\n    new DisabledCascadeController(this, { items: () => this.items })\n\n**Runs after every render, and on every `slotchange`.** The second half is\nnot an extra: a member arriving in the light DOM changes no property, so Lit\nschedules nothing, and a render-only cascade leaves a member slotted into an\nalready-disabled group enabled. Measured before it was added, on a radio\ngroup holding two disabled members with a third inserted: `110`, and the\nthird was live in a set nobody could use.\n\nThe listener is on the render root rather than on the host, because\n`slotchange` bubbles but is not composed: it reaches the shadow root that\nowns the slot and stops there. On the host it would never fire at all.\n\nAfter render rather than before, because the items are read from the DOM and\na newly slotted member is not there until the render that assigns it.\n\nIdempotent, so running on every update costs a comparison per member and\nnothing else: `inheritDisabled` writes only where the answer changed and\nremembers what each member said for itself, which is what lets a group be\nre-enabled without freeing a member that was disabled on its own.",
+          "description": "Pushes a group's `disabled` onto its members, on every update, unasked.\n\n**The cascade itself is `inheritDisabled`, and this is what makes it\nautomatic.** Called by hand it runs only when whichever method holds the call\nruns, so a group whose items changed by some other path leaves them holding\nthe last answer, and a group that forgets the call gets no cascade at all\nwith nothing to say so: the property exists, the attribute reflects, and the\nmembers simply ignore it. That is invisible in review and shows up only when\nsomeone disables a set.\n\nIt adds no API. A group already has `disabled`, from `HelixFormElement` or\nfrom the consumer; nothing here introduces a property or a method for anyone\nto call. Adding no API is what makes it a controller and not a mixin: it\nreacts to a lifecycle and nothing else.\n\nSo a group states its members once, at construction, and never thinks about\nit again:\n\n    new DisabledCascadeController(this, { items: () => this.items })\n\n**Runs after every render, and on every `slotchange`.** The second half is\nnot an extra: a member arriving in the light DOM changes no property, so Lit\nschedules nothing, and a render-only cascade leaves a member slotted into an\nalready-disabled group enabled. Measured before it was added, on a radio\ngroup holding two disabled members with a third inserted: `110`, and the\nthird was live in a set nobody could use.\n\nThe listener is on the render root rather than on the host, because\n`slotchange` bubbles but is not composed: it reaches the shadow root that\nowns the slot and stops there. On the host it would never fire at all.\n\nAfter render rather than before, because the items are read from the DOM and\na newly slotted member is not there until the render that assigns it.\n\nIdempotent, so running on every update costs a comparison per member and\nnothing else: `inheritDisabled` writes only where the answer changed and\nremembers what each member said for itself, which is what lets a group be\nre-enabled without freeing a member that was disabled on its own.",
           "name": "DisabledCascadeController",
           "members": [
             {
@@ -5524,7 +5524,7 @@
       "declarations": [
         {
           "kind": "class",
-          "description": "Reads a design token as the sRGB triple a shader or a 2D canvas can take, and\ntells the host when the palette underneath it moves.\n\n**Two hops, and both are load-bearing.** A custom property's own value is the\nunevaluated function text, so `getComputedStyle` on a probe is the only way\nto see what it resolves to. The second hop is `readColor`, which is shared\nwith every other caller that has a resolved color and needs channels: what it\nresolves to is not `rgb()`, the\npalette derives from an `oklch()` seed, and Chrome answers `lab(100 0 0)` for\nwhite. Parsing that with a regular expression for numbers reads the three\nchannels as 100, 0 and 0, which divided by 255 is a dark red.\n\nA screenshot cannot catch that: a warm cast on a saturated gradient is also\nwhat chroma subsampling produces, so the picture agrees with the bug.\n\nThe conversion is therefore the browser's own: fill a pixel and read it back.\nThat holds for `lab()`, `oklch()`, `color-mix()` and whatever a token is\nwritten in next, which is the property worth having in a design system whose\npalette is derived rather than listed.\n\n**A controller and not a mixin**, by this repository's own line: it adds no\nproperty or method a consumer sets. It reacts to lifecycle, holding a probe\nthat has to be created after the host connects and removed when it leaves,\nand it watches for the color mode changing so the host can repaint.\n\n**Client only, and that is the contract rather than a limitation.** There is\nno computed style on a server and no canvas to convert with, so `read`\nanswers the fallback there. Every caller is drawing into a canvas, which does\nnot exist on a server either.",
+          "description": "Reads a design token as the sRGB triple a shader or a 2D canvas can take, and\ntells the host when the palette underneath it moves.\n\n**Two hops, and both are load-bearing.** A custom property's own value is the\nunevaluated function text, so `getComputedStyle` on a probe is the only way\nto see what it resolves to. The second hop is `readColor`, which is shared\nwith every other caller that has a resolved color and needs channels: what it\nresolves to is not `rgb()`, the\npalette derives from an `oklch()` seed, and Chrome answers `lab(100 0 0)` for\nwhite. Parsing that with a regular expression for numbers reads the three\nchannels as 100, 0 and 0, which divided by 255 is a dark red.\n\nA screenshot cannot catch that: a warm cast on a saturated gradient is also\nwhat chroma subsampling produces, so the picture agrees with the bug.\n\nThe conversion is therefore the browser's own: fill a pixel and read it back.\nThat holds for `lab()`, `oklch()`, `color-mix()` and whatever a token is\nwritten in next, which is the property worth having in a design system whose\npalette is derived rather than listed.\n\n**A controller and not a mixin**, because it adds no property or method a\nconsumer sets. It reacts to lifecycle, holding a probe\nthat has to be created after the host connects and removed when it leaves,\nand it watches for the color mode changing so the host can repaint.\n\n**Client only, and that is the contract rather than a limitation.** There is\nno computed style on a server and no canvas to convert with, so `read`\nanswers the fallback there. Every caller is drawing into a canvas, which does\nnot exist on a server either.",
           "name": "TokenColorController",
           "members": [
             {
@@ -25062,7 +25062,7 @@
         },
         {
           "kind": "mixin",
-          "description": "Grafts a pan-and-zoom surface: its controls, its keys, and the way out.\n\n**Nothing here is geographic, which is why it is here.** `Map` was written\nfirst and its frame turned out to be a surface a reader can move, fill the\nscreen with, and stop touching: a canvas of notes and a graph of nodes want\nthe same four hundred lines, and the only thing that made them Map's was\nbeing written there. Extracted before the second consumer rather than after,\nwhich is the opposite of what [#383](queue.md) had to conclude about a\ncontroller promoted ahead of one.\n\n**Nothing here moves anything, either.** Both controls ask, through an event\na family names, and the answer is the consumer's: the surface a reader is\nlooking at belongs to them, whether it is a tile renderer, a canvas or a\nforce layout. A mixin that moved the view would have to know what the view\nwas.\n\n**The controls are buttons, and that is a decision against arrow keys.** They\nwork too, but what a screen reader does with them is not ours to decide:\nmacOS passes them through, Windows readers hold them for their own reading\nmode unless a page takes `role=\"application\"`, which costs the reader their\nnormal way of reading everything else. A button is findable and operable in\nevery screen reader on every platform without that bargain.\n\n**What stays in the family is `render()`, its slots and its part\ndocumentation**, because a part named through an interpolation is one the\nmanifest cannot see: a loop over the four pan buttons would publish `pan-`\nand a consumer's `::part(pan-up)` would match nothing.",
+          "description": "Grafts a pan-and-zoom surface: its controls, its keys, and the way out.\n\n**Nothing here is geographic, which is why it is here.** `Map` was written\nfirst and its frame turned out to be a surface a reader can move, fill the\nscreen with, and stop touching: a canvas of notes and a graph of nodes want\nthe same four hundred lines, and the only thing that made them Map's was\nbeing written there. Extracted before the second consumer arrived.\n\n**Nothing here moves anything, either.** Both controls ask, through an event\na family names, and the answer is the consumer's: the surface a reader is\nlooking at belongs to them, whether it is a tile renderer, a canvas or a\nforce layout. A mixin that moved the view would have to know what the view\nwas.\n\n**The controls are buttons, and that is a decision against arrow keys.** They\nwork too, but what a screen reader does with them is not ours to decide:\nmacOS passes them through, Windows readers hold them for their own reading\nmode unless a page takes `role=\"application\"`, which costs the reader their\nnormal way of reading everything else. A button is findable and operable in\nevery screen reader on every platform without that bargain.\n\n**What stays in the family is `render()`, its slots and its part\ndocumentation**, because a part named through an interpolation is one the\nmanifest cannot see: a loop over the four pan buttons would publish `pan-`\nand a consumer's `::part(pan-up)` would match nothing.",
           "name": "MixinViewport",
           "members": [
             {
@@ -28172,7 +28172,7 @@
               }
             }
           ],
-          "description": "Builds a stylesheet from CSS authored in a `.css` file.\n\nComponent styles live in real `.css` files rather than `css` tagged\ntemplates, so they get CSS tooling: syntax highlighting, formatters, the\ntoken linter, and a diff that reads as CSS. `turbo run styles` compiles each\none into a sibling `.css.ts` that calls this.\n\nThe `unsafe` in `unsafeCSS` warns about interpolating untrusted input into a\nstylesheet. That is not what happens here: the argument is a build-time\nconstant read from a file in this repo, never a runtime value. Wrapping it\nkeeps the warning where it belongs, on `unsafeCSS` itself, and gives one seam\nto change if constructable stylesheets become the better primitive."
+          "description": "Builds a stylesheet from CSS authored in a `.css` file.\n\nComponent styles live in real `.css` files rather than `css` tagged\ntemplates, so they get CSS tooling: syntax highlighting, formatters, the\ntoken linter, and a diff that reads as CSS. `turbo run styles` compiles each\none into a sibling `.css.ts` that calls this.\n\nThe `unsafe` in `unsafeCSS` warns about interpolating untrusted input into a\nstylesheet. That is not what happens here: the argument is a build-time\nconstant read from a file in the package, never a runtime value. Wrapping it\nkeeps the warning where it belongs, on `unsafeCSS` itself, and gives one seam\nto change if constructable stylesheets become the better primitive."
         }
       ],
       "exports": [
@@ -35683,7 +35683,7 @@
           "type": {
             "text": "string"
           },
-          "default": "'0.186.1'",
+          "default": "'0.188.0'",
           "description": "The version of the package this file ships in.\n\n**Written by `fusion/scripts/version.mjs`** wherever it writes the package's\n`package.json`, and stamped back into the repository beside it after a\nrelease, so the two never disagree; a spec beside this holds them to it.\nNothing else in the running code knows which release it is."
         }
       ],
@@ -36319,6 +36319,6 @@
   ],
   "helix": {
     "package": "@fusion.dev/helix-core",
-    "version": "0.186.1"
+    "version": "0.188.0"
   }
 }

package/dist/controllers/disabled-cascade-controller/disabled-cascade-controller.d.ts

@@ -38,8 +38,8 @@ type DisableableHost = ReactiveControllerHost & HTMLElement & {
  *
  * It adds no API. A group already has `disabled`, from `HelixFormElement` or
  * from the consumer; nothing here introduces a property or a method for anyone
- * to call. By this repo's own rule that makes it a controller and not a mixin:
- * it reacts to a lifecycle and nothing else.
+ * to call. Adding no API is what makes it a controller and not a mixin: it
+ * reacts to a lifecycle and nothing else.
  *
  * So a group states its members once, at construction, and never thinks about
  * it again:

package/dist/controllers/token-color-controller/token-color-controller.d.ts

@@ -22,8 +22,8 @@ export type TokenColor = [number, number, number];
  * written in next, which is the property worth having in a design system whose
  * palette is derived rather than listed.
  *
- * **A controller and not a mixin**, by this repository's own line: it adds no
- * property or method a consumer sets. It reacts to lifecycle, holding a probe
+ * **A controller and not a mixin**, because it adds no property or method a
+ * consumer sets. It reacts to lifecycle, holding a probe
  * that has to be created after the host connects and removed when it leaves,
  * and it watches for the color mode changing so the host can repaint.
  *

package/dist/mixins/mixin-viewport/mixin-viewport.d.ts

@@ -128,9 +128,7 @@ export declare class ViewportElement {
  * first and its frame turned out to be a surface a reader can move, fill the
  * screen with, and stop touching: a canvas of notes and a graph of nodes want
  * the same four hundred lines, and the only thing that made them Map's was
- * being written there. Extracted before the second consumer rather than after,
- * which is the opposite of what [#383](queue.md) had to conclude about a
- * controller promoted ahead of one.
+ * being written there. Extracted before the second consumer arrived.
  *
  * **Nothing here moves anything, either.** Both controls ask, through an event
  * a family names, and the answer is the consumer's: the surface a reader is

package/dist/utils/create-sheet/create-sheet.d.ts

@@ -9,7 +9,7 @@ import { type CSSResult } from 'lit';
  *
  * The `unsafe` in `unsafeCSS` warns about interpolating untrusted input into a
  * stylesheet. That is not what happens here: the argument is a build-time
- * constant read from a file in this repo, never a runtime value. Wrapping it
+ * constant read from a file in the package, never a runtime value. Wrapping it
  * keeps the warning where it belongs, on `unsafeCSS` itself, and gives one seam
  * to change if constructable stylesheets become the better primitive.
  */

package/dist/version.d.ts

@@ -6,4 +6,4 @@
  * release, so the two never disagree; a spec beside this holds them to it.
  * Nothing else in the running code knows which release it is.
  */
-export declare const VERSION = "0.186.1";
+export declare const VERSION = "0.188.0";

package/dist/version.js

@@ -1 +1 @@
-export const VERSION = '0.186.1';
+export const VERSION = '0.188.0';

package/package.json

@@ -1,7 +1,7 @@
 {
   "name": "@fusion.dev/helix-core",
   "description": "Helix element primitives: base classes, mixins, decorators, utilities.",
-  "version": "0.186.1",
+  "version": "0.188.0",
   "license": "MIT",
   "author": "Ross Sheppard <ross.sheppard@fusion.dev>",
   "repository": {
@@ -74,12 +74,12 @@
   "bugs": "https://github.com/project-fusion/fusion/issues",
   "dependencies": {
     "@floating-ui/dom": "^1.8.0",
-    "@fusion.dev/helix-icons": "0.186.1",
+    "@fusion.dev/helix-icons": "0.188.0",
     "tslib": "^2.8.1"
   },
   "devDependencies": {
-    "@fusion.dev/helix-cem": "0.186.1",
-    "@fusion.dev/helix-testing": "0.186.1",
+    "@fusion.dev/helix-cem": "0.188.0",
+    "@fusion.dev/helix-testing": "0.188.0",
     "@lit-labs/ssr": "^4.1.0",
     "lit": "^3.2.1"
   },