@fusion.dev/helix-headless 0.47.0 → 0.48.0

package/custom-elements.json

@@ -9611,6 +9611,10 @@
               "description": "The size one pane is laid out at. A sheet sets it and the component measures the run with it.",
               "name": "--carousel-pane"
             },
+            {
+              "description": "How many slides go across, written onto the track by the component so a sheet divides the track by the same number the positions are counted from. Read it rather than selecting on `per-view`, which cannot be enumerated without a ceiling. See `perView`.",
+              "name": "--carousel-per-view"
+            },
             {
               "description": "How far short of a whole pixel the run ends, on the last slide alone, for a sheet to take up as `margin-inline-end`. See `runEnd`.",
               "name": "--carousel-run-end"
@@ -9806,10 +9810,20 @@
               "type": {
                 "text": "number | undefined"
               },
-              "description": "How many slides are shown across the track at once. Absent shows one.\n\n**Here rather than on the styled tier, because it decides how many places\nthe track can stop.** From the stylesheet it looks like a width, one rule\nper value setting a custom property that the slides divide the track by.\nBut a carousel showing four of six slides has three positions, not six, and\neverything that counts positions is in this file. Declared up there, `goTo`\nclamps to the last *slide*, so three of the six indicators point at an\noffset the track has already reached: pressing next walks the dots to the\nend while the slides stop moving a third of the way through.\n\nNo default, because it reflects. A reflected property with a value writes\nits attribute on upgrade, and the host then carries something a consumer's\nserver markup never had, which React reports as a mismatch. The one-across\ncase is the absent attribute, and the styles read it that way.",
+              "description": "How many slides are shown across the track at once. Absent shows one.\n\n**Here rather than on the styled tier, because it decides how many places\nthe track can stop.** From the stylesheet it looks like a width, one rule\nper value setting a custom property that the slides divide the track by.\nBut a carousel showing four of six slides has three positions, not six, and\neverything that counts positions is in this file. Declared up there, `goTo`\nclamps to the last *slide*, so three of the six indicators point at an\noffset the track has already reached: pressing next walks the dots to the\nend while the slides stop moving a third of the way through.\n\n**The number is published to the styles rather than enumerated by them**,\nas `--carousel-per-view` on the track, which is what keeps a width and a\ncount from disagreeing. A sheet can only name a value it wrote a rule for,\nso the styled tier enumerated `per-view=\"2\"` through `5` and called five a\njudgment; above it the pane fell back to one across while this file went on\ncounting positions. Measured in Chromium over eight slides, six across gave\nthree dots, a pane taking the whole track and five slides reachable only by\ndragging. Written from here there is no ceiling to exceed, and a consumer's\nown sheet reads the same declaration the styled one does. `runEnd` publishes\nits correction the same way and for the same reason.\n\n**On the track and not on the host.** A custom property on the host is a\nreflected attribute by another name: it would arrive on upgrade, and a\nconsumer's server markup never had it. Inside the component's own shadow\nroot it serializes with the rest of the template on the server, and the\ntrack's own declaration beats anything a consumer inherits in, so the\nattribute is the one answer to how wide a pane is.\n\nA value the track cannot honor is taken to the nearest one it can, by\n`across`, and both tiers read that rather than this.\n\nNo default, because it reflects. A reflected property with a value writes\nits attribute on upgrade, and the host then carries something a consumer's\nserver markup never had, which React reports as a mismatch. The one-across\ncase is the absent attribute, and the styles read it that way.",
               "attribute": "per-view",
               "reflects": true
             },
