@fusion.dev/helix-headless 0.53.6 → 0.55.0

package/custom-elements.json

@@ -4974,23 +4974,13 @@
             }
           ],
           "members": [
-            {
-              "kind": "field",
-              "name": "direction",
-              "type": {
-                "text": "'horizontal' | undefined"
-              },
-              "description": "Whether the categories run down the side rather than along the bottom.\n\nAbsent is columns. `horizontal` is the one to reach for when the category\nnames are words rather than dates: a row of long names either overlaps or\nturns on its side, and neither is as readable as putting them down the left\nwhere they read normally.",
-              "attribute": "direction",
-              "reflects": true
-            },
             {
               "kind": "field",
               "name": "gridlines",
               "type": {
                 "text": "'both' | 'category' | 'value' | undefined"
               },
-              "description": "Which rules are drawn across the plot, if any.\n\nAbsent draws none. `value` rules the axis the columns are *measured* on,\n`category` rules the axis they are *arranged* on with one through each\ngroup, and `both` draws both. Which of those is horizontal turns with\n`direction`, because a rule belongs to an axis and not to a screen edge.\n\n**A bare `gridlines` means `value`**, and so does anything unrecognized: an\nunrecognized value that draws nothing is indistinguishable from the\nattribute being absent, which is the one thing a reader cannot debug.\n\n`category` is the quieter half of this on a bar chart: columns already\ndivide the categories by being separate columns, and a rule through each\none is a second statement of the same fact. It earns its place on a chart\nof many thin bars, where the eye has stopped counting.\n\nFurniture rather than data, so the rules are inside the `aria-hidden` plot\nand reach no reader through the table.",
+              "description": "Which rules are drawn across the plot, if any.\n\nAbsent draws none. `value` rules the axis the columns are *measured* on,\n`category` rules the axis they are *arranged* on with one through each\ngroup, and `both` draws both. Which of those is horizontal turns with\n`orientation`, because a rule belongs to an axis and not to a screen edge.\n\n**A bare `gridlines` means `value`**, and so does anything unrecognized: an\nunrecognized value that draws nothing is indistinguishable from the\nattribute being absent, which is the one thing a reader cannot debug.\n\n`category` is the quieter half of this on a bar chart: columns already\ndivide the categories by being separate columns, and a rule through each\none is a second statement of the same fact. It earns its place on a chart\nof many thin bars, where the eye has stopped counting.\n\nFurniture rather than data, so the rules are inside the `aria-hidden` plot\nand reach no reader through the table.",
               "attribute": "gridlines"
             },
             {
@@ -5002,6 +4992,16 @@
               "description": "Which series are drawn as a line instead of as columns, by name.\n\nSeparated by whitespace or commas and matched against the column headings\nthe table gives, so a chart says `lines=\"Margin\"` rather than counting\ncolumns. Names because they are what the table already carries and what the\nlegend already shows: an index is a fourth place the column order is\nwritten down and the first one to go stale when somebody moves a column.\n\n**This says which mark a series takes and nothing about which scale it is\nmeasured on.** Named here alone, a line shares the columns' domain, so it\nsays something comparable to the columns beside it.\n\nThe other half of a combination chart, a count against a percentage on a\nscale of its own, is `secondary`, which is a separate property because it\nis a separate question and because the two compose: `with-a-second-axis`\nships naming one series in both. The argument for why a second scale is opt\nin, and why setting it labels both axes, is written there.\n\nA line among columns measures from zero, because the columns do and they\nshare the axis. So does a line on the second scale, which is that scale's\nown rule rather than this one's.",
               "attribute": "lines"
             },
+            {
+              "kind": "field",
+              "name": "orientation",
+              "type": {
+                "text": "'horizontal' | undefined"
+              },
+              "description": "Whether the categories run down the side rather than along the bottom.\n\nAbsent is columns. `horizontal` is the one to reach for when the category\nnames are words rather than dates: a row of long names either overlaps or\nturns on its side, and neither is as readable as putting them down the left\nwhere they read normally.\n\n`orientation` and not `orientation`, which `Trend` uses in the same group for\nwhich way a number moved.",
+              "attribute": "orientation",
+              "reflects": true
+            },
             {
               "kind": "field",
               "name": "secondary",
@@ -5187,7 +5187,7 @@
                   }
                 }
               ],
