@fusion.dev/helix 0.54.0 → 0.55.0

package/custom-elements.json

@@ -5990,9 +5990,9 @@
               "kind": "field",
               "name": "shape",
               "type": {
-                "text": "'circle' | 'square' | undefined"
+                "text": "'circle' | 'rounded' | undefined"
               },
-              "description": "Whether the avatar is a circle or a rounded square.",
+              "description": "Whether the avatar is a circle or a rounded square.\n\n`rounded` and not `square`, which is the sharp-cornered pole of the same\naxis and what `QrCode` draws with it. This corner is `radii-md`, so the word\nfor it is the one the registry already has.",
               "attribute": "shape",
               "reflects": true
             },
@@ -6425,9 +6425,9 @@
             {
               "name": "shape",
               "type": {
-                "text": "'circle' | 'square' | undefined"
+                "text": "'circle' | 'rounded' | undefined"
               },
-              "description": "Whether the avatar is a circle or a rounded square.",
+              "description": "Whether the avatar is a circle or a rounded square.\n\n`rounded` and not `square`, which is the sharp-cornered pole of the same\naxis and what `QrCode` draws with it. This corner is `radii-md`, so the word\nfor it is the one the registry already has.",
               "fieldName": "shape"
             },
             {
@@ -7517,13 +7517,12 @@
             },
             {
               "kind": "field",
-              "name": "direction",
+              "name": "gridlines",
               "type": {
-                "text": "'horizontal' | undefined"
+                "text": "'both' | 'category' | 'value' | 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,
+              "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",
               "inheritedFrom": {
                 "name": "HelixHeadlessBarChart",
                 "module": "src/bar-chart/root/bar-chart-root.ts"
@@ -7531,12 +7530,12 @@
             },
             {
               "kind": "field",
-              "name": "gridlines",
+              "name": "lines",
               "type": {
-                "text": "'both' | 'category' | 'value' | undefined"
+                "text": "string | 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.",
-              "attribute": "gridlines",
+              "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",
               "inheritedFrom": {
                 "name": "HelixHeadlessBarChart",
                 "module": "src/bar-chart/root/bar-chart-root.ts"
@@ -7544,12 +7543,13 @@
             },
             {
               "kind": "field",
-              "name": "lines",
+              "name": "orientation",
               "type": {
-                "text": "string | undefined"
+                "text": "'horizontal' | undefined"
               },
-              "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",
+              "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,
               "inheritedFrom": {
                 "name": "HelixHeadlessBarChart",
                 "module": "src/bar-chart/root/bar-chart-root.ts"
@@ -7768,7 +7768,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.",
               "inheritedFrom": {
                 "name": "HelixHeadlessBarChart",
                 "module": "src/bar-chart/root/bar-chart-root.ts"
@@ -8274,36 +8274,36 @@
               }
             },
             {
-              "name": "direction",
+              "name": "gridlines",
               "type": {
-                "text": "'horizontal' | undefined"
+                "text": "'both' | 'category' | 'value' | 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",
+              "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",
               "inheritedFrom": {
                 "name": "HelixHeadlessBarChart",
                 "module": "src/bar-chart/root/bar-chart-root.ts"
               }
             },
             {
-              "name": "gridlines",
+              "name": "lines",
               "type": {
-                "text": "'both' | 'category' | 'value' | undefined"
+                "text": "string | 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.",
-              "fieldName": "gridlines",
+              "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",
               "inheritedFrom": {
                 "name": "HelixHeadlessBarChart",
                 "module": "src/bar-chart/root/bar-chart-root.ts"
               }
             },
             {
-              "name": "lines",
+              "name": "orientation",
               "type": {
-                "text": "string | undefined"
+                "text": "'horizontal' | undefined"
               },
-              "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",
+              "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",
               "inheritedFrom": {
                 "name": "HelixHeadlessBarChart",
                 "module": "src/bar-chart/root/bar-chart-root.ts"
@@ -13328,9 +13328,9 @@
               "kind": "field",
               "name": "controlsPlacement",
               "type": {
-                "text": "'block-end' | 'block-start' | 'inline-end' | 'inline-start' | 'overlay' | undefined"
+                "text": "'start' | 'end' | 'top' | 'bottom' | 'overlay' | undefined"
               },
-              "description": "Which side of the slides the arrows sit on.\n\nThe same four sides as `indicatorPlacement` and the same default, so a\ncarousel that moves only one of them keeps the other where it was.\n`inline-start` or `inline-end` stacks the arrows into a column, which is\nwhat a vertical track usually wants.\n\n`overlay` puts them on the slides, at the track's own edges, which is what a\nfull-bleed carousel wants: the slide is the page and the controls are on it\nrather than in a bar beneath it. It carries its own treatment with it, a\nsurface and a shadow under each arrow, because a glyph drawn straight onto a\nphotograph is legible against about half of one.\n\n**It is a value here rather than an axis of its own.** \"The controls are\nover the content\" is the whole of what a `hero` appearance would say, and\nthe surface, the edge-to-edge arrows and the bar that catches no presses all\nfollow from it. These two placements are the whole of where a carousel's\nchrome can go.",
+              "description": "Which side of the slides the arrows sit on.\n\nThe same four sides as `indicatorPlacement` and the same default, so a\ncarousel that moves only one of them keeps the other where it was. `start`\nor `end` stacks the arrows into a column, which is what a vertical track\nusually wants.\n\n`overlay` puts them on the slides, at the track's own edges, which is what a\nfull-bleed carousel wants: the slide is the page and the controls are on it\nrather than in a bar beneath it. It carries its own treatment with it, a\nsurface and a shadow under each arrow, because a glyph drawn straight onto a\nphotograph is legible against about half of one.\n\n**It is a value here rather than an axis of its own.** \"The controls are\nover the content\" is the whole of what a `hero` appearance would say, and\nthe surface, the edge-to-edge arrows and the bar that catches no presses all\nfollow from it. These two placements are the whole of where a carousel's\nchrome can go.",
               "attribute": "controls-placement",
               "reflects": true
             },
@@ -13340,7 +13340,7 @@
               "type": {
                 "text": "'center' | 'end' | 'start' | undefined"
               },
-              "description": "Where along that side the dots sit.\n\nThe second half of the answer to \"where do they go\". `indicatorPlacement`\nsays which edge and this says where along it, so the pair spells out the\nnine positions a consumer asks for in words: bottom left, bottom center,\ntop right, and so on. One attribute with nine values was the alternative\nand it multiplies rather than composing, since every value has to name both\nfacts and a consumer changing one has to rewrite the other.\n\n**One word for both axes, because the edge decides which axis it is.** On a\nblock edge the run is a row and this is `justify-self`; on an inline edge it\nis a column and the same question is `align-self`. A consumer should not\nhave to know which of those two words their edge wanted.\n\nLogical, like the placement: `start` is the left in English and the right in\nArabic on a horizontal run, and the top on a vertical one.\n\nUnset splits the row, dots to the start and arrows to the end, which is\nwhat keeps two items in one grid cell from landing on each other. Beside the\nslides, and over them, both center instead, because a column there has\nnothing to split the edge with. Putting both groups on the same edge with\nthe same alignment overlaps them, which is what the two different defaults\nexist to avoid.",
+              "description": "Where along that side the dots sit.\n\nThe second half of the answer to \"where do they go\". `indicatorPlacement`\nsays which edge and this says where along it, so the pair spells out the\nnine positions a consumer asks for in words: bottom left, bottom center,\ntop right, and so on. One attribute with nine values was the alternative\nand it multiplies rather than composing, since every value has to name both\nfacts and a consumer changing one has to rewrite the other.\n\n**One word for both axes, because the edge decides which axis it is.** On a\nblock edge the run is a row and this is `justify-self`; on an inline edge it\nis a column and the same question is `align-self`. A consumer should not\nhave to know which of those two words their edge wanted.\n\nLogical, like the placement's own `start` and `end`: `start` is the left in\nEnglish and the right in Arabic on a horizontal run, and the top on a\nvertical one.\n\nUnset splits the row, dots to the start and arrows to the end, which is\nwhat keeps two items in one grid cell from landing on each other. Beside the\nslides, and over them, both center instead, because a column there has\nnothing to split the edge with. Putting both groups on the same edge with\nthe same alignment overlaps them, which is what the two different defaults\nexist to avoid.",
               "attribute": "indicator-align",
               "reflects": true
             },
@@ -13348,9 +13348,9 @@
               "kind": "field",
               "name": "indicatorPlacement",
               "type": {
-                "text": "'block-end' | 'block-start' | 'inline-end' | 'inline-start' | undefined"
+                "text": "'start' | 'end' | 'top' | 'bottom' | undefined"
               },
-              "description": "Which side of the slides the dots sit on.\n\nUnset is `block-end`, under them. `block-start` puts them above,\n`inline-start` and `inline-end` beside, where a run of dots becomes a\ncolumn.\n\n**The sides of the content, not positions along a bar**, and logical names\nrather than `top`/`left`: an `inline-start` carousel should put its dots on\nthe right in Arabic without being told.\n\nIndependent of `controlsPlacement`. Both default to the block end, where\nthey share the row and split it, dots to the start and arrows to the end,\narrived at by two defaults rather than by a rule about the pair, so moving\none leaves the other alone.",
+              "description": "Which side of the slides the dots sit on.\n\nUnset is `bottom`, under them. `top` puts them above, `start` and `end`\nbeside, where a run of dots becomes a column.\n\n**The sides of the content, not positions along a bar.** `start` and `end`\nare the logical ones and they are logical because that axis flips: a\ncarousel with its dots at the start should put them on the right in Arabic\nwithout being told. `top` and `bottom` are the block edges, which flip in\nno writing mode this library draws for, so the plain word is the honest one\nand `block-start` would be jargon standing in for it.\n\n**`Drawer` and `Toast` say it in exactly these four words**, and one\nvocabulary across the three is worth more than each family's own: a\nconsumer who has placed a drawer knows where a carousel's dots go.\n\nIndependent of `controlsPlacement`. Both default to the bottom, where they\nshare the row and split it, dots to the start and arrows to the end,\narrived at by two defaults rather than by a rule about the pair, so moving\none leaves the other alone.",
               "attribute": "indicator-placement",
               "reflects": true
             },
@@ -14370,9 +14370,9 @@
             {
               "name": "controls-placement",
               "type": {
-                "text": "'block-end' | 'block-start' | 'inline-end' | 'inline-start' | 'overlay' | undefined"
+                "text": "'start' | 'end' | 'top' | 'bottom' | 'overlay' | undefined"
               },
-              "description": "Which side of the slides the arrows sit on.\n\nThe same four sides as `indicatorPlacement` and the same default, so a\ncarousel that moves only one of them keeps the other where it was.\n`inline-start` or `inline-end` stacks the arrows into a column, which is\nwhat a vertical track usually wants.\n\n`overlay` puts them on the slides, at the track's own edges, which is what a\nfull-bleed carousel wants: the slide is the page and the controls are on it\nrather than in a bar beneath it. It carries its own treatment with it, a\nsurface and a shadow under each arrow, because a glyph drawn straight onto a\nphotograph is legible against about half of one.\n\n**It is a value here rather than an axis of its own.** \"The controls are\nover the content\" is the whole of what a `hero` appearance would say, and\nthe surface, the edge-to-edge arrows and the bar that catches no presses all\nfollow from it. These two placements are the whole of where a carousel's\nchrome can go.",
+              "description": "Which side of the slides the arrows sit on.\n\nThe same four sides as `indicatorPlacement` and the same default, so a\ncarousel that moves only one of them keeps the other where it was. `start`\nor `end` stacks the arrows into a column, which is what a vertical track\nusually wants.\n\n`overlay` puts them on the slides, at the track's own edges, which is what a\nfull-bleed carousel wants: the slide is the page and the controls are on it\nrather than in a bar beneath it. It carries its own treatment with it, a\nsurface and a shadow under each arrow, because a glyph drawn straight onto a\nphotograph is legible against about half of one.\n\n**It is a value here rather than an axis of its own.** \"The controls are\nover the content\" is the whole of what a `hero` appearance would say, and\nthe surface, the edge-to-edge arrows and the bar that catches no presses all\nfollow from it. These two placements are the whole of where a carousel's\nchrome can go.",
               "fieldName": "controlsPlacement"
             },
             {
@@ -14380,15 +14380,15 @@
               "type": {
                 "text": "'center' | 'end' | 'start' | undefined"
               },
-              "description": "Where along that side the dots sit.\n\nThe second half of the answer to \"where do they go\". `indicatorPlacement`\nsays which edge and this says where along it, so the pair spells out the\nnine positions a consumer asks for in words: bottom left, bottom center,\ntop right, and so on. One attribute with nine values was the alternative\nand it multiplies rather than composing, since every value has to name both\nfacts and a consumer changing one has to rewrite the other.\n\n**One word for both axes, because the edge decides which axis it is.** On a\nblock edge the run is a row and this is `justify-self`; on an inline edge it\nis a column and the same question is `align-self`. A consumer should not\nhave to know which of those two words their edge wanted.\n\nLogical, like the placement: `start` is the left in English and the right in\nArabic on a horizontal run, and the top on a vertical one.\n\nUnset splits the row, dots to the start and arrows to the end, which is\nwhat keeps two items in one grid cell from landing on each other. Beside the\nslides, and over them, both center instead, because a column there has\nnothing to split the edge with. Putting both groups on the same edge with\nthe same alignment overlaps them, which is what the two different defaults\nexist to avoid.",
+              "description": "Where along that side the dots sit.\n\nThe second half of the answer to \"where do they go\". `indicatorPlacement`\nsays which edge and this says where along it, so the pair spells out the\nnine positions a consumer asks for in words: bottom left, bottom center,\ntop right, and so on. One attribute with nine values was the alternative\nand it multiplies rather than composing, since every value has to name both\nfacts and a consumer changing one has to rewrite the other.\n\n**One word for both axes, because the edge decides which axis it is.** On a\nblock edge the run is a row and this is `justify-self`; on an inline edge it\nis a column and the same question is `align-self`. A consumer should not\nhave to know which of those two words their edge wanted.\n\nLogical, like the placement's own `start` and `end`: `start` is the left in\nEnglish and the right in Arabic on a horizontal run, and the top on a\nvertical one.\n\nUnset splits the row, dots to the start and arrows to the end, which is\nwhat keeps two items in one grid cell from landing on each other. Beside the\nslides, and over them, both center instead, because a column there has\nnothing to split the edge with. Putting both groups on the same edge with\nthe same alignment overlaps them, which is what the two different defaults\nexist to avoid.",
               "fieldName": "indicatorAlign"
             },
             {
               "name": "indicator-placement",
               "type": {
-                "text": "'block-end' | 'block-start' | 'inline-end' | 'inline-start' | undefined"
+                "text": "'start' | 'end' | 'top' | 'bottom' | undefined"
               },
-              "description": "Which side of the slides the dots sit on.\n\nUnset is `block-end`, under them. `block-start` puts them above,\n`inline-start` and `inline-end` beside, where a run of dots becomes a\ncolumn.\n\n**The sides of the content, not positions along a bar**, and logical names\nrather than `top`/`left`: an `inline-start` carousel should put its dots on\nthe right in Arabic without being told.\n\nIndependent of `controlsPlacement`. Both default to the block end, where\nthey share the row and split it, dots to the start and arrows to the end,\narrived at by two defaults rather than by a rule about the pair, so moving\none leaves the other alone.",
+              "description": "Which side of the slides the dots sit on.\n\nUnset is `bottom`, under them. `top` puts them above, `start` and `end`\nbeside, where a run of dots becomes a column.\n\n**The sides of the content, not positions along a bar.** `start` and `end`\nare the logical ones and they are logical because that axis flips: a\ncarousel with its dots at the start should put them on the right in Arabic\nwithout being told. `top` and `bottom` are the block edges, which flip in\nno writing mode this library draws for, so the plain word is the honest one\nand `block-start` would be jargon standing in for it.\n\n**`Drawer` and `Toast` say it in exactly these four words**, and one\nvocabulary across the three is worth more than each family's own: a\nconsumer who has placed a drawer knows where a carousel's dots go.\n\nIndependent of `controlsPlacement`. Both default to the bottom, where they\nshare the row and split it, dots to the start and arrows to the end,\narrived at by two defaults rather than by a rule about the pair, so moving\none leaves the other alone.",
               "fieldName": "indicatorPlacement"
             },
             {
@@ -19648,12 +19648,12 @@
           "members": [
             {
               "kind": "field",
-              "name": "variant",
+              "name": "separation",
               "type": {
-                "text": "'plain' | 'card' | undefined"
+                "text": "'filled' | 'outlined' | 'plain' | undefined"
               },
-              "description": "How the choice presents itself.\n\n- `plain` is the default and is never written: a box beside its words,\n  which is what a list of choices should be almost always.\n- `card` puts it in a bounded surface, for options that need room to\n  explain themselves: a description, an icon, a price. It is the half a\n  `data-card` link cannot do, because a link reports no value and belongs\n  to no group, so a card that is genuinely an answer has to be this.\n\nThe box stays in both. A card whose only marker was its own border would\nask a reader to compare surfaces across a row to find the answer, and would\nleave nothing for a high-contrast display.",
-              "attribute": "variant",
+              "description": "Where the choice's own surface ends.\n\nThe question `separation` asks everywhere else, asked of one option, so it\nis that word: what these values pick is a surface, and `plain` is already\nthe registry's own word for the answer this family used it for. `Radio`\ntakes the same three for the same reason.\n\n- `plain` is the resting one and is never written: a box beside its words,\n  which is what a list of choices should be almost always.\n- `outlined` puts it in a bounded surface, for options that need room to\n  explain themselves: a description, an icon, a price. It is the half a\n  `data-card` link cannot do, because a link reports no value and belongs\n  to no group, so a card that is genuinely an answer has to be this.\n- `filled` is that same card on a ground of its own with no edge, which is\n  what a column of options wants where a hairline around every one of them\n  is a grid of lines rather than a set of answers.\n\n**`elevated` is the one value of the axis this family does not take.** A\nraised choice competes with a dialog: the top layer is where a thing that\ninterrupts you lives, and an option in a form is not one of those.\n\nThe box stays in all of them. A card whose only marker was its own border\nwould ask a reader to compare surfaces across a row to find the answer, and\nwould leave nothing for a high-contrast display.",
+              "attribute": "separation",
               "reflects": true
             },
             {
@@ -20624,12 +20624,12 @@
           ],
           "attributes": [
             {
-              "name": "variant",
+              "name": "separation",
               "type": {
-                "text": "'plain' | 'card' | undefined"
+                "text": "'filled' | 'outlined' | 'plain' | undefined"
               },
-              "description": "How the choice presents itself.\n\n- `plain` is the default and is never written: a box beside its words,\n  which is what a list of choices should be almost always.\n- `card` puts it in a bounded surface, for options that need room to\n  explain themselves: a description, an icon, a price. It is the half a\n  `data-card` link cannot do, because a link reports no value and belongs\n  to no group, so a card that is genuinely an answer has to be this.\n\nThe box stays in both. A card whose only marker was its own border would\nask a reader to compare surfaces across a row to find the answer, and would\nleave nothing for a high-contrast display.",
-              "fieldName": "variant"
+              "description": "Where the choice's own surface ends.\n\nThe question `separation` asks everywhere else, asked of one option, so it\nis that word: what these values pick is a surface, and `plain` is already\nthe registry's own word for the answer this family used it for. `Radio`\ntakes the same three for the same reason.\n\n- `plain` is the resting one and is never written: a box beside its words,\n  which is what a list of choices should be almost always.\n- `outlined` puts it in a bounded surface, for options that need room to\n  explain themselves: a description, an icon, a price. It is the half a\n  `data-card` link cannot do, because a link reports no value and belongs\n  to no group, so a card that is genuinely an answer has to be this.\n- `filled` is that same card on a ground of its own with no edge, which is\n  what a column of options wants where a hairline around every one of them\n  is a grid of lines rather than a set of answers.\n\n**`elevated` is the one value of the axis this family does not take.** A\nraised choice competes with a dialog: the top layer is where a thing that\ninterrupts you lives, and an option in a form is not one of those.\n\nThe box stays in all of them. A card whose only marker was its own border\nwould ask a reader to compare surfaces across a row to find the answer, and\nwould leave nothing for a high-contrast display.",
+              "fieldName": "separation"
             },
             {
               "name": "checked",
@@ -33219,7 +33219,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.",
               "inheritedFrom": {
                 "name": "HelixHeadlessDataTable",
                 "module": "src/data-table/root/data-table-root.ts"
@@ -39527,7 +39527,7 @@
               "type": {
                 "text": "'between' | undefined"
               },
-              "description": "Where the values sit, beside their labels.\n\nAbsent, each value starts right after the label column. `between` sets it on\nthe end edge instead, with the label on the start one, and in figures of one\nwidth so a column of numbers lines up by its digits. Only with\n`direction=\"row\"`: stacked, a label and its value share one edge already.\n\nFlex's word for the same thing, and a grid rather than a flex row\nunderneath, so the labels still share one column while the values share an\nend.",
+              "description": "Where the values sit, beside their labels.\n\nAbsent, each value starts right after the label column. `between` sets it on\nthe end edge instead, with the label on the start one, and in figures of one\nwidth so a column of numbers lines up by its digits. Only with\n`direction=\"row\"`: stacked, a label and its value share one edge already.\n\nFlex's value for the same idea, under a shorter name than Flex's own:\nthere it is `justify-content`, the CSS property it sets, and here the\nunderlying layout is a grid handing an edge down to each item as a custom\nproperty, so the labels still share one column while the values share an\nend. Naming a property this does not set after it would be the wrong kind\nof precision.",
               "attribute": "justify",
               "reflects": true
             },
@@ -39886,7 +39886,7 @@
               "type": {
                 "text": "'between' | undefined"
               },
-              "description": "Where the values sit, beside their labels.\n\nAbsent, each value starts right after the label column. `between` sets it on\nthe end edge instead, with the label on the start one, and in figures of one\nwidth so a column of numbers lines up by its digits. Only with\n`direction=\"row\"`: stacked, a label and its value share one edge already.\n\nFlex's word for the same thing, and a grid rather than a flex row\nunderneath, so the labels still share one column while the values share an\nend.",
+              "description": "Where the values sit, beside their labels.\n\nAbsent, each value starts right after the label column. `between` sets it on\nthe end edge instead, with the label on the start one, and in figures of one\nwidth so a column of numbers lines up by its digits. Only with\n`direction=\"row\"`: stacked, a label and its value share one edge already.\n\nFlex's value for the same idea, under a shorter name than Flex's own:\nthere it is `justify-content`, the CSS property it sets, and here the\nunderlying layout is a grid handing an edge down to each item as a custom\nproperty, so the labels still share one column while the values share an\nend. Naming a property this does not set after it would be the wrong kind\nof precision.",
               "fieldName": "justify"
             },
             {
@@ -40080,22 +40080,22 @@
           "members": [
             {
               "kind": "field",
-              "name": "align",
+              "name": "size",
               "type": {
-                "text": "'center' | 'start' | undefined"
+                "text": "'sm' | 'md' | 'lg' | 'full' | undefined"
               },
-              "description": "Which way the panel's contents read.\n\nOne property for the whole panel rather than one per region. The regions are\nnever mixed in practice: a dialog that asks a short question centers its\nmark, its title, its sentence and its buttons together, and a dialog holding\na form runs all four from the start. Three properties would be three ways to\nwrite the same two arrangements, and a fourth way to get one of them wrong.\n\nUnset is `start` and stays unset, so a reflected default cannot appear on a\nhost whose server output never had it.",
-              "attribute": "align",
+              "description": "How wide the panel is allowed to be.\n\nSteps rather than a number, because a dialog's width is a fact about what is\nin it: a confirmation is narrow, a form is not, and picking pixels per\ndialog is how a product ends up with nine of them. `full` takes the viewport\nless the same inset every step already stops short by, so a takeover is one\nmore rung and not a second property.\n\nUnset is `md`, read as `:host(:not([size]))` beside `:host([size=\"md\"])`\nrather than assigned here, for the reason `Drawer.placement` gives: this\nreflects, and a default would put `size=\"md\"` into markup no consumer wrote.\n\n`size` is right despite the rule that controls have no size, because that\nrule's own test is whether two of them sitting together could legitimately\ndiffer, and it is answering \"a ragged row is unwritable\". Two dialogs never\nsit together. One is on screen at a time, in the top layer, and it is the\nregion rather than a control in one, which is the other half of the axis's\ndomain: the rest of it is pictures, which are not controls either. Not\n`appearance`, which says how a thing reads rather than how wide it is.",
+              "attribute": "size",
               "reflects": true
             },
             {
               "kind": "field",
-              "name": "size",
+              "name": "textAlign",
               "type": {
-                "text": "'sm' | 'md' | 'lg' | 'full' | undefined"
+                "text": "'center' | 'start' | undefined"
               },
-              "description": "How wide the panel is allowed to be.\n\nSteps rather than a number, because a dialog's width is a fact about what is\nin it: a confirmation is narrow, a form is not, and picking pixels per\ndialog is how a product ends up with nine of them. `full` takes the viewport\nless the same inset every step already stops short by, so a takeover is one\nmore rung and not a second property.\n\nUnset is `md`, read as `:host(:not([size]))` beside `:host([size=\"md\"])`\nrather than assigned here, for the reason `Drawer.placement` gives: this\nreflects, and a default would put `size=\"md\"` into markup no consumer wrote.\n\n`size` is right despite the rule that controls have no size, because that\nrule's own test is whether two of them sitting together could legitimately\ndiffer, and it is answering \"a ragged row is unwritable\". Two dialogs never\nsit together. One is on screen at a time, in the top layer, and it is the\nregion rather than a control in one, which is the same reason `Avatar` and\n`Spinner` keep theirs. Not `appearance`, which says how a thing reads\nrather than how wide it is.",
-              "attribute": "size",
+              "description": "Which way the panel's contents read.\n\n**Text alignment, and the name says so.** `Flex` and `Grid` ask the CSS\nbox-alignment question, where things sit in a container, and they are named\nfor the properties they mirror; this one is `text-align` on a panel of\nprose, and `Table.Column` answers the same question under the same name.\nOne word for both questions is how a consumer who learned it on a layout\nwrites it here and gets no error, a value a component does not have leaving\nthe default in place and looking deliberate.\n\nOne property for the whole panel rather than one per region. The regions are\nnever mixed in practice: a dialog that asks a short question centers its\nmark, its title, its sentence and its buttons together, and a dialog holding\na form runs all four from the start. Three properties would be three ways to\nwrite the same two arrangements, and a fourth way to get one of them wrong.\n\nUnset is `start` and stays unset, so a reflected default cannot appear on a\nhost whose server output never had it.",
+              "attribute": "text-align",
               "reflects": true
             },
             {
@@ -40752,20 +40752,20 @@
           ],
           "attributes": [
             {
-              "name": "align",
+              "name": "size",
               "type": {
-                "text": "'center' | 'start' | undefined"
+                "text": "'sm' | 'md' | 'lg' | 'full' | undefined"
               },
-              "description": "Which way the panel's contents read.\n\nOne property for the whole panel rather than one per region. The regions are\nnever mixed in practice: a dialog that asks a short question centers its\nmark, its title, its sentence and its buttons together, and a dialog holding\na form runs all four from the start. Three properties would be three ways to\nwrite the same two arrangements, and a fourth way to get one of them wrong.\n\nUnset is `start` and stays unset, so a reflected default cannot appear on a\nhost whose server output never had it.",
-              "fieldName": "align"
+              "description": "How wide the panel is allowed to be.\n\nSteps rather than a number, because a dialog's width is a fact about what is\nin it: a confirmation is narrow, a form is not, and picking pixels per\ndialog is how a product ends up with nine of them. `full` takes the viewport\nless the same inset every step already stops short by, so a takeover is one\nmore rung and not a second property.\n\nUnset is `md`, read as `:host(:not([size]))` beside `:host([size=\"md\"])`\nrather than assigned here, for the reason `Drawer.placement` gives: this\nreflects, and a default would put `size=\"md\"` into markup no consumer wrote.\n\n`size` is right despite the rule that controls have no size, because that\nrule's own test is whether two of them sitting together could legitimately\ndiffer, and it is answering \"a ragged row is unwritable\". Two dialogs never\nsit together. One is on screen at a time, in the top layer, and it is the\nregion rather than a control in one, which is the other half of the axis's\ndomain: the rest of it is pictures, which are not controls either. Not\n`appearance`, which says how a thing reads rather than how wide it is.",
+              "fieldName": "size"
             },
             {
-              "name": "size",
+              "name": "text-align",
               "type": {
-                "text": "'sm' | 'md' | 'lg' | 'full' | undefined"
+                "text": "'center' | 'start' | undefined"
               },
-              "description": "How wide the panel is allowed to be.\n\nSteps rather than a number, because a dialog's width is a fact about what is\nin it: a confirmation is narrow, a form is not, and picking pixels per\ndialog is how a product ends up with nine of them. `full` takes the viewport\nless the same inset every step already stops short by, so a takeover is one\nmore rung and not a second property.\n\nUnset is `md`, read as `:host(:not([size]))` beside `:host([size=\"md\"])`\nrather than assigned here, for the reason `Drawer.placement` gives: this\nreflects, and a default would put `size=\"md\"` into markup no consumer wrote.\n\n`size` is right despite the rule that controls have no size, because that\nrule's own test is whether two of them sitting together could legitimately\ndiffer, and it is answering \"a ragged row is unwritable\". Two dialogs never\nsit together. One is on screen at a time, in the top layer, and it is the\nregion rather than a control in one, which is the same reason `Avatar` and\n`Spinner` keep theirs. Not `appearance`, which says how a thing reads\nrather than how wide it is.",
-              "fieldName": "size"
+              "description": "Which way the panel's contents read.\n\n**Text alignment, and the name says so.** `Flex` and `Grid` ask the CSS\nbox-alignment question, where things sit in a container, and they are named\nfor the properties they mirror; this one is `text-align` on a panel of\nprose, and `Table.Column` answers the same question under the same name.\nOne word for both questions is how a consumer who learned it on a layout\nwrites it here and gets no error, a value a component does not have leaving\nthe default in place and looking deliberate.\n\nOne property for the whole panel rather than one per region. The regions are\nnever mixed in practice: a dialog that asks a short question centers its\nmark, its title, its sentence and its buttons together, and a dialog holding\na form runs all four from the start. Three properties would be three ways to\nwrite the same two arrangements, and a fourth way to get one of them wrong.\n\nUnset is `start` and stays unset, so a reflected default cannot appear on a\nhost whose server output never had it.",
+              "fieldName": "textAlign"
             },
             {
               "name": "open",
@@ -52355,12 +52355,12 @@
           "members": [
             {
               "kind": "field",
-              "name": "align",
+              "name": "alignItems",
               "type": {
                 "text": "'start' | 'center' | 'end' | 'stretch' | 'baseline' | undefined"
               },
-              "description": "Alignment across the direction.",
-              "attribute": "align",
+              "description": "Alignment across the direction, which is `align-items`.\n\n**Named for the CSS property it sets, because it is that property.** A flex\ncontainer is the one place where the box-alignment words are already the\nreader's, so a shorter name would be a second vocabulary for something they\ncan already say, and `align` alone is the word four other families use for\nfour other questions: `Dialog` and `Table.Column` mean `text-align` by it.\n\n**It also keeps the name out of the browser's way.** `align` is a legacy\nHTML presentational attribute mapped to `text-align` on any element that\ncarries one, this one included: measured, an invented tag with\n`align=\"center\"` computes centered text too, so it is nothing to do with\nbeing a known element. A row that carried it therefore centered the text\ninside every field in it, through a hint no rule here declares and none can\nsee, and the fix is a name the platform has no opinion about rather than a\nguard against the hint.",
+              "attribute": "align-items",
               "reflects": true
             },
             {
@@ -52396,12 +52396,12 @@
             },
             {
               "kind": "field",
-              "name": "justify",
+              "name": "justifyContent",
               "type": {
                 "text": "'start' | 'center' | 'end' | 'between' | 'around' | undefined"
               },
-              "description": "Distribution along the direction.",
-              "attribute": "justify",
+              "description": "Distribution along the direction, which is `justify-content`.\n\nNamed for the property it sets, the way `alignItems` is. `between` and\n`around` drop the `space-` prefix and nothing else does, because those two\nare the only values whose CSS spelling is two words.",
+              "attribute": "justify-content",
               "reflects": true
             },
             {
@@ -52742,12 +52742,12 @@
           ],
           "attributes": [
             {
-              "name": "align",
+              "name": "align-items",
               "type": {
                 "text": "'start' | 'center' | 'end' | 'stretch' | 'baseline' | undefined"
               },
-              "description": "Alignment across the direction.",
-              "fieldName": "align"
+              "description": "Alignment across the direction, which is `align-items`.\n\n**Named for the CSS property it sets, because it is that property.** A flex\ncontainer is the one place where the box-alignment words are already the\nreader's, so a shorter name would be a second vocabulary for something they\ncan already say, and `align` alone is the word four other families use for\nfour other questions: `Dialog` and `Table.Column` mean `text-align` by it.\n\n**It also keeps the name out of the browser's way.** `align` is a legacy\nHTML presentational attribute mapped to `text-align` on any element that\ncarries one, this one included: measured, an invented tag with\n`align=\"center\"` computes centered text too, so it is nothing to do with\nbeing a known element. A row that carried it therefore centered the text\ninside every field in it, through a hint no rule here declares and none can\nsee, and the fix is a name the platform has no opinion about rather than a\nguard against the hint.",
+              "fieldName": "alignItems"
             },
             {
               "name": "direction",
@@ -52775,12 +52775,12 @@
               "fieldName": "inline"
             },
             {
-              "name": "justify",
+              "name": "justify-content",
               "type": {
                 "text": "'start' | 'center' | 'end' | 'between' | 'around' | undefined"
               },
-              "description": "Distribution along the direction.",
-              "fieldName": "justify"
+              "description": "Distribution along the direction, which is `justify-content`.\n\nNamed for the property it sets, the way `alignItems` is. `between` and\n`around` drop the `space-` prefix and nothing else does, because those two\nare the only values whose CSS spelling is two words.",
+              "fieldName": "justifyContent"
             },
             {
               "name": "wrap",
@@ -53791,12 +53791,12 @@
           "members": [
             {
               "kind": "field",
-              "name": "align",
+              "name": "alignItems",
               "type": {
                 "text": "'start' | 'center' | 'end' | 'stretch' | undefined"
               },
-              "description": "Alignment of each cell within its row.",
-              "attribute": "align",
+              "description": "Alignment of each cell within its row, which is `align-items`.\n\n**Named for the CSS property it sets**, the way `Flex` is, and the same\nproperty on a grid: it places every cell in its row's track rather than\nplacing the tracks. No `baseline`, which `Flex` offers, because cells in a\nrow of a grid are boxes of unrelated content and lining their first lines\nup is a thing a reader asks for between siblings in a row, not between\ncells in a table of them.\n\nThere is no `justifyContent` here for the same reason: the tracks are\n`1fr`, so they already fill the row and there is nothing left over to\ndistribute. `columns`, `min` and `--grid-columns` are how a grid says how\nwide its tracks are.",
+              "attribute": "align-items",
               "reflects": true
             },
             {
@@ -54167,12 +54167,12 @@
           ],
           "attributes": [
             {
-              "name": "align",
+              "name": "align-items",
               "type": {
                 "text": "'start' | 'center' | 'end' | 'stretch' | undefined"
               },
-              "description": "Alignment of each cell within its row.",
-              "fieldName": "align"
+              "description": "Alignment of each cell within its row, which is `align-items`.\n\n**Named for the CSS property it sets**, the way `Flex` is, and the same\nproperty on a grid: it places every cell in its row's track rather than\nplacing the tracks. No `baseline`, which `Flex` offers, because cells in a\nrow of a grid are boxes of unrelated content and lining their first lines\nup is a thing a reader asks for between siblings in a row, not between\ncells in a table of them.\n\nThere is no `justifyContent` here for the same reason: the tracks are\n`1fr`, so they already fill the row and there is nothing left over to\ndistribute. `columns`, `min` and `--grid-columns` are how a grid says how\nwide its tracks are.",
+              "fieldName": "alignItems"
             },
             {
               "name": "columns",
@@ -57447,20 +57447,19 @@
               "name": "--image-position"
             },
             {
-              "description": "Corner radius, under `rounded`.",
+              "description": "Corner radius, under `shape=\"rounded\"`.",
               "name": "--image-radius"
             }
           ],
           "members": [
             {
               "kind": "field",
-              "name": "rounded",
+              "name": "shape",
               "type": {
-                "text": "boolean"
+                "text": "'rounded' | undefined"
               },
-              "default": "false",
-              "description": "Whether the corners are cut.\n\nA boolean rather than a radius, because the radius is a token and the\nquestion a consumer is answering is whether this picture is a card's\nsurface or a page's. `--image-radius` moves it for the case that is\nneither.",
-              "attribute": "rounded",
+              "description": "Whether the corners are cut.\n\nThe axis and not a boolean, because `rounded` is a registered word and a\nprivate spelling of a registry question is what `appearance` was retired\nfor. Not a radius either: the radius is a token and the question a consumer\nis answering is whether this picture is a card's surface or a page's.\n`--image-radius` moves it for the case that is neither.",
+              "attribute": "shape",
               "reflects": true
             },
             {
@@ -58088,13 +58087,12 @@
           ],
           "attributes": [
             {
-              "name": "rounded",
+              "name": "shape",
               "type": {
-                "text": "boolean"
+                "text": "'rounded' | undefined"
               },
-              "default": "false",
-              "description": "Whether the corners are cut.\n\nA boolean rather than a radius, because the radius is a token and the\nquestion a consumer is answering is whether this picture is a card's\nsurface or a page's. `--image-radius` moves it for the case that is\nneither.",
-              "fieldName": "rounded"
+              "description": "Whether the corners are cut.\n\nThe axis and not a boolean, because `rounded` is a registered word and a\nprivate spelling of a registry question is what `appearance` was retired\nfor. Not a radius either: the radius is a token and the question a consumer\nis answering is whether this picture is a card's surface or a page's.\n`--image-radius` moves it for the case that is neither.",
+              "fieldName": "shape"
             },
             {
               "name": "alt",
@@ -67673,13 +67671,13 @@
             },
             {
               "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",
               "inheritedFrom": {
                 "name": "HelixHeadlessMegamenu",
                 "module": "src/megamenu/root/megamenu-root.ts"
@@ -67717,9 +67715,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,
               "inheritedFrom": {
@@ -68413,16 +68411,16 @@
                 "min": 360,
                 "slug": "preview"
               },
+              {
+                "description": "A band from edge to edge, for a panel too wide to hang off one word.",
+                "slug": "band"
+              },
               {
                 "description": "A panel across the navigation, announcing before it moves and after.",
                 "layout": "padded",
                 "min": 360,
                 "slug": "events"
               },
-              {
-                "description": "A band from edge to edge, for a panel too wide to hang off one word.",
-                "slug": "full"
-              },
               {
                 "description": "Opening only on a press, for a trigger that is also a link.",
                 "slug": "on-press"
@@ -68464,13 +68462,13 @@
               }
             },
             {
-              "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",
               "inheritedFrom": {
                 "name": "HelixHeadlessMegamenu",
                 "module": "src/megamenu/root/megamenu-root.ts"
@@ -68505,9 +68503,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",
               "inheritedFrom": {
                 "name": "HelixHeadlessMegamenu",
@@ -68591,7 +68589,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",
               "inheritedFrom": {
                 "name": "HelixHeadlessMegamenu",
@@ -79827,9 +79825,9 @@
               "kind": "field",
               "name": "size",
               "type": {
-                "text": "'lg' | 'sm' | undefined"
+                "text": "'sm' | 'md' | 'lg' | undefined"
               },
-              "description": "Diameter relative to the surrounding text.\n\nReflected because the stylesheet selects on it. The mesh is chosen from the\nrendered box rather than from this, so `--orb-size` and a consumer's own\n`inline-size` get the same treatment as the named steps.",
+              "description": "Diameter relative to the surrounding text.\n\n**`Loader`'s three steps, because the two are swapped for each other.** An\norb and a spinner are the same job drawn differently, a wait a reader is\nlooking at, and a product that replaces one with the other should not find\nthat a step it was writing has stopped existing. `md` is the resting one\nand selects nothing, landing on the base rule the way a written resting\nvalue does everywhere else.\n\nReflected because the stylesheet selects on it. The mesh is chosen from the\nrendered box rather than from this, so `--orb-size` and a consumer's own\n`inline-size` get the same treatment as the named steps.",
               "attribute": "size",
               "reflects": true
             },
@@ -80449,9 +80447,9 @@
             {
               "name": "size",
               "type": {
-                "text": "'lg' | 'sm' | undefined"
+                "text": "'sm' | 'md' | 'lg' | undefined"
               },
-              "description": "Diameter relative to the surrounding text.\n\nReflected because the stylesheet selects on it. The mesh is chosen from the\nrendered box rather than from this, so `--orb-size` and a consumer's own\n`inline-size` get the same treatment as the named steps.",
+              "description": "Diameter relative to the surrounding text.\n\n**`Loader`'s three steps, because the two are swapped for each other.** An\norb and a spinner are the same job drawn differently, a wait a reader is\nlooking at, and a product that replaces one with the other should not find\nthat a step it was writing has stopped existing. `md` is the resting one\nand selects nothing, landing on the base rule the way a written resting\nvalue does everywhere else.\n\nReflected because the stylesheet selects on it. The mesh is chosen from the\nrendered box rather than from this, so `--orb-size` and a consumer's own\n`inline-size` get the same treatment as the named steps.",
               "fieldName": "size"
             },
             {
@@ -87295,6 +87293,14 @@
               "description": "Thickness of its stroke.",
               "name": "--progress-ring-width"
             },
+            {
+              "description": "Thickness of the bar.",
+              "name": "--progress-size"
+            },
+            {
+              "description": "Fill of the part that is not.",
+              "name": "--progress-track-color"
+            },
             {
               "description": "The value as a fraction of the range, 0 to 1. Pinned to 1 while indeterminate.",
               "name": "--progress-fraction",
@@ -90481,17 +90487,27 @@
                 "text": "boolean"
               },
               "default": "false",
-              "description": "Takes the circle away, leaving the card as the whole control.\n\nUnnecessary under `chip`, which has no room for a circle beside its mark\nand hides it already.\n\n`card` only, and it is a graphic that goes rather than a radio: the control\nin the shadow root is untouched, so the row is still focusable, still\nreported to a screen reader, and still the thing a form submits.\n\nSafe because the card already carries the answer in its surface, a raised\nfill inside a primary edge and a three-pixel ring of it. Without that ring\nnothing would be left saying which card was chosen.\n\nNot on `Checkbox`, deliberately. A radio card with no circle is still\nunmistakably one-of-many because its siblings behave that way; a checkbox\ncard with no box loses the only thing that says you may pick several.",
+              "description": "Takes the circle away, leaving the card as the whole control.\n\nUnnecessary under `chip`, which has no room for a circle beside its mark\nand hides it already.\n\nA separated choice only, and it is a graphic that goes rather than a radio:\nthe control in the shadow root is untouched, so the row is still focusable,\nstill reported to a screen reader, and still the thing a form submits.\n\nSafe because the card already carries the answer in its surface, a raised\nfill inside a primary edge and a three-pixel ring of it. Without that ring\nnothing would be left saying which card was chosen.\n\nNot on `Checkbox`, deliberately. A radio card with no circle is still\nunmistakably one-of-many because its siblings behave that way; a checkbox\ncard with no box loses the only thing that says you may pick several.",
               "attribute": "hide-control",
               "reflects": true
             },
+            {
+              "kind": "field",
+              "name": "separation",
+              "type": {
+                "text": "'filled' | 'outlined' | 'plain' | undefined"
+              },
+              "description": "Where the choice's own surface ends.\n\nThe question `separation` asks everywhere else, asked of one option, so it\nis that word: what these values pick is a surface, and `plain` is already\nthe registry's own word for the answer this family used it for.\n\n- `plain` is the resting one and is never written: a circle beside its\n  words, which is what a list of choices should be almost always.\n- `outlined` puts it in a bounded surface, for options that need room to\n  explain themselves: a description, an icon, a price. It is the half a\n  `data-card` link cannot do, because a link reports no value and belongs\n  to no group, so a card that is genuinely an answer has to be this.\n- `filled` is that same card on a ground of its own with no edge, which is\n  what a column of choices wants where a hairline around every one of them\n  is a grid of lines rather than a set of answers.\n\n**`elevated` is the one value of the axis this family does not take.** A\nraised choice competes with a dialog: the top layer is where a thing that\ninterrupts you lives, and an option in a form is not one of those, so a\ncolumn of lifted cards reads as a stack of floating things none of which is\nsettled.\n\nThe circle stays in all of them. A card whose only marker was its own\nborder would ask a reader to compare surfaces across a row to find the\nanswer, and would leave nothing for a high-contrast display.",
+              "attribute": "separation",
+              "reflects": true
+            },
             {
               "kind": "field",
               "name": "variant",
               "type": {
-                "text": "'chip' | 'plain' | 'card' | undefined"
+                "text": "'chip' | undefined"
               },
-              "description": "How the choice presents itself.\n\n- `plain` is the default and is never written: a circle beside its words,\n  which is what a list of choices should be almost always.\n- `card` puts it in a bounded surface, for options that need room to\n  explain themselves: a description, an icon, a price. It is the half a\n  `data-card` link cannot do, because a link reports no value and belongs\n  to no group, so a card that is genuinely an answer has to be this.\n- `chip` is the answer as its own small surface, for a row of short\n  choices read at a glance. It hides the circle, the surface being the\n  whole mark, which is why `hide-control` says it is unnecessary here.\n\nThe circle stays in both. A card whose only marker was its own border would\nask a reader to compare surfaces across a row to find the answer, and would\nleave nothing for a high-contrast display.",
+              "description": "The answer as its own small surface, for a row of short choices read at a\nglance.\n\n**Not a separation, which is why it is still `variant`.** The other values\npick where a surface ends around a row that keeps its circle and its words;\na chip has neither. It hides the circle, the surface being the whole mark,\nwhich is why `hide-control` says it is unnecessary here, and it takes the\nwords out of the flow to be the accessible name. That removes the\ndistinction `separation` exists to make rather than answering it.",
               "attribute": "variant",
               "reflects": true
             },
@@ -90943,15 +90959,23 @@
                 "text": "boolean"
               },
               "default": "false",
-              "description": "Takes the circle away, leaving the card as the whole control.\n\nUnnecessary under `chip`, which has no room for a circle beside its mark\nand hides it already.\n\n`card` only, and it is a graphic that goes rather than a radio: the control\nin the shadow root is untouched, so the row is still focusable, still\nreported to a screen reader, and still the thing a form submits.\n\nSafe because the card already carries the answer in its surface, a raised\nfill inside a primary edge and a three-pixel ring of it. Without that ring\nnothing would be left saying which card was chosen.\n\nNot on `Checkbox`, deliberately. A radio card with no circle is still\nunmistakably one-of-many because its siblings behave that way; a checkbox\ncard with no box loses the only thing that says you may pick several.",
+              "description": "Takes the circle away, leaving the card as the whole control.\n\nUnnecessary under `chip`, which has no room for a circle beside its mark\nand hides it already.\n\nA separated choice only, and it is a graphic that goes rather than a radio:\nthe control in the shadow root is untouched, so the row is still focusable,\nstill reported to a screen reader, and still the thing a form submits.\n\nSafe because the card already carries the answer in its surface, a raised\nfill inside a primary edge and a three-pixel ring of it. Without that ring\nnothing would be left saying which card was chosen.\n\nNot on `Checkbox`, deliberately. A radio card with no circle is still\nunmistakably one-of-many because its siblings behave that way; a checkbox\ncard with no box loses the only thing that says you may pick several.",
               "fieldName": "hideControl"
             },
+            {
+              "name": "separation",
+              "type": {
+                "text": "'filled' | 'outlined' | 'plain' | undefined"
+              },
+              "description": "Where the choice's own surface ends.\n\nThe question `separation` asks everywhere else, asked of one option, so it\nis that word: what these values pick is a surface, and `plain` is already\nthe registry's own word for the answer this family used it for.\n\n- `plain` is the resting one and is never written: a circle beside its\n  words, which is what a list of choices should be almost always.\n- `outlined` puts it in a bounded surface, for options that need room to\n  explain themselves: a description, an icon, a price. It is the half a\n  `data-card` link cannot do, because a link reports no value and belongs\n  to no group, so a card that is genuinely an answer has to be this.\n- `filled` is that same card on a ground of its own with no edge, which is\n  what a column of choices wants where a hairline around every one of them\n  is a grid of lines rather than a set of answers.\n\n**`elevated` is the one value of the axis this family does not take.** A\nraised choice competes with a dialog: the top layer is where a thing that\ninterrupts you lives, and an option in a form is not one of those, so a\ncolumn of lifted cards reads as a stack of floating things none of which is\nsettled.\n\nThe circle stays in all of them. A card whose only marker was its own\nborder would ask a reader to compare surfaces across a row to find the\nanswer, and would leave nothing for a high-contrast display.",
+              "fieldName": "separation"
+            },
             {
               "name": "variant",
               "type": {
-                "text": "'chip' | 'plain' | 'card' | undefined"
+                "text": "'chip' | undefined"
               },
-              "description": "How the choice presents itself.\n\n- `plain` is the default and is never written: a circle beside its words,\n  which is what a list of choices should be almost always.\n- `card` puts it in a bounded surface, for options that need room to\n  explain themselves: a description, an icon, a price. It is the half a\n  `data-card` link cannot do, because a link reports no value and belongs\n  to no group, so a card that is genuinely an answer has to be this.\n- `chip` is the answer as its own small surface, for a row of short\n  choices read at a glance. It hides the circle, the surface being the\n  whole mark, which is why `hide-control` says it is unnecessary here.\n\nThe circle stays in both. A card whose only marker was its own border would\nask a reader to compare surfaces across a row to find the answer, and would\nleave nothing for a high-contrast display.",
+              "description": "The answer as its own small surface, for a row of short choices read at a\nglance.\n\n**Not a separation, which is why it is still `variant`.** The other values\npick where a surface ends around a row that keeps its circle and its words;\na chip has neither. It hides the circle, the surface being the whole mark,\nwhich is why `hide-control` says it is unnecessary here, and it takes the\nwords out of the flow to be the accessible name. That removes the\ndistinction `separation` exists to make rather than answering it.",
               "fieldName": "variant"
             },
             {
@@ -91260,12 +91284,12 @@
           "members": [
             {
               "kind": "field",
-              "name": "variant",
+              "name": "shape",
               "type": {
-                "text": "'dots' | 'marks' | undefined"
+                "text": "'dots' | undefined"
               },
-              "description": "Which mark the row is drawn with.\n\n`marks` is the star, and is what a rating means to most readers. `dots`\ndrops the glyph for a plain circle, which says how much rather than how\ngood: a star carries a judgment that a level of spice, a difficulty or a\nconfidence has not earned.\n\nBoth are one shape repeated and clipped to the score, so halves work in\neither, and both are only a choice of drawing. A scale whose marks are\n*different* drawings is a set of choices rather than a quantity: that is\n`Radio.Group`, whose options already carry a value and a name each.\n\n**Undefaulted, because it reflects.** A default of `marks` writes\n`variant=\"marks\"` onto every server-rendered rating, which React holds no\nprop for and reports as a hydration mismatch. The stylesheet names only\n`dots`, so an unset one draws marks anyway.",
-              "attribute": "variant",
+              "description": "The geometry one mark is drawn to.\n\nThe registry's word, because the question is the registry's: `Avatar`,\n`Skeleton`, `IconButton`, `Meter` and `Progress` each ask what geometry\ntheir own thing is cut to under this name, and `dots` is already a value\nthe axis holds. What is picked here is the outline of one mark and nothing\nelse, which is a shape and not a component-specific choice.\n\n`dots` drops the glyph for a plain circle, which says how much rather than\nhow good: a star carries a judgment that a level of spice, a difficulty or\na confidence has not earned. Either way it is one shape repeated and\nclipped to the score, so halves work in both. A scale whose marks are\n*different* drawings is a set of choices rather than a quantity: that is\n`Radio.Group`, whose options already carry a value and a name each.\n\n**The star is the resting one and has no word**, which is the rule every\naxis follows and is also what this family needed anyway: it reflects, so a\ndefault would write the resting value onto every server-rendered rating,\nan attribute React holds no prop for and so a hydration mismatch for each\none. The stylesheet names only `dots`, so an unset one draws the star by\nlanding on the base rule.",
+              "attribute": "shape",
               "reflects": true
             },
             {
@@ -92535,12 +92559,12 @@
           ],
           "attributes": [
             {
-              "name": "variant",
+              "name": "shape",
               "type": {
-                "text": "'dots' | 'marks' | undefined"
+                "text": "'dots' | undefined"
               },
-              "description": "Which mark the row is drawn with.\n\n`marks` is the star, and is what a rating means to most readers. `dots`\ndrops the glyph for a plain circle, which says how much rather than how\ngood: a star carries a judgment that a level of spice, a difficulty or a\nconfidence has not earned.\n\nBoth are one shape repeated and clipped to the score, so halves work in\neither, and both are only a choice of drawing. A scale whose marks are\n*different* drawings is a set of choices rather than a quantity: that is\n`Radio.Group`, whose options already carry a value and a name each.\n\n**Undefaulted, because it reflects.** A default of `marks` writes\n`variant=\"marks\"` onto every server-rendered rating, which React holds no\nprop for and reports as a hydration mismatch. The stylesheet names only\n`dots`, so an unset one draws marks anyway.",
-              "fieldName": "variant"
+              "description": "The geometry one mark is drawn to.\n\nThe registry's word, because the question is the registry's: `Avatar`,\n`Skeleton`, `IconButton`, `Meter` and `Progress` each ask what geometry\ntheir own thing is cut to under this name, and `dots` is already a value\nthe axis holds. What is picked here is the outline of one mark and nothing\nelse, which is a shape and not a component-specific choice.\n\n`dots` drops the glyph for a plain circle, which says how much rather than\nhow good: a star carries a judgment that a level of spice, a difficulty or\na confidence has not earned. Either way it is one shape repeated and\nclipped to the score, so halves work in both. A scale whose marks are\n*different* drawings is a set of choices rather than a quantity: that is\n`Radio.Group`, whose options already carry a value and a name each.\n\n**The star is the resting one and has no word**, which is the rule every\naxis follows and is also what this family needed anyway: it reflects, so a\ndefault would write the resting value onto every server-rendered rating,\nan attribute React holds no prop for and so a hydration mismatch for each\none. The stylesheet names only `dots`, so an unset one draws the star by\nlanding on the base rule.",
+              "fieldName": "shape"
             },
             {
               "name": "default-value",
@@ -98559,7 +98583,7 @@
               "type": {
                 "text": "'ghost' | undefined"
               },
-              "description": "How much ink the trigger claims.\n\n**The first field in this library to take an axis, and the case that asked\nfor it is a control in a row rather than a control on a form.** A chat's\ncomposer wants a model picker beside an attachment button and a send button:\nat the field's own frame it is 40 pixels of bordered well in a line of 28\npixel glyphs, and it reads as the composer's subject rather than as one of\nits tools. The same is true of a select in a toolbar, in a table header, or\ninside a sentence.\n\n- Unset is the frame an `Input` wears, which is what a form wants: a control\n  that looks like a button among fields reads as an action rather than an\n  answer.\n- `ghost` drops the fill and the edge, takes the width of what is in it, and\n  puts the mark against the value instead of at the far end of the control.\n\n**`emphasis` and not `separation`, which the registry decides rather than\ntaste.** Emphasis is asked of controls, how loud this one is; separation is\nasked of containers, where the surface ends. A trigger is a control, and a\nfamily may not declare both. Three of the five values are refused: `solid`\nand `subtle` are a button's way of being the one thing to press, which is\nnot a thing an answer should ever be, and `muted` is the quiet ink `Text`\ntakes, where a trigger's loudness is its frame rather than its ink.\n`outlined` is what the unset frame already draws, so writing it would be\nwriting the resting state out.\n\n**The other three fields want this too and do not have it yet.** `Input`,\n`Textarea` and `Combobox` wear the same frame from the same shared\nstylesheet, and an inline one of each is as reasonable as an inline select.\nThey are left alone rather than swept, because each has a different thing\ninside the frame and guessing at three is how an axis ends up meaning four\nthings, which is the fault `appearance` was retired for.",
+              "description": "How much ink the trigger claims.\n\n**The first field in this library to take an axis, and the case that asked\nfor it is a control in a row rather than a control on a form.** A chat's\ncomposer wants a model picker beside an attachment button and a send button:\nat the field's own frame it is 40 pixels of bordered well in a line of 28\npixel glyphs, and it reads as the composer's subject rather than as one of\nits tools. The same is true of a select in a toolbar, in a table header, or\ninside a sentence.\n\n- Unset is the frame an `Input` wears, which is what a form wants: a control\n  that looks like a button among fields reads as an action rather than an\n  answer.\n- `ghost` drops the fill and the edge, takes the width of what is in it, and\n  puts the mark against the value instead of at the far end of the control.\n\n**`emphasis` and not `separation`, which the registry decides rather than\ntaste.** Emphasis is asked of controls, how loud this one is; separation is\nasked of containers, where the surface ends. A trigger is a control, and a\nfamily may not declare both. Three of the five values are refused: `solid`\nand `subtle` are a button's way of being the one thing to press, which is\nnot a thing an answer should ever be, and `muted` is the quiet ink `Text`\ntakes, where a trigger's loudness is its frame rather than its ink.\n`outlined` is what the unset frame already draws, so writing it would be\nwriting the resting state out.\n\n**Every field wearing `field-frame.css` wants this too and does not have it\nyet**, which this trigger is not one of: it draws its own frame below. An\ninline number input in a toolbar is as reasonable as an inline select. They\nare left alone rather than swept, because each has a different thing inside\nthe frame and guessing at a set of them is how an axis ends up meaning four\nthings, which is the fault `appearance` was retired for.",
               "attribute": "emphasis",
               "reflects": true
             },
@@ -99760,7 +99784,7 @@
               "type": {
                 "text": "'ghost' | undefined"
               },
-              "description": "How much ink the trigger claims.\n\n**The first field in this library to take an axis, and the case that asked\nfor it is a control in a row rather than a control on a form.** A chat's\ncomposer wants a model picker beside an attachment button and a send button:\nat the field's own frame it is 40 pixels of bordered well in a line of 28\npixel glyphs, and it reads as the composer's subject rather than as one of\nits tools. The same is true of a select in a toolbar, in a table header, or\ninside a sentence.\n\n- Unset is the frame an `Input` wears, which is what a form wants: a control\n  that looks like a button among fields reads as an action rather than an\n  answer.\n- `ghost` drops the fill and the edge, takes the width of what is in it, and\n  puts the mark against the value instead of at the far end of the control.\n\n**`emphasis` and not `separation`, which the registry decides rather than\ntaste.** Emphasis is asked of controls, how loud this one is; separation is\nasked of containers, where the surface ends. A trigger is a control, and a\nfamily may not declare both. Three of the five values are refused: `solid`\nand `subtle` are a button's way of being the one thing to press, which is\nnot a thing an answer should ever be, and `muted` is the quiet ink `Text`\ntakes, where a trigger's loudness is its frame rather than its ink.\n`outlined` is what the unset frame already draws, so writing it would be\nwriting the resting state out.\n\n**The other three fields want this too and do not have it yet.** `Input`,\n`Textarea` and `Combobox` wear the same frame from the same shared\nstylesheet, and an inline one of each is as reasonable as an inline select.\nThey are left alone rather than swept, because each has a different thing\ninside the frame and guessing at three is how an axis ends up meaning four\nthings, which is the fault `appearance` was retired for.",
+              "description": "How much ink the trigger claims.\n\n**The first field in this library to take an axis, and the case that asked\nfor it is a control in a row rather than a control on a form.** A chat's\ncomposer wants a model picker beside an attachment button and a send button:\nat the field's own frame it is 40 pixels of bordered well in a line of 28\npixel glyphs, and it reads as the composer's subject rather than as one of\nits tools. The same is true of a select in a toolbar, in a table header, or\ninside a sentence.\n\n- Unset is the frame an `Input` wears, which is what a form wants: a control\n  that looks like a button among fields reads as an action rather than an\n  answer.\n- `ghost` drops the fill and the edge, takes the width of what is in it, and\n  puts the mark against the value instead of at the far end of the control.\n\n**`emphasis` and not `separation`, which the registry decides rather than\ntaste.** Emphasis is asked of controls, how loud this one is; separation is\nasked of containers, where the surface ends. A trigger is a control, and a\nfamily may not declare both. Three of the five values are refused: `solid`\nand `subtle` are a button's way of being the one thing to press, which is\nnot a thing an answer should ever be, and `muted` is the quiet ink `Text`\ntakes, where a trigger's loudness is its frame rather than its ink.\n`outlined` is what the unset frame already draws, so writing it would be\nwriting the resting state out.\n\n**Every field wearing `field-frame.css` wants this too and does not have it\nyet**, which this trigger is not one of: it draws its own frame below. An\ninline number input in a toolbar is as reasonable as an inline select. They\nare left alone rather than swept, because each has a different thing inside\nthe frame and guessing at a set of them is how an axis ends up meaning four\nthings, which is the fault `appearance` was retired for.",
               "fieldName": "emphasis"
             },
             {
@@ -111507,20 +111531,6 @@
           "description": "Styled as the header cell it is, and it carries the same rule and inset as\nthe cells beneath it so the heading and its column read as one line down the\ntable.",
           "name": "HelixTableColumn",
           "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,
-              "inheritedFrom": {
-                "name": "HelixHeadlessTableColumn",
-                "module": "src/table/column/table-column.ts"
-              }
-            },
             {
               "kind": "field",
               "name": "cell",
@@ -111590,6 +111600,20 @@
                 "module": "src/table/column/table-column.ts"
               }
             },
+            {
+              "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,
+              "inheritedFrom": {
+                "name": "HelixHeadlessTableColumn",
+                "module": "src/table/column/table-column.ts"
+              }
+            },
             {
               "kind": "field",
               "name": "width",
@@ -112281,18 +112305,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",
-              "inheritedFrom": {
-                "name": "HelixHeadlessTableColumn",
-                "module": "src/table/column/table-column.ts"
-              }
-            },
             {
               "name": "field",
               "type": {
@@ -112332,6 +112344,18 @@
                 "module": "src/table/column/table-column.ts"
               }
             },
+            {
+              "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",
+              "inheritedFrom": {
+                "name": "HelixHeadlessTableColumn",
+                "module": "src/table/column/table-column.ts"
+              }
+            },
             {
               "name": "width",
               "type": {
@@ -112794,7 +112818,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.",
               "inheritedFrom": {
                 "name": "HelixHeadlessTable",
                 "module": "src/table/root/table-root.ts"