+            {
+              "kind": "field",
+              "name": "across",
+              "type": {
+                "text": "number"
+              },
+              "privacy": "private",
+              "description": "`perView` as both tiers use it: a whole number of slides, one at least.\n\n**The clamp is here because the arithmetic is here**, and the two readers\nof this number have to be given the same one. A fraction is floored, since\na position is a whole slide along: one and a half across leaves a last\nposition the track runs out before reaching, which is the fault `goTo`\nalready carries a comment about. Zero and a negative divide the track into\nnothing and into a pane facing the wrong way, and a non-numeric attribute\nparses to `NaN`, which `Math.max` propagates: it counted `NaN` positions,\ndrew no indicators at all and left `index` at `NaN`. All of them read as\none across, which is what a carousel with nothing sayable asked for.\n\nNot clamped to the number of slides. Six across four slides is four panes\nat a sixth of the track each and the one place to stand, which is what was\nasked for as nearly as it can be had, and the slide count is a fact the\nserver does not have: clamping to it would draw one width there and another\non upgrade.",
+              "readonly": true
+            },
             {
               "kind": "field",
               "name": "positions",
@@ -10477,7 +10491,7 @@
               "type": {
                 "text": "number | undefined"
               },
-              "description": "How many slides are shown across the track at once. Absent shows one.\n\n**Here rather than on the styled tier, because it decides how many places\nthe track can stop.** From the stylesheet it looks like a width, one rule\nper value setting a custom property that the slides divide the track by.\nBut a carousel showing four of six slides has three positions, not six, and\neverything that counts positions is in this file. Declared up there, `goTo`\nclamps to the last *slide*, so three of the six indicators point at an\noffset the track has already reached: pressing next walks the dots to the\nend while the slides stop moving a third of the way through.\n\nNo default, because it reflects. A reflected property with a value writes\nits attribute on upgrade, and the host then carries something a consumer's\nserver markup never had, which React reports as a mismatch. The one-across\ncase is the absent attribute, and the styles read it that way.",
+              "description": "How many slides are shown across the track at once. Absent shows one.\n\n**Here rather than on the styled tier, because it decides how many places\nthe track can stop.** From the stylesheet it looks like a width, one rule\nper value setting a custom property that the slides divide the track by.\nBut a carousel showing four of six slides has three positions, not six, and\neverything that counts positions is in this file. Declared up there, `goTo`\nclamps to the last *slide*, so three of the six indicators point at an\noffset the track has already reached: pressing next walks the dots to the\nend while the slides stop moving a third of the way through.\n\n**The number is published to the styles rather than enumerated by them**,\nas `--carousel-per-view` on the track, which is what keeps a width and a\ncount from disagreeing. A sheet can only name a value it wrote a rule for,\nso the styled tier enumerated `per-view=\"2\"` through `5` and called five a\njudgment; above it the pane fell back to one across while this file went on\ncounting positions. Measured in Chromium over eight slides, six across gave\nthree dots, a pane taking the whole track and five slides reachable only by\ndragging. Written from here there is no ceiling to exceed, and a consumer's\nown sheet reads the same declaration the styled one does. `runEnd` publishes\nits correction the same way and for the same reason.\n\n**On the track and not on the host.** A custom property on the host is a\nreflected attribute by another name: it would arrive on upgrade, and a\nconsumer's server markup never had it. Inside the component's own shadow\nroot it serializes with the rest of the template on the server, and the\ntrack's own declaration beats anything a consumer inherits in, so the\nattribute is the one answer to how wide a pane is.\n\nA value the track cannot honor is taken to the nearest one it can, by\n`across`, and both tiers read that rather than this.\n\nNo default, because it reflects. A reflected property with a value writes\nits attribute on upgrade, and the host then carries something a consumer's\nserver markup never had, which React reports as a mismatch. The one-across\ncase is the absent attribute, and the styles read it that way.",
               "fieldName": "perView"
             }
           ],
@@ -19129,6 +19143,28 @@
               "description": "Whether to leave the value out, for a picker whose value is stated elsewhere.\n\nThe row reads the color as text and lets it be typed or pasted, which is\nwhat makes this element complete standing on a page: a square and two ramps\ncan build a color and cannot state one, and a reader who has a hex already\nshould not have to find it by dragging.\n\nColor Input sets this, because its field is that input. Two editable fields\nfor one value is the outcome worth avoiding: two places to type, and no\nanswer to which one is authoritative or which has the caret. Do not close it\nthe other way round, with Color Input dropping its own field: the value\nwould then be unreadable and unpasteable without opening a panel.",
               "attribute": "no-value"
             },
+            {
+              "kind": "field",
+              "name": "readOnly",
+              "type": {
+                "text": "boolean"
+              },
+              "default": "false",
+              "description": "Whether the control refuses changes while still submitting its value.\n\n**Enforced by refusing every request in one place**, which is the seam this\ncomponent already has: `requestValue` is what every path here comes through,\nand gating it once is what stops the next call site from being written\nwithout the check.\n\nNot `disabled`, which is the confusion worth naming: a disabled control\nsubmits nothing and leaves the tab order, and a read-only one submits its\nvalue and stays reachable, which is what a form showing a color somebody\nelse set needs.\n\n**One gate is not enough here, and the second is `move`.** This picker\nholds a model beside its value, which Date Picker and Time Picker do not:\n`moved` is the HSB the square is drawn from, and it is written before the\nvalue is requested. Gating only the request would leave the square under\nthe reader's pointer and the value where it was, which is a control that\nrefuses and looks like it accepted.",
+              "attribute": "readonly",
+              "reflects": true
+            },
+            {
+              "kind": "field",
+              "name": "required",
+              "type": {
+                "text": "boolean"
+              },
+              "default": "false",
+              "description": "Whether the form refuses to submit while no color is chosen.\n\n**A color is exactly as requirable as a date**, which is the comparison\nthat settles it: this element extends `HelixFormElement`, carries `name`\nand reports its value, so a consumer writing\n`<helix-color-picker name=\"brand\" required>` inside a form has every reason\nto expect the form to refuse an empty one. Its two siblings in the same\ncomposition position, Date Picker and Time Picker, both check it.\n\nWritten out rather than taken from `MixinField`, for the reason those two\nrecord: the mixin brings a label, a hint and a feedback region, and this is\na panel composed *into* a field that already has all three, so taking it\nwould give one control two of each. What is left is the validity call and\nthe anchor the browser points its bubble at.\n\n**Emptiness is the only fault reported, and bad input deliberately is\nnot.** The value row is typed into a character at a time and every\nkeystroke reaches `requestValue`, so `#0`, `#00` and `#00f` would each be a\nreported fault on the way to `#00ff00`. Date Picker and Time Picker can\nreport bad input because their value moves only on a commit. Color Input\nreports it for this family instead, once, against the field the reader\ntyped into.",
+              "attribute": "required",
+              "reflects": true
+            },
             {
               "kind": "field",
               "name": "swatches",
@@ -19214,6 +19250,31 @@
               "readonly": true,
               "description": "Takes what was typed, and lets the square follow only a whole color."
             },