-              "description": "The grid, behind everything, or nothing at all.\n\nAcross the measured axis, which turns with `direction`: a rule belongs to\nthe axis the bars are measured on and not the one they are arranged on, so\ncolumns get horizontal rules and rows get vertical ones. Getting that\nbackwards draws a grid that divides the categories, which are already\ndivided by being separate bars.\n\nDrawn before the baseline, so where a gridline and zero coincide the\nbaseline is what shows: zero is a fact about the data and a gridline is a\nruler."
+              "description": "The grid, behind everything, or nothing at all.\n\nAcross the measured axis, which turns with `orientation`: a rule belongs to\nthe axis the bars are measured on and not the one they are arranged on, so\ncolumns get horizontal rules and rows get vertical ones. Getting that\nbackwards draws a grid that divides the categories, which are already\ndivided by being separate bars.\n\nDrawn before the baseline, so where a gridline and zero coincide the\nbaseline is what shows: zero is a fact about the data and a gridline is a\nruler."
             },
             {
               "kind": "method",
@@ -5753,20 +5753,12 @@
             }
           ],
           "attributes": [
-            {
-              "name": "direction",
-              "type": {
-                "text": "'horizontal' | undefined"
-              },
-              "description": "Whether the categories run down the side rather than along the bottom.\n\nAbsent is columns. `horizontal` is the one to reach for when the category\nnames are words rather than dates: a row of long names either overlaps or\nturns on its side, and neither is as readable as putting them down the left\nwhere they read normally.",
-              "fieldName": "direction"
-            },
             {
               "name": "gridlines",
               "type": {
                 "text": "'both' | 'category' | 'value' | undefined"
               },
-              "description": "Which rules are drawn across the plot, if any.\n\nAbsent draws none. `value` rules the axis the columns are *measured* on,\n`category` rules the axis they are *arranged* on with one through each\ngroup, and `both` draws both. Which of those is horizontal turns with\n`direction`, because a rule belongs to an axis and not to a screen edge.\n\n**A bare `gridlines` means `value`**, and so does anything unrecognized: an\nunrecognized value that draws nothing is indistinguishable from the\nattribute being absent, which is the one thing a reader cannot debug.\n\n`category` is the quieter half of this on a bar chart: columns already\ndivide the categories by being separate columns, and a rule through each\none is a second statement of the same fact. It earns its place on a chart\nof many thin bars, where the eye has stopped counting.\n\nFurniture rather than data, so the rules are inside the `aria-hidden` plot\nand reach no reader through the table.",
+              "description": "Which rules are drawn across the plot, if any.\n\nAbsent draws none. `value` rules the axis the columns are *measured* on,\n`category` rules the axis they are *arranged* on with one through each\ngroup, and `both` draws both. Which of those is horizontal turns with\n`orientation`, because a rule belongs to an axis and not to a screen edge.\n\n**A bare `gridlines` means `value`**, and so does anything unrecognized: an\nunrecognized value that draws nothing is indistinguishable from the\nattribute being absent, which is the one thing a reader cannot debug.\n\n`category` is the quieter half of this on a bar chart: columns already\ndivide the categories by being separate columns, and a rule through each\none is a second statement of the same fact. It earns its place on a chart\nof many thin bars, where the eye has stopped counting.\n\nFurniture rather than data, so the rules are inside the `aria-hidden` plot\nand reach no reader through the table.",
               "fieldName": "gridlines"
             },
             {
@@ -5777,6 +5769,14 @@
               "description": "Which series are drawn as a line instead of as columns, by name.\n\nSeparated by whitespace or commas and matched against the column headings\nthe table gives, so a chart says `lines=\"Margin\"` rather than counting\ncolumns. Names because they are what the table already carries and what the\nlegend already shows: an index is a fourth place the column order is\nwritten down and the first one to go stale when somebody moves a column.\n\n**This says which mark a series takes and nothing about which scale it is\nmeasured on.** Named here alone, a line shares the columns' domain, so it\nsays something comparable to the columns beside it.\n\nThe other half of a combination chart, a count against a percentage on a\nscale of its own, is `secondary`, which is a separate property because it\nis a separate question and because the two compose: `with-a-second-axis`\nships naming one series in both. The argument for why a second scale is opt\nin, and why setting it labels both axes, is written there.\n\nA line among columns measures from zero, because the columns do and they\nshare the axis. So does a line on the second scale, which is that scale's\nown rule rather than this one's.",
               "fieldName": "lines"
             },
+            {
+              "name": "orientation",
+              "type": {
+                "text": "'horizontal' | undefined"
+              },
+              "description": "Whether the categories run down the side rather than along the bottom.\n\nAbsent is columns. `horizontal` is the one to reach for when the category\nnames are words rather than dates: a row of long names either overlaps or\nturns on its side, and neither is as readable as putting them down the left\nwhere they read normally.\n\n`orientation` and not `orientation`, which `Trend` uses in the same group for\nwhich way a number moved.",
+              "fieldName": "orientation"
+            },
             {
               "name": "secondary",
               "type": {
@@ -19169,17 +19169,13 @@
               "name": "format-button"
             },
             {
-              "description": "The saturation and brightness square.",
+              "description": "The saturation and brightness square. The mark showing where in the square the color sits is drawn on the square itself, which is `::part(grid)::after` from a consumer's sheet: the two channels are already on the square as `--color-picker-saturation` and `--color-picker-brightness`, so a box would have carried nothing, and this tier ships no CSS.",
               "name": "grid"
             },
             {
               "description": "The range input for its vertical axis.",
               "name": "grid-brightness"
             },
-            {
-              "description": "The mark showing where in the square the color sits.",
-              "name": "grid-handle"
-            },
             {
               "description": "The range input for the square's horizontal axis.",
               "name": "grid-saturation"
@@ -24745,7 +24741,7 @@
       "declarations": [
         {
           "kind": "class",
-          "description": "**The schema is markup and the data is a property.** Columns are declared as\n`TableColumn` children, because a schema is small and something a reader\nshould see in the HTML; rows are handed over as an array, because a table\nthat draws ten thousand elements cannot window them.\n\n```html\n<helix-headless-data-table .rows=${rows} sort=\"name:asc\" page-size=\"20\">\n  <helix-headless-table-column field=\"name\" sortable>Name</helix-headless-table-column>\n  <helix-headless-table-column field=\"size\" align=\"end\" sortable .cell=${bytes}>Size</helix-headless-table-column>\n</helix-headless-data-table>\n```\n\n`Table` takes rows as markup and is the right component for a table of twelve\nthings a person wrote out.\n\n**Sort and filter apply to the whole set, never the page.** Sorting the drawn\nwindow is correct on the first screen and wrong on every other one.\n\n**The cell values do not server-render.** The headings do, and the row\nelements do, but reading a cell needs the columns, and the columns are markup\nchildren Lit SSR does not hand this element. So a crawler sees a table of the\nright shape with nothing in it. That is the cost of the first paragraph: use\n`Table` where the served HTML has to carry the values.\n\n**`selectable` adds a column of checkboxes, keyed on `row-key`.** A row is\nselected by its identity rather than its position, so a selection survives a\nsort, a filter and a page. `selected` is the chosen keys, comma separated, the\nshape Listbox uses for a multiple choice, and like `sort` writing it applies\nwhile `default-selected` is what the markup declared. The box in the heading\nselects every row in the result, across pages, and shows a dash while only\nsome are chosen.\nChoosing one of many, rather than several, is opening a row, and that is a\nlink or a button in a cell rather than a selection.\n\n**A reader can size and order the columns.** `resizable` on a column puts a\nseparator on its edge; `reorderable` on the table puts a grip on each heading\nthat has a `field`, moved by dragging or with the arrow keys. The order lands\nin `order` as fields, and the consumer's own markup is never rewritten: the\ntable assigns the headings to its header in that order instead.\n\n**`csv()` hands back the result as text**: every row the filter lets through,\nin the order on screen, in the columns on screen. Saving it is the page's\nbusiness, the same as any other file.\n\n**There is no `columns` attribute here, and Table has one.** The difference\nis what a column is in each: here it is the schema, so a table without one\nhas nothing to read a row with, and every column is a place to write a\n`width`. A Table holds cells a consumer wrote and can be written with no\ncolumn at all, so its `columns` is where such a table is sized from. Written\non this element the attribute is inert, which is the trap worth knowing when\nmoving between the two.",
+          "description": "**The schema is markup and the data is a property.** Columns are declared as\n`TableColumn` children, because a schema is small and something a reader\nshould see in the HTML; rows are handed over as an array, because a table\nthat draws ten thousand elements cannot window them.\n\n```html\n<helix-headless-data-table .rows=${rows} sort=\"name:asc\" page-size=\"20\">\n  <helix-headless-table-column field=\"name\" sortable>Name</helix-headless-table-column>\n  <helix-headless-table-column field=\"size\" text-align=\"end\" sortable .cell=${bytes}>Size</helix-headless-table-column>\n</helix-headless-data-table>\n```\n\n`Table` takes rows as markup and is the right component for a table of twelve\nthings a person wrote out.\n\n**Sort and filter apply to the whole set, never the page.** Sorting the drawn\nwindow is correct on the first screen and wrong on every other one.\n\n**The cell values do not server-render.** The headings do, and the row\nelements do, but reading a cell needs the columns, and the columns are markup\nchildren Lit SSR does not hand this element. So a crawler sees a table of the\nright shape with nothing in it. That is the cost of the first paragraph: use\n`Table` where the served HTML has to carry the values.\n\n**`selectable` adds a column of checkboxes, keyed on `row-key`.** A row is\nselected by its identity rather than its position, so a selection survives a\nsort, a filter and a page. `selected` is the chosen keys, comma separated, the\nshape Listbox uses for a multiple choice, and like `sort` writing it applies\nwhile `default-selected` is what the markup declared. The box in the heading\nselects every row in the result, across pages, and shows a dash while only\nsome are chosen.\nChoosing one of many, rather than several, is opening a row, and that is a\nlink or a button in a cell rather than a selection.\n\n**A reader can size and order the columns.** `resizable` on a column puts a\nseparator on its edge; `reorderable` on the table puts a grip on each heading\nthat has a `field`, moved by dragging or with the arrow keys. The order lands\nin `order` as fields, and the consumer's own markup is never rewritten: the\ntable assigns the headings to its header in that order instead.\n\n**`csv()` hands back the result as text**: every row the filter lets through,\nin the order on screen, in the columns on screen. Saving it is the page's\nbusiness, the same as any other file.\n\n**There is no `columns` attribute here, and Table has one.** The difference\nis what a column is in each: here it is the schema, so a table without one\nhas nothing to read a row with, and every column is a place to write a\n`width`. A Table holds cells a consumer wrote and can be written with no\ncolumn at all, so its `columns` is where such a table is sized from. Written\non this element the attribute is inert, which is the trap worth knowing when\nmoving between the two.",
           "name": "HelixHeadlessDataTable",
           "cssProperties": [
             {
@@ -25790,7 +25786,7 @@
                   }
                 }
               ],
-              "description": "One cell, carrying its column's edge as a fact rather than as a decision.\n\n**A fact published rather than a property chosen**, which is what `Table`\ndoes with the same attribute: what lining up *means*, a `justify-content`\nfor a value that fits or a `text-align` for one that wraps, belongs to\nwhoever draws the cell. Written here as an inline `text-align` it was this\ntier choosing, in the tier that ships no CSS, and a consumer could not\noverrule it either, an inline declaration beating any `::part(cell)` rule\nthey wrote.\n\nOnly the three edges reach it, `align` being a string anybody can write and\nthis being a style attribute: `edgeOf` is that guard, and `Table` holds the\nsame value to the same three."
+              "description": "One cell, carrying its column's edge as a fact rather than as a decision.\n\n**A fact published rather than a property chosen**, which is what `Table`\ndoes with the same attribute: what lining up *means*, a `justify-content`\nfor a value that fits or a `text-align` for one that wraps, belongs to\nwhoever draws the cell. Written here as an inline `text-align` it was this\ntier choosing, in the tier that ships no CSS, and a consumer could not\noverrule it either, an inline declaration beating any `::part(cell)` rule\nthey wrote.\n\nOnly the three edges reach it, `text-align` being a string anybody can write and\nthis being a style attribute: `edgeOf` is that guard, and `Table` holds the\nsame value to the same three."
             },
             {
               "kind": "method",
@@ -49308,7 +49304,7 @@
           "name": "HelixHeadlessLegend",
           "cssParts": [
             {
-              "description": "One name and its swatch.",
+              "description": "One name and its swatch. The swatch is drawn on the entry, which is `::part(entry)::before` from a consumer's sheet: the series is already on the entry as `--chart-series`, so a box would have carried nothing, and this tier ships no CSS.",
               "name": "entry"
             },
             {
@@ -49318,10 +49314,6 @@
             {
               "description": "One series name.",
               "name": "name"
-            },
-            {
-              "description": "The color a series is drawn in.",
-              "name": "swatch"
             }
           ],
           "members": [
@@ -54072,13 +54064,13 @@
           "members": [
             {
               "kind": "field",
-              "name": "fullBelow",
+              "name": "bandBelow",
               "type": {
                 "text": "number"
               },
               "default": "640",
               "description": "The width, in pixels, under which a card becomes a band. Zero never does.\n\nA card is a panel hung off one word, and there is no room to hang anything\noff a word on a phone: the columns do not shrink past\n`--megamenu-column-size`, so four of them stay four of them and the panel\nruns off the side of the screen rather than reflowing. Below this it takes\nthe whole width and its columns stack, which is the only arrangement that\nfits.\n\n**In script rather than a media query, and only once.** Whether the panel is\na band is not a question of paint: a band is not placed against the trigger,\nso the controller has to be told not to measure, and that decision is here\nwhatever the stylesheet says. Writing the width in both places would be one\nnumber in two languages, drifting the first time either moved. This records\n`:state(narrow)` on the host and the stylesheet arranges itself off that.\n\n**A custom state and never `data-narrow`, which is what it was.** The width\nis read in `connectedCallback`, so on a phone this is true on the very first\nupdate: an attribute written there is markup a consumer's server never sent,\nwhich React reports as a mismatch and answers by rebuilding the subtree. The\nnarrow exception the server specs describe covers a mirror that can only\nbecome true long after hydration, and a viewport measured before the first\npaint is the opposite case. See `MixinControllerOpen` on `open`.",
-              "attribute": "full-below"
+              "attribute": "band-below"
             },
             {
               "kind": "field",
@@ -54104,9 +54096,9 @@
               "kind": "field",
               "name": "variant",
               "type": {
-                "text": "'full' | undefined"
+                "text": "'band' | undefined"
               },
-              "description": "Whether the panel is a card under the trigger or a band across the page.\n\nThe resting one is the card, hanging off the trigger and as wide as it\nneeds to be. `full` is the other shape navigations use: a band from edge to\nedge under the header, with its contents held to the page's own measure, so\na set of destinations too wide to sit under one word gets the whole width\nto lay out in.\n\nIt changes where the panel goes as well as how it looks, which is why this\ntier knows about it at all: a band spans the viewport, so there is nothing\nto measure it against and nothing to flip or shift to, and the placing pass\nis told not to run. Everything else the popover gives, the top layer and\nthe dismissal, is exactly what such a band needs.",
+              "description": "Whether the panel is a card under the trigger or a band across the page.\n\nThe resting one is the card, hanging off the trigger and as wide as it\nneeds to be. `band` is the other shape navigations use: a run from edge to\nedge under the header, with its contents held to the page's own measure, so\na set of destinations too wide to sit under one word gets the whole width\nto lay out in.\n\n**A band and not a width, which is why the word is not `full`.** It changes\nwhere the panel goes as well as how wide it is, which is why this tier\nknows about it at all: a band spans the viewport, so there is nothing to\nmeasure it against and nothing to flip or shift to, and the placing pass is\ntold not to run. Everything else the popover gives, the top layer and the\ndismissal, is exactly what such a band needs. `full` is the registry's word\nfor a width, and `Button` and `Dialog` are the two families answering that\nquestion; borrowing it here would put a third meaning on it.\n\n`variant` and not an axis, for the reason the registry gives: a card under\na word and a band under a header are two arrangements this family has, and\nno other family is being asked the same question.",
               "attribute": "variant",
               "reflects": true
             },
@@ -54805,13 +54797,13 @@
           ],
           "attributes": [
             {
-              "name": "full-below",
+              "name": "band-below",
               "type": {
                 "text": "number"
               },
               "default": "640",
               "description": "The width, in pixels, under which a card becomes a band. Zero never does.\n\nA card is a panel hung off one word, and there is no room to hang anything\noff a word on a phone: the columns do not shrink past\n`--megamenu-column-size`, so four of them stay four of them and the panel\nruns off the side of the screen rather than reflowing. Below this it takes\nthe whole width and its columns stack, which is the only arrangement that\nfits.\n\n**In script rather than a media query, and only once.** Whether the panel is\na band is not a question of paint: a band is not placed against the trigger,\nso the controller has to be told not to measure, and that decision is here\nwhatever the stylesheet says. Writing the width in both places would be one\nnumber in two languages, drifting the first time either moved. This records\n`:state(narrow)` on the host and the stylesheet arranges itself off that.\n\n**A custom state and never `data-narrow`, which is what it was.** The width\nis read in `connectedCallback`, so on a phone this is true on the very first\nupdate: an attribute written there is markup a consumer's server never sent,\nwhich React reports as a mismatch and answers by rebuilding the subtree. The\nnarrow exception the server specs describe covers a mirror that can only\nbecome true long after hydration, and a viewport measured before the first\npaint is the opposite case. See `MixinControllerOpen` on `open`.",
-              "fieldName": "fullBelow"
+              "fieldName": "bandBelow"
             },
             {
               "name": "label",
@@ -54834,9 +54826,9 @@
             {
               "name": "variant",
               "type": {
-                "text": "'full' | undefined"
+                "text": "'band' | undefined"
               },
-              "description": "Whether the panel is a card under the trigger or a band across the page.\n\nThe resting one is the card, hanging off the trigger and as wide as it\nneeds to be. `full` is the other shape navigations use: a band from edge to\nedge under the header, with its contents held to the page's own measure, so\na set of destinations too wide to sit under one word gets the whole width\nto lay out in.\n\nIt changes where the panel goes as well as how it looks, which is why this\ntier knows about it at all: a band spans the viewport, so there is nothing\nto measure it against and nothing to flip or shift to, and the placing pass\nis told not to run. Everything else the popover gives, the top layer and\nthe dismissal, is exactly what such a band needs.",
+              "description": "Whether the panel is a card under the trigger or a band across the page.\n\nThe resting one is the card, hanging off the trigger and as wide as it\nneeds to be. `band` is the other shape navigations use: a run from edge to\nedge under the header, with its contents held to the page's own measure, so\na set of destinations too wide to sit under one word gets the whole width\nto lay out in.\n\n**A band and not a width, which is why the word is not `full`.** It changes\nwhere the panel goes as well as how wide it is, which is why this tier\nknows about it at all: a band spans the viewport, so there is nothing to\nmeasure it against and nothing to flip or shift to, and the placing pass is\ntold not to run. Everything else the popover gives, the top layer and the\ndismissal, is exactly what such a band needs. `full` is the registry's word\nfor a width, and `Button` and `Dialog` are the two families answering that\nquestion; borrowing it here would put a third meaning on it.\n\n`variant` and not an axis, for the reason the registry gives: a card under\na word and a band under a header are two arrangements this family has, and\nno other family is being asked the same question.",
               "fieldName": "variant"
             },
             {
@@ -54867,7 +54859,7 @@
           ],
           "cssStates": [
             {
-              "description": "While the page is under `full-below`, so the panel is a band whether or not one was asked for.",
+              "description": "While the page is under `band-below`, so the panel is a band whether or not one was asked for.",
               "name": "narrow"
             },
             {
@@ -71873,7 +71865,7 @@
           "name": "HelixHeadlessRadio",
           "cssParts": [
             {
-              "description": "The circle.",
+              "description": "The circle. The dot inside it is drawn on the box itself, which is `::part(box)::after` from a consumer's sheet: this tier ships no CSS, so a box it renders for one to paint is an empty child costing whatever the consumer's own layout charges for a child. `ListItem` measured that.",
               "name": "box"
             },
             {
@@ -71883,10 +71875,6 @@
             {
               "description": "The words beside it.",
               "name": "label"
-            },
-            {
-              "description": "The dot inside it.",
-              "name": "mark"
             }
           ],
           "slots": [
@@ -83878,7 +83866,7 @@
       "declarations": [
         {
           "kind": "class",
-          "description": "**The name is a button, and only the name.** The marker is `aria-hidden`\ndecoration, so wrapping it would add hit area and no meaning. It is `Button`\nrather than a `<button>` this element resets: the hover wash, the focus ring\nand the disabled treatment are decisions the button carries.\n\n**It says nothing about where a reader may go.** Every step is pressable and\nannounces itself with `helix-select`; refusing the ones ahead is `disabled`,\nwhich the consumer sets, because only they know whether a form can be\nskipped.\n\n**The marker is a slot whose fallback is the state.** A finished stage shows\na check, the current one a target, one not yet reached an empty ring. Exactly\none is rendered, chosen from the step's own two booleans, rather than three\nwith two hidden in CSS: the accessibility tree would otherwise carry marks\nthat are not there.",
+          "description": "**The name is a button, and only the name.** The marker is `aria-hidden`\ndecoration, so wrapping it would add hit area and no meaning. It is `Button`\nrather than a `<button>` this element resets: the hover wash, the focus ring\nand the disabled treatment are decisions the button carries.\n\n**It says nothing about where a reader may go.** Every step is pressable and\nannounces itself with `helix-select`; refusing the ones ahead is `disabled`,\nwhich the consumer sets, because only they know whether a form can be\nskipped.\n\n**The marker is a slot whose fallback is the state.** A finished stage shows\na check, the current one a target, one not yet reached an empty ring. Exactly\none is rendered, chosen from the step's own two booleans, rather than three\nwith two hidden in CSS: the accessibility tree would otherwise carry marks\nthat are not there.\n\n**The two half lines either side of the mark are a sheet's, on `::before` and\n`::after` of the step.** Both are placed entirely from properties the list\nhands down, so there was nothing about them for a box to carry, and this tier\nships no CSS: a box it rendered for one to paint would be an empty child\ncosting whatever the consumer's own layout charges for a child. `ListItem`\nmeasured that.",
           "name": "HelixHeadlessStep",
           "cssParts": [
             {
@@ -83901,10 +83889,6 @@
               "description": "The inner control.",
               "name": "label-button"
             },
-            {
-              "description": "The half line arriving from the step before.",
-              "name": "lead"
-            },
             {
               "description": "The glyph inside the marker: a tick, a dot, or an empty ring.",
               "name": "mark"
@@ -83912,10 +83896,6 @@
             {
               "description": "The shape carrying the number or the check.",
               "name": "marker"
-            },
-            {
-              "description": "The half line running on to the next.",
-              "name": "trail"
             }
           ],
           "slots": [
@@ -84484,11 +84464,7 @@
               "name": "label"
             },
             {
-              "description": "The part that moves.",
-              "name": "thumb"
-            },
-            {
-              "description": "The groove the thumb travels in.",
+              "description": "The groove. The thumb that travels in it is drawn on the groove itself, which is `::part(track)::after` from a consumer's sheet: this tier ships no CSS, so a box it renders for one to paint is an empty child costing whatever the consumer's own layout charges for a child. `ListItem` measured that.",
               "name": "track"
             }
           ],
@@ -86087,11 +86063,11 @@
               }
             }
           ],
-          "description": "The edge a column names, where it names one of the three.\n\n**`align` is a string anybody can write**, the union on the property being a\ncompile-time claim and nothing else, and both tables put the value straight\ninto CSS: `Table` into a rule in each row's shadow root, `DataTable` into the\ncell it draws. One guard, here with the property, rather than one in each\ntable and only one of them written."
+          "description": "The edge a column names, where it names one of the three.\n\n**`text-align` is a string anybody can write**, the union on the property being a\ncompile-time claim and nothing else, and both tables put the value straight\ninto CSS: `Table` into a rule in each row's shadow root, `DataTable` into the\ncell it draws. One guard, here with the property, rather than one in each\ntable and only one of them written."
         },
         {
           "kind": "class",
-          "description": "**The column is the source of both its heading and its track.** Add one and\nthe table has another track; remove one and it does not. That is what ties\nthe two together, and a table-level track list on its own does not: a list\nthat is accidentally the headings is invalid CSS a grid ignores in silence,\ndrawing the whole table as one column. `Table`'s `columns` is dealt out a\ntrack at a time against the columns declared under it, so a heading among the\nwidths costs its own column a width and no more, and a list longer or shorter\nthan the columns is trimmed or shared rather than being a second count of\nthem. A column's own `width` wins over the track in its place.\n\n**It is also where every per-column fact goes**, which is the reason\n`DataTable` needs no column config object. `field` names the key the cell\nreads, `sortable` says a reader may reorder by it, `align` says which edge\nthe values line up against, and `cell` takes a function for anything the\nfield alone cannot express. The schema is markup and the data is a property:\na schema is small, declarative, and something a reader should be able to see\nin the HTML, and data is large and windowed.\n\n**The same element serves both tables**, the markup one and the data one. It\nis identified by a flag rather than by `instanceof`, so a `TableColumn` works\ninside either without the two roots sharing anything else.\n\n**It generates no box of its own**, the same as a row: the heading is a grid\nitem of the table, so it lines up with the cells under it rather than sitting\nin a wrapper that has to be kept the same width.\n\n**`hidden` takes the column out of the grid**, its heading and its track\nboth, so the columns after it keep their own widths and every row keeps its\ncells under their headings. `hidden=\"until-found\"` keeps its track, the\nheading being left drawn, as every Helix element leaves one with that value.\n`DataTable` draws the cells, so it leaves out the ones under a hidden column.\nA `Table`'s cells are markup the consumer wrote, so hide them with the\ncolumn, as removing a column means removing its cells: a row with a cell more\nthan the table has tracks wraps into the next.\n\n**A heading that does something holds a control that does it.** The host is\nthe column header, and a header is not focusable, so a sortable heading is a\n`<button>` inside it: the pattern for a sortable table, and the only way a\nreader on a keyboard reaches the sort at all. A column a reader may resize\ncarries a `separator` on its end edge, moved by dragging it or with the arrow\nkeys, and a column in a table that lets a reader reorder its columns carries\na grip the table moves.",
+          "description": "**The column is the source of both its heading and its track.** Add one and\nthe table has another track; remove one and it does not. That is what ties\nthe two together, and a table-level track list on its own does not: a list\nthat is accidentally the headings is invalid CSS a grid ignores in silence,\ndrawing the whole table as one column. `Table`'s `columns` is dealt out a\ntrack at a time against the columns declared under it, so a heading among the\nwidths costs its own column a width and no more, and a list longer or shorter\nthan the columns is trimmed or shared rather than being a second count of\nthem. A column's own `width` wins over the track in its place.\n\n**It is also where every per-column fact goes**, which is the reason\n`DataTable` needs no column config object. `field` names the key the cell\nreads, `sortable` says a reader may reorder by it, `text-align` says which edge\nthe values line up against, and `cell` takes a function for anything the\nfield alone cannot express. The schema is markup and the data is a property:\na schema is small, declarative, and something a reader should be able to see\nin the HTML, and data is large and windowed.\n\n**The same element serves both tables**, the markup one and the data one. It\nis identified by a flag rather than by `instanceof`, so a `TableColumn` works\ninside either without the two roots sharing anything else.\n\n**It generates no box of its own**, the same as a row: the heading is a grid\nitem of the table, so it lines up with the cells under it rather than sitting\nin a wrapper that has to be kept the same width.\n\n**`hidden` takes the column out of the grid**, its heading and its track\nboth, so the columns after it keep their own widths and every row keeps its\ncells under their headings. `hidden=\"until-found\"` keeps its track, the\nheading being left drawn, as every Helix element leaves one with that value.\n`DataTable` draws the cells, so it leaves out the ones under a hidden column.\nA `Table`'s cells are markup the consumer wrote, so hide them with the\ncolumn, as removing a column means removing its cells: a row with a cell more\nthan the table has tracks wraps into the next.\n\n**A heading that does something holds a control that does it.** The host is\nthe column header, and a header is not focusable, so a sortable heading is a\n`<button>` inside it: the pattern for a sortable table, and the only way a\nreader on a keyboard reaches the sort at all. A column a reader may resize\ncarries a `separator` on its end edge, moved by dragging it or with the arrow\nkeys, and a column in a table that lets a reader reorder its columns carries\na grip the table moves.",
           "name": "HelixHeadlessTableColumn",
           "cssParts": [
             {
@@ -86122,16 +86098,6 @@
             }
           ],
           "members": [
-            {
-              "kind": "field",
-              "name": "align",
-              "type": {
-                "text": "'center' | 'end' | 'start' | undefined"
-              },
-              "description": "Which edge the values line up against.\n\n`end` is what a column of numbers wants, so digits of the same magnitude\nsit above each other. Left unset the cell inherits the table's own\nalignment, which is `start` for text in either writing direction.\n`DataTable` aligns the cells it draws. A `Table`'s cells are markup the\nconsumer wrote, so the table writes nothing onto them: it publishes the\nedge to each cell under this column as `--table-cell-align`, which\n`@fusion.dev/helix` reads. The heading is this element's own, and\n`@fusion.dev/helix` sets it to the same edge in either table. `end` is the\ninline end, so in a right-to-left table it is the left.\n\n**Reflected, because the heading is drawn by a stylesheet and has no other\nway to learn it.** Set as a property, which is how React sets it, an\nunreflected `align` left no attribute to select on, so the heading stayed at\nthe start over a column of digits set to the end. It is the author's\ndeclaration and nothing moves it afterwards, so an attribute cannot come to\ndisagree with the element, which is the reason `open` records a custom\nstate instead. No default, so an unset column writes nothing onto its host.",
-              "attribute": "align",
-              "reflects": true
-            },
             {
               "kind": "field",
               "name": "cell",
@@ -86181,6 +86147,16 @@
               "attribute": "sortable",
               "reflects": true
             },
+            {
+              "kind": "field",
+              "name": "textAlign",
+              "type": {
+                "text": "'center' | 'end' | 'start' | undefined"
+              },
+              "description": "Which edge the values line up against.\n\n**Text alignment, and the name says so.** `Flex` and `Grid` ask the CSS\nbox-alignment question, where a thing sits in a container, and they are\nnamed for the properties they mirror; this is `text-align` down a column of\nvalues, and `Dialog` answers the same question under the same name. One\nword for both questions is how a consumer who learned it on a layout writes\nit here and gets no error, a value a component does not have leaving the\ndefault in place and looking deliberate.\n\n`end` is what a column of numbers wants, so digits of the same magnitude\nsit above each other. Left unset the cell inherits the table's own\nalignment, which is `start` for text in either writing direction.\n`DataTable` aligns the cells it draws. A `Table`'s cells are markup the\nconsumer wrote, so the table writes nothing onto them: it publishes the\nedge to each cell under this column as `--table-cell-align`, which\n`@fusion.dev/helix` reads. The heading is this element's own, and\n`@fusion.dev/helix` sets it to the same edge in either table. `end` is the\ninline end, so in a right-to-left table it is the left.\n\n**Reflected, because the heading is drawn by a stylesheet and has no other\nway to learn it.** Set as a property, which is how React sets it, an\nunreflected edge left no attribute to select on, so the heading stayed at\nthe start over a column of digits set to the end. It is the author's\ndeclaration and nothing moves it afterwards, so an attribute cannot come to\ndisagree with the element, which is the reason `open` records a custom\nstate instead. No default, so an unset column writes nothing onto its host.",
+              "attribute": "text-align",
+              "reflects": true
+            },
             {
               "kind": "field",
               "name": "width",
@@ -86731,14 +86707,6 @@
             }
           ],
           "attributes": [
-            {
-              "name": "align",
-              "type": {
-                "text": "'center' | 'end' | 'start' | undefined"
-              },
-              "description": "Which edge the values line up against.\n\n`end` is what a column of numbers wants, so digits of the same magnitude\nsit above each other. Left unset the cell inherits the table's own\nalignment, which is `start` for text in either writing direction.\n`DataTable` aligns the cells it draws. A `Table`'s cells are markup the\nconsumer wrote, so the table writes nothing onto them: it publishes the\nedge to each cell under this column as `--table-cell-align`, which\n`@fusion.dev/helix` reads. The heading is this element's own, and\n`@fusion.dev/helix` sets it to the same edge in either table. `end` is the\ninline end, so in a right-to-left table it is the left.\n\n**Reflected, because the heading is drawn by a stylesheet and has no other\nway to learn it.** Set as a property, which is how React sets it, an\nunreflected `align` left no attribute to select on, so the heading stayed at\nthe start over a column of digits set to the end. It is the author's\ndeclaration and nothing moves it afterwards, so an attribute cannot come to\ndisagree with the element, which is the reason `open` records a custom\nstate instead. No default, so an unset column writes nothing onto its host.",
-              "fieldName": "align"
-            },
             {
               "name": "field",
               "type": {
@@ -86766,6 +86734,14 @@
               "description": "Whether a reader may reorder the set by this column.\n\nIgnored without a `field`, and silently: a column with nothing to sort by\nhas no order to offer, and refusing loudly would mean an actions column\ncarrying `sortable` breaks a table rather than doing nothing.\n\n**Reflected, because a stylesheet selects on it.** `@fusion.dev/helix`\ngives a data table's sortable headings a pointer through\n`::slotted(helix-table-column[sortable])`, and set as a property, which is\nhow React sets it, an unreflected `sortable` left no attribute to match.\n`false` reflects as no attribute at all, so an unset column writes nothing\nonto its host.",
               "fieldName": "sortable"
             },
+            {
+              "name": "text-align",
+              "type": {
+                "text": "'center' | 'end' | 'start' | undefined"
+              },
+              "description": "Which edge the values line up against.\n\n**Text alignment, and the name says so.** `Flex` and `Grid` ask the CSS\nbox-alignment question, where a thing sits in a container, and they are\nnamed for the properties they mirror; this is `text-align` down a column of\nvalues, and `Dialog` answers the same question under the same name. One\nword for both questions is how a consumer who learned it on a layout writes\nit here and gets no error, a value a component does not have leaving the\ndefault in place and looking deliberate.\n\n`end` is what a column of numbers wants, so digits of the same magnitude\nsit above each other. Left unset the cell inherits the table's own\nalignment, which is `start` for text in either writing direction.\n`DataTable` aligns the cells it draws. A `Table`'s cells are markup the\nconsumer wrote, so the table writes nothing onto them: it publishes the\nedge to each cell under this column as `--table-cell-align`, which\n`@fusion.dev/helix` reads. The heading is this element's own, and\n`@fusion.dev/helix` sets it to the same edge in either table. `end` is the\ninline end, so in a right-to-left table it is the left.\n\n**Reflected, because the heading is drawn by a stylesheet and has no other\nway to learn it.** Set as a property, which is how React sets it, an\nunreflected edge left no attribute to select on, so the heading stayed at\nthe start over a column of digits set to the end. It is the author's\ndeclaration and nothing moves it afterwards, so an attribute cannot come to\ndisagree with the element, which is the reason `open` records a custom\nstate instead. No default, so an unset column writes nothing onto its host.",
+              "fieldName": "textAlign"
+            },
             {
               "name": "width",
               "type": {
@@ -87027,7 +87003,7 @@
               },
               "privacy": "private",
               "default": "undefined",
-              "description": "The rules handing each column's `align` to the cells under it. One sheet for\nevery row this table holds, rewritten in place, so a column changing its\nedge reaches every row in one write."
+              "description": "The rules handing each column's `text-align` to the cells under it. One sheet for\nevery row this table holds, rewritten in place, so a column changing its\nedge reaches every row in one write."
             },
             {
               "kind": "field",
@@ -95705,10 +95681,6 @@
           "description": "**The time is a `<time>`, and only when there is a time to put in it.** Given\n`datetime`, the label a consumer wrote is wrapped in the element the platform\nhas for exactly this, so the machine-readable instant travels with the human\none: a crawler, a reader's own tooling and a copy-paste all get \"2026-08-19\",\nwhere \"yesterday\" on its own is a word. Given no `datetime`, it stays a span,\nbecause a `<time>` with nothing to be precise about is markup pretending.\n\n**The connector is this element's, not the list's.** Each entry draws the line\nthat arrives at it and hides it when it is first, which `:host(:first-child)`\nsettles with no index, no counting parent and no script. `Steps` and\n`Breadcrumbs` both do it this way and for the same reason.\n\n`tone` says what kind of event it was, and it is the only thing that colors\nthe mark. It takes `Announcement`'s vocabulary rather than a second one.",
           "name": "HelixHeadlessTimelineItem",
           "cssParts": [
-            {
-              "description": "The line arriving at this entry.",
-              "name": "connector"
-            },
             {
               "description": "What happened, and the time above it.",
               "name": "content"
@@ -95722,7 +95694,7 @@
               "name": "marker"
             },
             {
-              "description": "The column holding the mark and the line.",
+              "description": "The column holding the mark and the line. Both halves of the line are drawn on the rail, which is `::part(rail)::before` and `::after` from a consumer's sheet: this tier ships no CSS, so a box it renders for one to paint is an empty child costing whatever the consumer's own layout charges for a child. `ListItem` measured that.",
               "name": "rail"
             },
             {
@@ -97796,10 +97768,6 @@
           "description": "The indicator is one element that travels, not a background that appears on\nwhichever item is current. A fill that swaps is two things changing at once\nand reads as a flicker; one that moves is a single object the eye follows,\nand it says where the selection came from as well as where it went.\n\nIts box is measured from the selected item and written onto the indicator as\ncustom properties, labels being different lengths. Measurement is client-side\nby necessity, so the server renders the indicator hidden and it fades in once\nit has somewhere to be, which is the harmless direction.",
           "name": "HelixHeadlessToggleGroup",
           "cssParts": [
-            {
-              "description": "The rule after an inline label, separating it from the items.",
-              "name": "divider"
-            },
             {
               "description": "What is wrong with it.",
               "name": "feedback"
@@ -97821,7 +97789,7 @@
               "name": "row"
             },
             {
-              "description": "The bar the items sit in.",
+              "description": "The bar the items sit in. The rule after an inline label, separating it from the items, is drawn on the bar, which is `::part(track)::before` from a consumer's sheet: this tier ships no CSS, so a box it renders for one to paint is an empty child costing whatever the consumer's own layout charges for a child. `ListItem` measured that.",
               "name": "track"
             }
           ],
@@ -107374,13 +107342,9 @@
               "name": "fullscreen"
             },
             {
-              "description": "What is said while the picture waits for more of itself.",
+              "description": "What is said while the picture waits for more of itself. The part of that which spins is drawn on it, which is `::part(loading)::before` from a consumer's sheet: this tier ships no CSS, so a box it renders for one to paint is an empty child costing whatever the consumer's own layout charges for a child. `ListItem` measured that.",
               "name": "loading"
             },
-            {
-              "description": "The part of that which spins.",
-              "name": "loading-mark"
-            },
             {
               "description": "The button that opens it.",
               "name": "more"

package/dist/bar-chart/root/bar-chart-root.d.ts

@@ -72,22 +72,13 @@ declare const HelixHeadlessBarChart_base: typeof HelixElement & (new (...args: a
  *   `wash="gradient"` asks for it.
  */
 export declare class HelixHeadlessBarChart extends HelixHeadlessBarChart_base {
-    /**
-     * Whether the categories run down the side rather than along the bottom.
-     *
-     * Absent is columns. `horizontal` is the one to reach for when the category
-     * names are words rather than dates: a row of long names either overlaps or
-     * turns on its side, and neither is as readable as putting them down the left
-     * where they read normally.
-     */
-    direction?: 'horizontal';
     /**
      * Which rules are drawn across the plot, if any.
      *
      * Absent draws none. `value` rules the axis the columns are *measured* on,
      * `category` rules the axis they are *arranged* on with one through each
      * group, and `both` draws both. Which of those is horizontal turns with
-     * `direction`, because a rule belongs to an axis and not to a screen edge.
+     * `orientation`, because a rule belongs to an axis and not to a screen edge.
      *
      * **A bare `gridlines` means `value`**, and so does anything unrecognized: an
      * unrecognized value that draws nothing is indistinguishable from the
@@ -126,6 +117,18 @@ export declare class HelixHeadlessBarChart extends HelixHeadlessBarChart_base {
      * own rule rather than this one's.
      */
     lines?: string;
+    /**
+     * Whether the categories run down the side rather than along the bottom.
+     *
+     * Absent is columns. `horizontal` is the one to reach for when the category
+     * names are words rather than dates: a row of long names either overlaps or
+     * turns on its side, and neither is as readable as putting them down the left
+     * where they read normally.
+     *
+     * `orientation` and not `orientation`, which `Trend` uses in the same group for
+     * which way a number moved.
+     */
+    orientation?: 'horizontal';
     /**
      * Which series are measured against a scale of their own, by name.
      *
@@ -172,7 +175,7 @@ export declare class HelixHeadlessBarChart extends HelixHeadlessBarChart_base {
     /**
      * Tells the pointer which way the categories run.
      *
-     * In `willUpdate` because `direction` is a property a consumer can change at
+     * In `willUpdate` because `orientation` is a property a consumer can change at
      * any time, and the controller resolves a reading from whichever axis it was
      * last told about: set once at connect, a chart turned sideways after that
      * goes on reading x and answers with the same row wherever the pointer goes.
@@ -220,7 +223,7 @@ export declare class HelixHeadlessBarChart extends HelixHeadlessBarChart_base {
     /**
      * The grid, behind everything, or nothing at all.
      *
-     * Across the measured axis, which turns with `direction`: a rule belongs to
+     * Across the measured axis, which turns with `orientation`: a rule belongs to
      * the axis the bars are measured on and not the one they are arranged on, so
      * columns get horizontal rules and rows get vertical ones. Getting that
      * backwards draws a grid that divides the categories, which are already

package/dist/bar-chart/root/bar-chart-root.js

@@ -23,7 +23,7 @@ let HelixHeadlessBarChart = class HelixHeadlessBarChart extends MixinChartSource
     }
     willUpdate(changed) {
         super.willUpdate(changed);
-        this.pointer.axis = this.direction === 'horizontal' ? 'block' : 'inline';
+        this.pointer.axis = this.orientation === 'horizontal' ? 'block' : 'inline';
     }
     render() {
         const series = this.series;
@@ -40,10 +40,10 @@ let HelixHeadlessBarChart = class HelixHeadlessBarChart extends MixinChartSource
         };
         const [low, high] = extent(scaled.size === 0 ? on(() => true) : on((one) => !own(one)));
         const domain = [Math.min(0, low), Math.max(0, high)];
-        const range = this.direction === 'horizontal' ? [0, PLOT_HEIGHT] : [PLOT_HEIGHT, 0];
+        const range = this.orientation === 'horizontal' ? [0, PLOT_HEIGHT] : [PLOT_HEIGHT, 0];
         const y = linear(domain, range);
         const floor = y(0);
-        const sideways = this.direction === 'horizontal';
+        const sideways = this.orientation === 'horizontal';
         const [second, top] = extent(scaled.size > 0 ? on(own) : [0]);
         const other = [Math.min(0, second), Math.max(0, top)];
         const z = scaled.size > 0 ? linear(other, range) : undefined;
@@ -57,7 +57,7 @@ let HelixHeadlessBarChart = class HelixHeadlessBarChart extends MixinChartSource
         return html `${z === undefined ? nothing : this.renderAxis(y, domain, 'primary', sideways, widest)}${this.renderPlot(series, categories, y, domain, floor, z)}${z === undefined ? nothing : this.renderAxis(z, other, 'secondary', sideways, widest, tint)}${this.renderLabels(categories)}`;
     }
     renderPlot(series, categories, y, domain, floor, z) {
-        const sideways = this.direction === 'horizontal';
+        const sideways = this.orientation === 'horizontal';
         const slot = 100 / categories.length;
         const lined = this.lined;
         const scaled = this.scaled;
@@ -206,7 +206,7 @@ let HelixHeadlessBarChart = class HelixHeadlessBarChart extends MixinChartSource
         const all = series.flatMap((one) => one.points.map((point) => point.value));
         const [low, high] = extent(all.length > 0 ? all : [0]);
         const domain = [Math.min(0, low), Math.max(0, high)];
-        const sideways = this.direction === 'horizontal';
+        const sideways = this.orientation === 'horizontal';
         const scale = sideways ? linear(domain, [0, PLOT_HEIGHT]) : linear(domain, [PLOT_HEIGHT, 0]);
         const ends = values.map((one) => scale(one));
         const far = sideways ? Math.max(...ends) : Math.min(...ends);
@@ -219,15 +219,15 @@ let HelixHeadlessBarChart = class HelixHeadlessBarChart extends MixinChartSource
         }, (cell) => this.seriesOf(cell));
     }
 };
-__decorate([
-    property({ reflect: true })
-], HelixHeadlessBarChart.prototype, "direction", void 0);
 __decorate([
     property()
 ], HelixHeadlessBarChart.prototype, "gridlines", void 0);
 __decorate([
     property()
 ], HelixHeadlessBarChart.prototype, "lines", void 0);
+__decorate([
+    property({ reflect: true })
+], HelixHeadlessBarChart.prototype, "orientation", void 0);
 __decorate([
     property({ reflect: true })
 ], HelixHeadlessBarChart.prototype, "secondary", void 0);

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

@@ -57,9 +57,12 @@ declare const HelixHeadlessColorPicker_base: (new (...args: any[]) => import("@f
  * @csspart footer - The row holding the value and the tools.
  * @csspart format - The control that changes the syntax the value is written in.
  * @csspart format-button - The inner control.
- * @csspart grid - The saturation and brightness square.
+ * @csspart grid - The saturation and brightness square. The mark showing where
+ * in the square the color sits is drawn on the square itself, which is
+ * `::part(grid)::after` from a consumer's sheet: the two channels are already
+ * on the square as `--color-picker-saturation` and `--color-picker-brightness`,
+ * so a box would have carried nothing, and this tier ships no CSS.
  * @csspart grid-brightness - The range input for its vertical axis.
- * @csspart grid-handle - The mark showing where in the square the color sits.
  * @csspart grid-saturation - The range input for the square's horizontal axis.
  * @csspart sample - The chip of the current color, which copies it when pressed.
  * @csspart swatch - One preset.

package/dist/color-picker/root/color-picker-root.js

@@ -234,7 +234,6 @@ let HelixHeadlessColorPicker = class HelixHeadlessColorPicker extends MixinContr
         @pointerdown=${this.handleGridPointer}
         @pointermove=${this.handleGridPointer}
       >
-        <span part="grid-handle" aria-hidden="true"></span>
         <input
           part="grid-saturation"
           type="range"

package/dist/data-table/root/data-table-root.d.ts

@@ -17,7 +17,7 @@ declare const HelixHeadlessDataTable_base: (new (...args: any[]) => import("@fus
  * ```html
  * <helix-headless-data-table .rows=${rows} sort="name:asc" page-size="20">
  *   <helix-headless-table-column field="name" sortable>Name</helix-headless-table-column>
- *   <helix-headless-table-column field="size" align="end" sortable .cell=${bytes}>Size</helix-headless-table-column>
+ *   <helix-headless-table-column field="size" text-align="end" sortable .cell=${bytes}>Size</helix-headless-table-column>
  * </helix-headless-data-table>
  * ```
  *
@@ -622,7 +622,7 @@ export declare class HelixHeadlessDataTable extends HelixHeadlessDataTable_base
      * overrule it either, an inline declaration beating any `::part(cell)` rule
      * they wrote.
      *
-     * Only the three edges reach it, `align` being a string anybody can write and
+     * Only the three edges reach it, `text-align` being a string anybody can write and
      * this being a style attribute: `edgeOf` is that guard, and `Table` holds the
      * same value to the same three.
      */