+            {
+              "kind": "method",
+              "name": "requestValue",
+              "return": {
+                "type": {
+                  "text": "boolean"
+                }
+              },
+              "parameters": [
+                {
+                  "name": "next",
+                  "type": {
+                    "text": "string"
+                  }
+                }
+              ],
+              "description": "Refuses every change while read-only. See `readOnly`.",
+              "inheritedFrom": {
+                "name": "MixinControllerValue",
+                "module": "src/mixins/mixin-controller-value/mixin-controller-value.ts"
+              },
+              "type": {
+                "text": "requestValue(next: string) => boolean"
+              }
+            },
             {
               "kind": "field",
               "name": "move",
@@ -19266,7 +19327,18 @@
                   "text": "void"
                 }
               },
-              "description": "Reports the color to the form.\n\n**The one thing a form-associated element owes, and this element owed it\nfrom the start without paying.** It extends `HelixFormElement`, takes\n`MixinControllerValue` and carries `name`, so a consumer writing\n`<helix-color-picker name=\"brand\">` inside a form has every reason to\nexpect an entry, and the form carried none: no error, nothing in the\nmarkup to look at, and a field silently missing from the submission. Its\ntwo siblings in the same composition position, Color Input and Slider,\nboth report.\n\n`null` rather than an empty string where there is no color, which is the\ndifference between a control that submits nothing and one that submits a\nblank. There is no `setValidity` beside it: this element does not take\n`MixinField`, and every validity member of `ElementInternals` is the\nconsumer's to reach through the field that wraps it."
+              "description": "Reports the color to the form.\n\n**The one thing a form-associated element owes, and this element owed it\nfrom the start without paying.** It extends `HelixFormElement`, takes\n`MixinControllerValue` and carries `name`, so a consumer writing\n`<helix-color-picker name=\"brand\">` inside a form has every reason to\nexpect an entry, and the form carried none: no error, nothing in the\nmarkup to look at, and a field silently missing from the submission. Its\ntwo siblings in the same composition position, Color Input and Slider,\nboth report.\n\n`null` rather than an empty string where there is no color, which is the\ndifference between a control that submits nothing and one that submits a\nblank.\n\nThe verdict goes beside it, because `required` is this element's own claim\nand nothing else can answer it: a picker standing on a page has no field\naround it to check on its behalf. What it is *not* is a second opinion on\neverything else, which is why bad input is left to Color Input. See\n`required`."
+            },
+            {
+              "kind": "method",
+              "name": "reportRequired",
+              "privacy": "private",
+              "return": {
+                "type": {
+                  "text": "void"
+                }
+              },
+              "description": "Reports \"required and empty\", or clears it.\n\nAnchored on the square, which is where a reader would go to answer: it is\nthe first control in the panel and the one `focus` puts the keyboard on, so\nthe browser's bubble points at the thing to do rather than at the row that\nstates the result."
             },
             {
               "kind": "method",
@@ -19352,6 +19424,31 @@
               ],
               "description": "One axis of the area, taken the way `takeChannel` takes a rail.\n\n**Named rather than inline because of the first line.** The `<input\ntype=\"range\">` behind each axis sends its own composed `input`, which\nreaches a consumer listening on this element beside this element's own\nunless it is stopped: a consumer dragging the area receives the range's\nevent and not this component's."
             },
+            {
+              "kind": "method",
+              "name": "putBack",
+              "privacy": "private",
+              "return": {
+                "type": {
+                  "text": "void"
+                }
+              },
+              "parameters": [
+                {
+                  "name": "control",
+                  "type": {
+                    "text": "{ value: string }"
+                  }
+                },
+                {
+                  "name": "at",
+                  "type": {
+                    "text": "number"
+                  }
+                }
+              ],
+              "description": "Returns a control that moved itself to what the model still holds.\n\n**A refusal has to undo something, and here it is a handle.** Every other\ncontrol in this picker is drawn from the model, so refusing the change\nleaves the picture right on its own. The two area ranges and the two\nchannel sliders are not: each moved before it announced, and each is bound\nwith `.value`, which lit dirty-checks against the value it last committed.\nThe model never changed, so that binding writes nothing and the handle\nstays where the reader dragged it, on a control that refused. Carousel\nsettles the same question the same way: a refusal puts the track back on\nthe slide the index still holds."
+            },
             {
               "kind": "method",
               "name": "takeChannel",
@@ -19459,31 +19556,6 @@
                 "module": "src/mixins/mixin-controller-value/mixin-controller-value.ts"
               }
             },
-            {
-              "kind": "method",
-              "name": "requestValue",
-              "return": {
-                "type": {
-                  "text": "boolean"
-                }
-              },
-              "parameters": [
-                {
-                  "name": "next",
-                  "type": {
-                    "text": "string"
-                  }
-                }
-              ],
-              "description": "Requests a new value, and reports whether the request stood.\n\nAnnounces before it acts, so `preventDefault()` on the `helix-before-change` is\na refusal and nothing moves. Nobody refusing means the control updates\nitself, whether or not a consumer declared `value`: a declared property\nis a seed and a correction, the way `<input value>` is, and a consumer\nwho wants the change for themselves refuses it and assigns their own.",
-              "inheritedFrom": {
-                "name": "MixinControllerValue",
-                "module": "src/mixins/mixin-controller-value/mixin-controller-value.ts"
-              },
-              "type": {
-                "text": "requestValue(next: string) => boolean"
-              }
-            },
             {
               "kind": "method",
               "name": "formResetCallback",
@@ -20120,6 +20192,24 @@
               "description": "Whether to leave the value out, for a picker whose value is stated elsewhere.\n\nThe row reads the color as text and lets it be typed or pasted, which is\nwhat makes this element complete standing on a page: a square and two ramps\ncan build a color and cannot state one, and a reader who has a hex already\nshould not have to find it by dragging.\n\nColor Input sets this, because its field is that input. Two editable fields\nfor one value is the outcome worth avoiding: two places to type, and no\nanswer to which one is authoritative or which has the caret. Do not close it\nthe other way round, with Color Input dropping its own field: the value\nwould then be unreadable and unpasteable without opening a panel.",
               "fieldName": "noValue"
             },
+            {
+              "name": "readonly",
+              "type": {
+                "text": "boolean"
+              },
+              "default": "false",
+              "description": "Whether the control refuses changes while still submitting its value.\n\n**Enforced by refusing every request in one place**, which is the seam this\ncomponent already has: `requestValue` is what every path here comes through,\nand gating it once is what stops the next call site from being written\nwithout the check.\n\nNot `disabled`, which is the confusion worth naming: a disabled control\nsubmits nothing and leaves the tab order, and a read-only one submits its\nvalue and stays reachable, which is what a form showing a color somebody\nelse set needs.\n\n**One gate is not enough here, and the second is `move`.** This picker\nholds a model beside its value, which Date Picker and Time Picker do not:\n`moved` is the HSB the square is drawn from, and it is written before the\nvalue is requested. Gating only the request would leave the square under\nthe reader's pointer and the value where it was, which is a control that\nrefuses and looks like it accepted.",
+              "fieldName": "readOnly"
+            },
+            {
+              "name": "required",
+              "type": {
+                "text": "boolean"
+              },
+              "default": "false",
+              "description": "Whether the form refuses to submit while no color is chosen.\n\n**A color is exactly as requirable as a date**, which is the comparison\nthat settles it: this element extends `HelixFormElement`, carries `name`\nand reports its value, so a consumer writing\n`<helix-color-picker name=\"brand\" required>` inside a form has every reason\nto expect the form to refuse an empty one. Its two siblings in the same\ncomposition position, Date Picker and Time Picker, both check it.\n\nWritten out rather than taken from `MixinField`, for the reason those two\nrecord: the mixin brings a label, a hint and a feedback region, and this is\na panel composed *into* a field that already has all three, so taking it\nwould give one control two of each. What is left is the validity call and\nthe anchor the browser points its bubble at.\n\n**Emptiness is the only fault reported, and bad input deliberately is\nnot.** The value row is typed into a character at a time and every\nkeystroke reaches `requestValue`, so `#0`, `#00` and `#00f` would each be a\nreported fault on the way to `#00ff00`. Date Picker and Time Picker can\nreport bad input because their value moves only on a commit. Color Input\nreports it for this family instead, once, against the field the reader\ntyped into.",
+              "fieldName": "required"
+            },
             {
               "name": "swatches",
               "type": {
@@ -72097,11 +72187,11 @@
               "name": "--rating-part"
             },
             {
-              "description": "The width of one step, as a fraction of a mark.",
+              "description": "Which step along the row a target is, counting from one, whatever `min` leaves open.",
               "name": "--rating-step"
             },
             {
-              "description": "How many steps one mark is divided into.",
+              "description": "How many steps the whole row holds, which is `max` over `step`.",
               "name": "--rating-steps"
             }
           ],
@@ -72110,6 +72200,10 @@
               "description": "What is wrong with it.",
               "name": "feedback"
             },
+            {
+              "description": "The row: the marks, and the score beside them.",
+              "name": "field"
+            },
             {
               "description": "The filled marks, clipped to the score.",
               "name": "fill"
@@ -72176,7 +72270,7 @@
                 "text": "number"
               },
               "default": "0",
-              "description": "The lowest score a reader can give, which is what clearing returns to.\n\nZero rather than one, because \"no rating\" and \"the worst rating\" are\ndifferent answers and a control that cannot express the first has to\npretend the second. A survey that requires an answer says so with\n`required`, not by making one unreachable.",
+              "description": "The lowest score a reader can give, which is what clearing returns to.\n\nZero rather than one, because \"no rating\" and \"the worst rating\" are\ndifferent answers and a control that cannot express the first has to\npretend the second. A survey that requires an answer says so with\n`required`, not by making one unreachable.\n\n**It is the floor of the scale, and every edge follows from that.**\n\n*Clearing* returns the row to it. An empty rating, a value nothing can\nparse, and a form reset with nothing declared are all the same situation,\nand all three draw `min` filled: at the default of zero that is the empty\nrow this always drew, and at `min=\"2\"` it is two marks, the way an empty\n`Slider` sits at its own minimum rather than at zero. The value is still\n`\"\"` through all of it, so `required` still refuses it and `valueAsNumber`\nis still `NaN`: what the row shows is the bottom of the scale, not an\nanswer somebody gave.\n\n*The steps* are the scores from `step` up to `max` that are not below it,\nso `min=\"2\"` on five marks offers 2 to 5 and leaves the first two marks\nfilled and unpressable. At zero nothing is dropped, which is why the\ndefault row is unchanged.\n\n*The keyboard* moves through those steps and no others. `wrap` is already\nfalse here, so arrowing down from the lowest one holds its ground rather\nthan reaching a score this property forbids, and the tab stop an unrated\nrating carries sits on the lowest score offered rather than on the first\nmark.\n\n*A `min` between two steps* is a floor and not a step: `min=\"1.5\"` with\nwhole marks clamps the value at 1.5 and offers 2 upward, since 1.5 is not\nsomewhere the row can be pressed. That is a real thing to ask for and is\nleft to mean what it says.\n\n*A `min` outside the marks is refused rather than obeyed*, and says so\nonce on the console. Below zero and anything that is not a number are read\nas zero, there being no mark to draw for a negative score; above `max` is\nread as `max`, which collapses the scale to its top score rather than\nleaving a rating with nothing to press. A property that silently accepts\nnonsense is the fault this pays off, so neither case is quietly ignored.",
               "attribute": "min"
             },
             {
@@ -72258,6 +72352,16 @@
               "readonly": true,
               "default": "new KeyboardNavigationController(this, { items: () => this.options, selects: () => true, wrap: false, })"
             },
+            {
+              "kind": "field",
+              "name": "floor",
+              "type": {
+                "text": "number"
+              },
+              "privacy": "private",
+              "description": "The floor the row actually uses, which is `min` where `min` is one.\n\nBetween zero and `max`, and zero for anything that is not a number, per\nthe note on `min`. Derived on read rather than corrected into the property,\nso `rating.min` still reports what the consumer set and the warning below\ncan tell the two apart.",
+              "readonly": true
+            },
             {
               "kind": "field",
               "name": "score",
@@ -72267,6 +72371,16 @@
               "description": "The score, as a number, clamped to what the marks can show.",
               "readonly": true
             },
+            {
+              "kind": "field",
+              "name": "positions",
+              "type": {
+                "text": "number[]"
+              },
+              "privacy": "private",
+              "description": "Every score the marks can show, which is `max / step` of them.\n\nThe whole row rather than the part `min` leaves open, because this is what\nthe stylesheet lays the targets out against: `--rating-steps` is the pitch\nand a step's own place in this list is where it sits along the row. Counted\nfrom the part a reader can press instead, a floor above zero would widen\nevery target and slide the row left.",
+              "readonly": true
+            },
             {
               "kind": "field",
               "name": "steps",
@@ -72274,7 +72388,7 @@
                 "text": "number[]"
               },
               "privacy": "private",
-              "description": "Every score a reader can choose, which is `max / step` of them.",
+              "description": "Every score a reader can choose, which is the positions `min` leaves open.",
               "readonly": true
             },
             {
@@ -72389,7 +72503,7 @@
                   "text": "void"
                 }
               },
-              "description": "Reports the value, and whether the form may go without one.\n\n**`required` arrives from the mixin, so it prints on the reference page\nwhether or not anything here enforces it.** Without a `setValidity` call a\nform holding an unrated required rating submits, `:valid` true and the\nentry present but empty. `reportRequired` is what makes the property real.\n\n**Empty is `value === ''` rather than a score of zero**, because zero is a\nrating a reader can deliberately give when `min` allows it, and refusing to\nsubmit it would be the control disagreeing with the property that permits\nit. What `required` asks is whether they answered at all.\n\n`Slider` is deliberately not given the same treatment: a native\n`<input type=\"range\" required>` is always valid, because a range always\nholds a number, and matching the platform there is the point."
+              "description": "Reports the value, and whether the form may go without one.\n\n**`required` arrives from the mixin, so it prints on the reference page\nwhether or not anything here enforces it.** Without a `setValidity` call a\nform holding an unrated required rating submits, `:valid` true and the\nentry present but empty. `reportRequired` is what makes the property real.\n\n**Empty is `value === ''` rather than a score at the floor**, and the two\nare not the same thing: an unanswered row draws `min`, per the note on that\nproperty, so a control that read its own picture would call every rating\nwith `min=\"2\"` answered the moment it rendered. What `required` asks is\nwhether the reader answered at all, which only the value knows. A consumer\nwho writes `value=\"0\"` has answered, and is not refused.\n\n`Slider` is deliberately not given the same treatment: a native\n`<input type=\"range\" required>` is always valid, because a range always\nholds a number, and matching the platform there is the point."
             },
             {
               "kind": "field",
@@ -72409,6 +72523,16 @@
               "privacy": "private",
               "readonly": true
             },
+            {
+              "kind": "field",
+              "name": "warned",
+              "type": {
+                "text": "boolean"
+              },
+              "privacy": "private",
+              "default": "false",
+              "description": "Whether the console has already been told about a `min` off the scale."
+            },
             {
               "kind": "field",
               "name": "valueAsNumber",
@@ -73287,7 +73411,7 @@
                 "text": "number"
               },
               "default": "0",
-              "description": "The lowest score a reader can give, which is what clearing returns to.\n\nZero rather than one, because \"no rating\" and \"the worst rating\" are\ndifferent answers and a control that cannot express the first has to\npretend the second. A survey that requires an answer says so with\n`required`, not by making one unreachable.",
+              "description": "The lowest score a reader can give, which is what clearing returns to.\n\nZero rather than one, because \"no rating\" and \"the worst rating\" are\ndifferent answers and a control that cannot express the first has to\npretend the second. A survey that requires an answer says so with\n`required`, not by making one unreachable.\n\n**It is the floor of the scale, and every edge follows from that.**\n\n*Clearing* returns the row to it. An empty rating, a value nothing can\nparse, and a form reset with nothing declared are all the same situation,\nand all three draw `min` filled: at the default of zero that is the empty\nrow this always drew, and at `min=\"2\"` it is two marks, the way an empty\n`Slider` sits at its own minimum rather than at zero. The value is still\n`\"\"` through all of it, so `required` still refuses it and `valueAsNumber`\nis still `NaN`: what the row shows is the bottom of the scale, not an\nanswer somebody gave.\n\n*The steps* are the scores from `step` up to `max` that are not below it,\nso `min=\"2\"` on five marks offers 2 to 5 and leaves the first two marks\nfilled and unpressable. At zero nothing is dropped, which is why the\ndefault row is unchanged.\n\n*The keyboard* moves through those steps and no others. `wrap` is already\nfalse here, so arrowing down from the lowest one holds its ground rather\nthan reaching a score this property forbids, and the tab stop an unrated\nrating carries sits on the lowest score offered rather than on the first\nmark.\n\n*A `min` between two steps* is a floor and not a step: `min=\"1.5\"` with\nwhole marks clamps the value at 1.5 and offers 2 upward, since 1.5 is not\nsomewhere the row can be pressed. That is a real thing to ask for and is\nleft to mean what it says.\n\n*A `min` outside the marks is refused rather than obeyed*, and says so\nonce on the console. Below zero and anything that is not a number are read\nas zero, there being no mark to draw for a negative score; above `max` is\nread as `max`, which collapses the scale to its top score rather than\nleaving a rating with nothing to press. A property that silently accepts\nnonsense is the fault this pays off, so neither case is quietly ignored.",
               "fieldName": "min"
             },
             {
@@ -93647,7 +93771,7 @@
         },
         {
           "kind": "class",
-          "description": "**A list rather than three wheels**, and the reason is what a list already\nis. `helix-listbox` brings the keyboard, the typeahead, the scroll into view\nand the announcement of a set of options, and a time at a step is a set of\noptions. Three little wheels for hours, minutes and a meridiem are three\ncontrols to build, three to test, and a tab stop each for something a reader\nanswers once.\n\n**A step is what makes it a list at all.** Fifteen minutes is ninety-six rows,\nwhich a reader scrolls or types into; one minute is one thousand four hundred\nand forty, which is a listbox in name only. So the list is for the times a\nproduct actually offers, and arbitrary times are the field's job in Input\nTime, the same division Date Input draws between typing a date and using the\ncalendar.\n\n**The value is `HH:mm` on a twenty-four hour clock, always.** That is what a\nform submits and what `min` and `max` compare against, and it sorts as a\nstring, which is the whole reason the shape is that one. What each row *says*\nis the reader's own convention, from `Intl`.",
+          "description": "**A list rather than three wheels**, and the reason is what a list already\nis. `helix-listbox` brings the keyboard, the typeahead, the scroll into view\nand the announcement of a set of options, and a time at a step is a set of\noptions. Three little wheels for hours, minutes and a meridiem are three\ncontrols to build, three to test, and a tab stop each for something a reader\nanswers once.\n\n**A step is what makes it a list at all.** Fifteen minutes is ninety-six rows,\nwhich a reader scrolls or types into; one minute is one thousand four hundred\nand forty, which is a listbox in name only. So the list is for the times a\nproduct actually offers, and arbitrary times are the field's job in Input\nTime, the same division Date Input draws between typing a date and using the\ncalendar.\n\n**The value is `HH:mm` on a twenty-four hour clock, always.** That is what a\nform submits and what `min` and `max` compare against, and it sorts as a\nstring, which is the whole reason the shape is that one. What each row *says*\nis the reader's own convention, from `Intl`.\n\n**The chosen row is marked in the markup, not worked out on upgrade.** The\nlistbox is handed the answer as `.value`, and lit-ssr serializes no property\nbinding, so a served `value=\"09:30\"` shipped ninety-six rows with nothing on\nany of them saying which one it was: the mark arrived when the listbox\nupgraded and ran `place`. So each option is given `selected` as well, which\nis an attribute binding and does serve, and which the listbox then agrees\nwith rather than fights, `place` writing the same answer from the same value.\n`selected` is the declaration a consumer writes on `Option` anywhere else in\nthe library, and Date Picker expresses its own choice as markup for the same\nreason: a picker whose answer is invisible until a script runs is a picker\nwhose answer is not served at all. Both readings do it, the list and the\nwheels, a wheel being a listbox like the list is.",
           "name": "HelixHeadlessTimePicker",
           "cssParts": [
             {

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

@@ -44,6 +44,7 @@ import { type PropertyValues, type TemplateResult } from 'lit';
  *
  * @cssproperty --carousel-gap - Space between slides. A sheet sets it and the component measures the run with it.
  * @cssproperty --carousel-pane - The size one pane is laid out at. A sheet sets it and the component measures the run with it.
+ * @cssproperty --carousel-per-view - How many slides go across, written onto the track by the component so a sheet divides the track by the same number the positions are counted from. Read it rather than selecting on `per-view`, which cannot be enumerated without a ceiling. See `perView`.
  * @cssproperty --carousel-run-end - How far short of a whole pixel the run ends, on the last slide alone, for a sheet to take up as `margin-inline-end`. See `runEnd`.
  */
 export declare class HelixHeadlessCarousel extends HelixElement {
@@ -161,12 +162,53 @@ export declare class HelixHeadlessCarousel extends HelixElement {
      * offset the track has already reached: pressing next walks the dots to the
      * end while the slides stop moving a third of the way through.
      *
+     * **The number is published to the styles rather than enumerated by them**,
+     * as `--carousel-per-view` on the track, which is what keeps a width and a
+     * count from disagreeing. A sheet can only name a value it wrote a rule for,
+     * so the styled tier enumerated `per-view="2"` through `5` and called five a
+     * judgment; above it the pane fell back to one across while this file went on
+     * counting positions. Measured in Chromium over eight slides, six across gave
+     * three dots, a pane taking the whole track and five slides reachable only by
+     * dragging. Written from here there is no ceiling to exceed, and a consumer's
+     * own sheet reads the same declaration the styled one does. `runEnd` publishes
+     * its correction the same way and for the same reason.
+     *
+     * **On the track and not on the host.** A custom property on the host is a
+     * reflected attribute by another name: it would arrive on upgrade, and a
+     * consumer's server markup never had it. Inside the component's own shadow
+     * root it serializes with the rest of the template on the server, and the
+     * track's own declaration beats anything a consumer inherits in, so the
+     * attribute is the one answer to how wide a pane is.
+     *
+     * A value the track cannot honor is taken to the nearest one it can, by
+     * `across`, and both tiers read that rather than this.
+     *
      * No default, because it reflects. A reflected property with a value writes
      * its attribute on upgrade, and the host then carries something a consumer's
      * server markup never had, which React reports as a mismatch. The one-across
      * case is the absent attribute, and the styles read it that way.
      */
     perView?: number;
+    /**
+     * `perView` as both tiers use it: a whole number of slides, one at least.
+     *
+     * **The clamp is here because the arithmetic is here**, and the two readers
+     * of this number have to be given the same one. A fraction is floored, since
+     * a position is a whole slide along: one and a half across leaves a last
+     * position the track runs out before reaching, which is the fault `goTo`
+     * already carries a comment about. Zero and a negative divide the track into
+     * nothing and into a pane facing the wrong way, and a non-numeric attribute
+     * parses to `NaN`, which `Math.max` propagates: it counted `NaN` positions,
+     * drew no indicators at all and left `index` at `NaN`. All of them read as
+     * one across, which is what a carousel with nothing sayable asked for.
+     *
+     * Not clamped to the number of slides. Six across four slides is four panes
+     * at a sixth of the track each and the one place to stand, which is what was
+     * asked for as nearly as it can be had, and the slide count is a fact the
+     * server does not have: clamping to it would draw one width there and another
+     * on upgrade.
+     */
+    private get across();
     /**
      * How many distinct views the track holds, which is what the indicators count.
      *

package/dist/carousel/root/carousel-root.js

@@ -95,9 +95,12 @@ let HelixHeadlessCarousel = class HelixHeadlessCarousel extends HelixElement {
         this.indexState = next;
         this.requestUpdate('index', previous);
     }
+    get across() {
+        const asked = this.perView ?? 1;
+        return Number.isFinite(asked) ? Math.max(1, Math.floor(asked)) : 1;
+    }
     get positions() {
-        const across = Math.max(1, Math.floor(this.perView ?? 1));
-        return Math.max(1, this.slides.length - across + 1);
+        return Math.max(1, this.slides.length - this.across + 1);
     }
     get panes() {
         return [...(this.renderRoot?.querySelectorAll?.('[part="slide"]') ?? [])];
@@ -305,6 +308,7 @@ let HelixHeadlessCarousel = class HelixHeadlessCarousel extends HelixElement {
       <div
         data-scroller
         part="track"
+        style=${`--carousel-per-view: ${this.across}`}
         @scroll=${this.handleTrackScroll}
         @scrollend=${this.handleScroll}
         @pointerdown=${this.handleTake}

package/dist/color-picker/root/color-picker-root.d.ts

@@ -128,6 +128,52 @@ export declare class HelixHeadlessColorPicker extends HelixHeadlessColorPicker_b
      * would then be unreadable and unpasteable without opening a panel.
      */
     noValue: boolean;
+    /**
+     * Whether the control refuses changes while still submitting its value.
+     *
+     * **Enforced by refusing every request in one place**, which is the seam this
+     * component already has: `requestValue` is what every path here comes through,
+     * and gating it once is what stops the next call site from being written
+     * without the check.
+     *
+     * Not `disabled`, which is the confusion worth naming: a disabled control
+     * submits nothing and leaves the tab order, and a read-only one submits its
+     * value and stays reachable, which is what a form showing a color somebody
+     * else set needs.
+     *
+     * **One gate is not enough here, and the second is `move`.** This picker
+     * holds a model beside its value, which Date Picker and Time Picker do not:
+     * `moved` is the HSB the square is drawn from, and it is written before the
+     * value is requested. Gating only the request would leave the square under
+     * the reader's pointer and the value where it was, which is a control that
+     * refuses and looks like it accepted.
+     */
+    readOnly: boolean;
+    /**
+     * Whether the form refuses to submit while no color is chosen.
+     *
+     * **A color is exactly as requirable as a date**, which is the comparison
+     * that settles it: this element extends `HelixFormElement`, carries `name`
+     * and reports its value, so a consumer writing
+     * `<helix-color-picker name="brand" required>` inside a form has every reason
+     * to expect the form to refuse an empty one. Its two siblings in the same
+     * composition position, Date Picker and Time Picker, both check it.
+     *
+     * Written out rather than taken from `MixinField`, for the reason those two
+     * record: the mixin brings a label, a hint and a feedback region, and this is
+     * a panel composed *into* a field that already has all three, so taking it
+     * would give one control two of each. What is left is the validity call and
+     * the anchor the browser points its bubble at.
+     *
+     * **Emptiness is the only fault reported, and bad input deliberately is
+     * not.** The value row is typed into a character at a time and every
+     * keystroke reaches `requestValue`, so `#0`, `#00` and `#00f` would each be a
+     * reported fault on the way to `#00ff00`. Date Picker and Time Picker can
+     * report bad input because their value moves only on a commit. Color Input
+     * reports it for this family instead, once, against the field the reader
+     * typed into.
+     */
+    required: boolean;
     /**
      * Colors offered under the picker, as a comma-separated list.
      */
@@ -183,6 +229,8 @@ export declare class HelixHeadlessColorPicker extends HelixHeadlessColorPicker_b
     private settled;
     /** Takes what was typed, and lets the square follow only a whole color. */
     private readonly handleValueInput;
+    /** Refuses every change while read-only. See `readOnly`. */
+    requestValue(next: string): boolean;
     /** Moves part of the model and announces the value that follows from it. */
     private readonly move;
     /**
@@ -237,11 +285,24 @@ export declare class HelixHeadlessColorPicker extends HelixHeadlessColorPicker_b
      *
      * `null` rather than an empty string where there is no color, which is the
      * difference between a control that submits nothing and one that submits a
-     * blank. There is no `setValidity` beside it: this element does not take
-     * `MixinField`, and every validity member of `ElementInternals` is the
-     * consumer's to reach through the field that wraps it.
+     * blank.
+     *
+     * The verdict goes beside it, because `required` is this element's own claim
+     * and nothing else can answer it: a picker standing on a page has no field
+     * around it to check on its behalf. What it is *not* is a second opinion on
+     * everything else, which is why bad input is left to Color Input. See
+     * `required`.
      */
     private sync;
+    /**
+     * Reports "required and empty", or clears it.
+     *
+     * Anchored on the square, which is where a reader would go to answer: it is
+     * the first control in the panel and the one `focus` puts the keyboard on, so
+     * the browser's bubble points at the thing to do rather than at the row that
+     * states the result.
+     */
+    private reportRequired;
     protected updated(changed: import('lit').PropertyValues): void;
     /** Puts the keyboard on the square, which is the control a reader wants. */
     focus(options?: FocusOptions): void;
@@ -262,6 +323,20 @@ export declare class HelixHeadlessColorPicker extends HelixHeadlessColorPicker_b
      * event and not this component's.
      */
     private takeArea;
+    /**
+     * Returns a control that moved itself to what the model still holds.
+     *
+     * **A refusal has to undo something, and here it is a handle.** Every other
+     * control in this picker is drawn from the model, so refusing the change
+     * leaves the picture right on its own. The two area ranges and the two
+     * channel sliders are not: each moved before it announced, and each is bound
+     * with `.value`, which lit dirty-checks against the value it last committed.
+     * The model never changed, so that binding writes nothing and the handle
+     * stays where the reader dragged it, on a control that refused. Carousel
+     * settles the same question the same way: a refusal puts the track back on
+     * the slide the index still holds.
+     */
+    private putBack;
     /**
      * A channel's new value, read off the slider that just applied it.
      *