@fusion.dev/helix 0.54.0 → 0.55.0

package/types/vue.d.ts

@@ -680,7 +680,11 @@ export type HelixAvatarGroupVueEvents = {};
 export type HelixAvatarElementEvent<E = Event> = TypedEvent<HelixAvatar, E>;
 
 export type HelixAvatarVueProps = {
-  /** Whether the avatar is a circle or a rounded square. */
+  /** Whether the avatar is a circle or a rounded square.
+
+`rounded` and not `square`, which is the sharp-cornered pole of the same
+axis and what `QrCode` draws with it. This corner is `radii-md`, so the word
+for it is the one the registry already has. */
   shape?: (HelixAvatar["shape"]) | undefined;
   /** Edge length of the avatar. */
   size?: (HelixAvatar["size"]) | undefined;
@@ -871,19 +875,12 @@ shadow root names a table in that root rather than in the document. A
 Absent falls back to the table's own caption, which is usually the right
 words and is already written. */
   label?: (HelixBarChart["label"]) | undefined;
-  /** Whether the categories run down the side rather than along the bottom.
-
-Absent is columns. `horizontal` is the one to reach for when the category
-names are words rather than dates: a row of long names either overlaps or
-turns on its side, and neither is as readable as putting them down the left
-where they read normally. */
-  direction?: (HelixBarChart["direction"]) | undefined;
   /** Which rules are drawn across the plot, if any.
 
 Absent draws none. `value` rules the axis the columns are *measured* on,
 `category` rules the axis they are *arranged* on with one through each
 group, and `both` draws both. Which of those is horizontal turns with
-`direction`, because a rule belongs to an axis and not to a screen edge.
+`orientation`, because a rule belongs to an axis and not to a screen edge.
 
 **A bare `gridlines` means `value`**, and so does anything unrecognized: an
 unrecognized value that draws nothing is indistinguishable from the
@@ -919,6 +916,16 @@ A line among columns measures from zero, because the columns do and they
 share the axis. So does a line on the second scale, which is that scale's
 own rule rather than this one's. */
   lines?: (HelixBarChart["lines"]) | undefined;
+  /** Whether the categories run down the side rather than along the bottom.
+
+Absent is columns. `horizontal` is the one to reach for when the category
+names are words rather than dates: a row of long names either overlaps or
+turns on its side, and neither is as readable as putting them down the left
+where they read normally.
+
+`orientation` and not `orientation`, which `Trend` uses in the same group for
+which way a number moved. */
+  orientation?: (HelixBarChart["orientation"]) | undefined;
   /** Which series are measured against a scale of their own, by name.
 
 Separated and matched the way `lines` is, against the column headings the
@@ -1359,9 +1366,9 @@ where an arrow over a photograph belongs. */
   /** Which side of the slides the arrows sit on.
 
 The same four sides as `indicatorPlacement` and the same default, so a
-carousel that moves only one of them keeps the other where it was.
-`inline-start` or `inline-end` stacks the arrows into a column, which is
-what a vertical track usually wants.
+carousel that moves only one of them keeps the other where it was. `start`
+or `end` stacks the arrows into a column, which is what a vertical track
+usually wants.
 
 `overlay` puts them on the slides, at the track's own edges, which is what a
 full-bleed carousel wants: the slide is the page and the controls are on it
@@ -1378,9 +1385,9 @@ chrome can go. */
   /** Which side of the slides the arrows sit on.
 
 The same four sides as `indicatorPlacement` and the same default, so a
-carousel that moves only one of them keeps the other where it was.
-`inline-start` or `inline-end` stacks the arrows into a column, which is
-what a vertical track usually wants.
+carousel that moves only one of them keeps the other where it was. `start`
+or `end` stacks the arrows into a column, which is what a vertical track
+usually wants.
 
 `overlay` puts them on the slides, at the track's own edges, which is what a
 full-bleed carousel wants: the slide is the page and the controls are on it
@@ -1408,8 +1415,9 @@ block edge the run is a row and this is `justify-self`; on an inline edge it
 is a column and the same question is `align-self`. A consumer should not
 have to know which of those two words their edge wanted.
 
-Logical, like the placement: `start` is the left in English and the right in
-Arabic on a horizontal run, and the top on a vertical one.
+Logical, like the placement's own `start` and `end`: `start` is the left in
+English and the right in Arabic on a horizontal run, and the top on a
+vertical one.
 
 Unset splits the row, dots to the start and arrows to the end, which is
 what keeps two items in one grid cell from landing on each other. Beside the
@@ -1432,8 +1440,9 @@ block edge the run is a row and this is `justify-self`; on an inline edge it
 is a column and the same question is `align-self`. A consumer should not
 have to know which of those two words their edge wanted.
 
-Logical, like the placement: `start` is the left in English and the right in
-Arabic on a horizontal run, and the top on a vertical one.
+Logical, like the placement's own `start` and `end`: `start` is the left in
+English and the right in Arabic on a horizontal run, and the top on a
+vertical one.
 
 Unset splits the row, dots to the start and arrows to the end, which is
 what keeps two items in one grid cell from landing on each other. Beside the
@@ -1444,31 +1453,43 @@ exist to avoid. */
   indicatorAlign?: (HelixCarousel["indicatorAlign"]) | undefined;
   /** Which side of the slides the dots sit on.
 
-Unset is `block-end`, under them. `block-start` puts them above,
-`inline-start` and `inline-end` beside, where a run of dots becomes a
-column.
+Unset is `bottom`, under them. `top` puts them above, `start` and `end`
+beside, where a run of dots becomes a column.
+
+**The sides of the content, not positions along a bar.** `start` and `end`
+are the logical ones and they are logical because that axis flips: a
+carousel with its dots at the start should put them on the right in Arabic
+without being told. `top` and `bottom` are the block edges, which flip in
+no writing mode this library draws for, so the plain word is the honest one
+and `block-start` would be jargon standing in for it.
 
-**The sides of the content, not positions along a bar**, and logical names
-rather than `top`/`left`: an `inline-start` carousel should put its dots on
-the right in Arabic without being told.
+**`Drawer` and `Toast` say it in exactly these four words**, and one
+vocabulary across the three is worth more than each family's own: a
+consumer who has placed a drawer knows where a carousel's dots go.
 
-Independent of `controlsPlacement`. Both default to the block end, where
-they share the row and split it, dots to the start and arrows to the end,
+Independent of `controlsPlacement`. Both default to the bottom, where they
+share the row and split it, dots to the start and arrows to the end,
 arrived at by two defaults rather than by a rule about the pair, so moving
 one leaves the other alone. */
   "indicator-placement"?: (HelixCarousel["indicatorPlacement"]) | undefined;
   /** Which side of the slides the dots sit on.
 
-Unset is `block-end`, under them. `block-start` puts them above,
-`inline-start` and `inline-end` beside, where a run of dots becomes a
-column.
+Unset is `bottom`, under them. `top` puts them above, `start` and `end`
+beside, where a run of dots becomes a column.
+
+**The sides of the content, not positions along a bar.** `start` and `end`
+are the logical ones and they are logical because that axis flips: a
+carousel with its dots at the start should put them on the right in Arabic
+without being told. `top` and `bottom` are the block edges, which flip in
+no writing mode this library draws for, so the plain word is the honest one
+and `block-start` would be jargon standing in for it.
 
-**The sides of the content, not positions along a bar**, and logical names
-rather than `top`/`left`: an `inline-start` carousel should put its dots on
-the right in Arabic without being told.
+**`Drawer` and `Toast` say it in exactly these four words**, and one
+vocabulary across the three is worth more than each family's own: a
+consumer who has placed a drawer knows where a carousel's dots go.
 
-Independent of `controlsPlacement`. Both default to the block end, where
-they share the row and split it, dots to the start and arrows to the end,
+Independent of `controlsPlacement`. Both default to the bottom, where they
+share the row and split it, dots to the start and arrows to the end,
 arrived at by two defaults rather than by a rule about the pair, so moving
 one leaves the other alone. */
   indicatorPlacement?: (HelixCarousel["indicatorPlacement"]) | undefined;
@@ -1936,19 +1957,31 @@ export type HelixCheckboxHelixBeforeToggleElementEvent =
   HelixCheckboxElementEvent<HelixBeforeToggleEvent>;
 
 export type HelixCheckboxVueProps = {
-  /** How the choice presents itself.
+  /** Where the choice's own surface ends.
 
-- `plain` is the default and is never written: a box beside its words,
+The question `separation` asks everywhere else, asked of one option, so it
+is that word: what these values pick is a surface, and `plain` is already
+the registry's own word for the answer this family used it for. `Radio`
+takes the same three for the same reason.
+
+- `plain` is the resting one and is never written: a box beside its words,
   which is what a list of choices should be almost always.
-- `card` puts it in a bounded surface, for options that need room to
+- `outlined` puts it in a bounded surface, for options that need room to
   explain themselves: a description, an icon, a price. It is the half a
   `data-card` link cannot do, because a link reports no value and belongs
   to no group, so a card that is genuinely an answer has to be this.
-
-The box stays in both. A card whose only marker was its own border would
-ask a reader to compare surfaces across a row to find the answer, and would
-leave nothing for a high-contrast display. */
-  variant?: (HelixCheckbox["variant"]) | undefined;
+- `filled` is that same card on a ground of its own with no edge, which is
+  what a column of options wants where a hairline around every one of them
+  is a grid of lines rather than a set of answers.
+
+**`elevated` is the one value of the axis this family does not take.** A
+raised choice competes with a dialog: the top layer is where a thing that
+interrupts you lives, and an option in a form is not one of those.
+
+The box stays in all of them. A card whose only marker was its own border
+would ask a reader to compare surfaces across a row to find the answer, and
+would leave nothing for a high-contrast display. */
+  separation?: (HelixCheckbox["separation"]) | undefined;
   /** Whether the control is checked.
 
 One property rather than two. Writing always applies;
@@ -3531,9 +3564,12 @@ the end edge instead, with the label on the start one, and in figures of one
 width so a column of numbers lines up by its digits. Only with
 `direction="row"`: stacked, a label and its value share one edge already.
 
-Flex's word for the same thing, and a grid rather than a flex row
-underneath, so the labels still share one column while the values share an
-end. */
+Flex's value for the same idea, under a shorter name than Flex's own:
+there it is `justify-content`, the CSS property it sets, and here the
+underlying layout is a grid handing an edge down to each item as a custom
+property, so the labels still share one column while the values share an
+end. Naming a property this does not set after it would be the wrong kind
+of precision. */
   justify?: (HelixDescriptionList["justify"]) | undefined;
   /** How wide the list is.
 
@@ -3573,17 +3609,6 @@ export type HelixDialogHelixBeforeOpenElementEvent =
   HelixDialogElementEvent<HelixBeforeOpenEvent>;
 
 export type HelixDialogVueProps = {
-  /** Which way the panel's contents read.
-
-One property for the whole panel rather than one per region. The regions are
-never mixed in practice: a dialog that asks a short question centers its
-mark, its title, its sentence and its buttons together, and a dialog holding
-a form runs all four from the start. Three properties would be three ways to
-write the same two arrangements, and a fourth way to get one of them wrong.
-
-Unset is `start` and stays unset, so a reflected default cannot appear on a
-host whose server output never had it. */
-  align?: (HelixDialog["align"]) | undefined;
   /** How wide the panel is allowed to be.
 
 Steps rather than a number, because a dialog's width is a fact about what is
@@ -3600,10 +3625,48 @@ reflects, and a default would put `size="md"` into markup no consumer wrote.
 rule's own test is whether two of them sitting together could legitimately
 differ, and it is answering "a ragged row is unwritable". Two dialogs never
 sit together. One is on screen at a time, in the top layer, and it is the
-region rather than a control in one, which is the same reason `Avatar` and
-`Spinner` keep theirs. Not `appearance`, which says how a thing reads
-rather than how wide it is. */
+region rather than a control in one, which is the other half of the axis's
+domain: the rest of it is pictures, which are not controls either. Not
+`appearance`, which says how a thing reads rather than how wide it is. */
   size?: (HelixDialog["size"]) | undefined;
+  /** Which way the panel's contents read.
+
+**Text alignment, and the name says so.** `Flex` and `Grid` ask the CSS
+box-alignment question, where things sit in a container, and they are named
+for the properties they mirror; this one is `text-align` on a panel of
+prose, and `Table.Column` answers the same question under the same name.
+One word for both questions is how a consumer who learned it on a layout
+writes it here and gets no error, a value a component does not have leaving
+the default in place and looking deliberate.
+
+One property for the whole panel rather than one per region. The regions are
+never mixed in practice: a dialog that asks a short question centers its
+mark, its title, its sentence and its buttons together, and a dialog holding
+a form runs all four from the start. Three properties would be three ways to
+write the same two arrangements, and a fourth way to get one of them wrong.
+
+Unset is `start` and stays unset, so a reflected default cannot appear on a
+host whose server output never had it. */
+  "text-align"?: (HelixDialog["textAlign"]) | undefined;
+  /** Which way the panel's contents read.
+
+**Text alignment, and the name says so.** `Flex` and `Grid` ask the CSS
+box-alignment question, where things sit in a container, and they are named
+for the properties they mirror; this one is `text-align` on a panel of
+prose, and `Table.Column` answers the same question under the same name.
+One word for both questions is how a consumer who learned it on a layout
+writes it here and gets no error, a value a component does not have leaving
+the default in place and looking deliberate.
+
+One property for the whole panel rather than one per region. The regions are
+never mixed in practice: a dialog that asks a short question centers its
+mark, its title, its sentence and its buttons together, and a dialog holding
+a form runs all four from the start. Three properties would be three ways to
+write the same two arrangements, and a fourth way to get one of them wrong.
+
+Unset is `start` and stays unset, so a reflected default cannot appear on a
+host whose server output never had it. */
+  textAlign?: (HelixDialog["textAlign"]) | undefined;
   /** Whether the element is open.
 
 One property, not two, so `dialog.open` answers the question anyone
@@ -4393,16 +4456,58 @@ export type HelixFilterInputVueEvents = {
 };
 
 export type HelixFlexVueProps = {
-  /** Alignment across the direction. */
-  align?: (HelixFlex["align"]) | undefined;
+  /** Alignment across the direction, which is `align-items`.
+
+**Named for the CSS property it sets, because it is that property.** A flex
+container is the one place where the box-alignment words are already the
+reader's, so a shorter name would be a second vocabulary for something they
+can already say, and `align` alone is the word four other families use for
+four other questions: `Dialog` and `Table.Column` mean `text-align` by it.
+
+**It also keeps the name out of the browser's way.** `align` is a legacy
+HTML presentational attribute mapped to `text-align` on any element that
+carries one, this one included: measured, an invented tag with
+`align="center"` computes centered text too, so it is nothing to do with
+being a known element. A row that carried it therefore centered the text
+inside every field in it, through a hint no rule here declares and none can
+see, and the fix is a name the platform has no opinion about rather than a
+guard against the hint. */
+  "align-items"?: (HelixFlex["alignItems"]) | undefined;
+  /** Alignment across the direction, which is `align-items`.
+
+**Named for the CSS property it sets, because it is that property.** A flex
+container is the one place where the box-alignment words are already the
+reader's, so a shorter name would be a second vocabulary for something they
+can already say, and `align` alone is the word four other families use for
+four other questions: `Dialog` and `Table.Column` mean `text-align` by it.
+
+**It also keeps the name out of the browser's way.** `align` is a legacy
+HTML presentational attribute mapped to `text-align` on any element that
+carries one, this one included: measured, an invented tag with
+`align="center"` computes centered text too, so it is nothing to do with
+being a known element. A row that carried it therefore centered the text
+inside every field in it, through a hint no rule here declares and none can
+see, and the fix is a name the platform has no opinion about rather than a
+guard against the hint. */
+  alignItems?: (HelixFlex["alignItems"]) | undefined;
   /** Whether items run across or down. */
   direction?: (HelixFlex["direction"]) | undefined;
   /** Space between items, named on the space scale. */
   gap?: (HelixFlex["gap"]) | undefined;
   /** Flows with surrounding text instead of taking the full width. */
   inline?: (HelixFlex["inline"]) | undefined;
-  /** Distribution along the direction. */
-  justify?: (HelixFlex["justify"]) | undefined;
+  /** Distribution along the direction, which is `justify-content`.
+
+Named for the property it sets, the way `alignItems` is. `between` and
+`around` drop the `space-` prefix and nothing else does, because those two
+are the only values whose CSS spelling is two words. */
+  "justify-content"?: (HelixFlex["justifyContent"]) | undefined;
+  /** Distribution along the direction, which is `justify-content`.
+
+Named for the property it sets, the way `alignItems` is. `between` and
+`around` drop the `space-` prefix and nothing else does, because those two
+are the only values whose CSS spelling is two words. */
+  justifyContent?: (HelixFlex["justifyContent"]) | undefined;
   /** Whether items wrap onto more lines. */
   wrap?: (HelixFlex["wrap"]) | undefined;
 };
@@ -4467,8 +4572,34 @@ Empty is the runtime's own. */
 export type HelixFormatDateVueEvents = {};
 
 export type HelixGridVueProps = {
-  /** Alignment of each cell within its row. */
-  align?: (HelixGrid["align"]) | undefined;
+  /** Alignment of each cell within its row, which is `align-items`.
+
+**Named for the CSS property it sets**, the way `Flex` is, and the same
+property on a grid: it places every cell in its row's track rather than
+placing the tracks. No `baseline`, which `Flex` offers, because cells in a
+row of a grid are boxes of unrelated content and lining their first lines
+up is a thing a reader asks for between siblings in a row, not between
+cells in a table of them.
+
+There is no `justifyContent` here for the same reason: the tracks are
+`1fr`, so they already fill the row and there is nothing left over to
+distribute. `columns`, `min` and `--grid-columns` are how a grid says how
+wide its tracks are. */
+  "align-items"?: (HelixGrid["alignItems"]) | undefined;
+  /** Alignment of each cell within its row, which is `align-items`.
+
+**Named for the CSS property it sets**, the way `Flex` is, and the same
+property on a grid: it places every cell in its row's track rather than
+placing the tracks. No `baseline`, which `Flex` offers, because cells in a
+row of a grid are boxes of unrelated content and lining their first lines
+up is a thing a reader asks for between siblings in a row, not between
+cells in a table of them.
+
+There is no `justifyContent` here for the same reason: the tracks are
+`1fr`, so they already fill the row and there is nothing left over to
+distribute. `columns`, `min` and `--grid-columns` are how a grid says how
+wide its tracks are. */
+  alignItems?: (HelixGrid["alignItems"]) | undefined;
   /** Fixed number of equal columns. */
   columns?: (HelixGrid["columns"]) | undefined;
   /** Space between cells, named on the space scale. */
@@ -4814,11 +4945,12 @@ export type HelixImageElementEvent<E = Event> = TypedEvent<HelixImage, E>;
 export type HelixImageVueProps = {
   /** Whether the corners are cut.
 
-A boolean rather than a radius, because the radius is a token and the
-question a consumer is answering is whether this picture is a card's
-surface or a page's. `--image-radius` moves it for the case that is
-neither. */
-  rounded?: (HelixImage["rounded"]) | undefined;
+The axis and not a boolean, because `rounded` is a registered word and a
+private spelling of a registry question is what `appearance` was retired
+for. Not a radius either: the radius is a token and the question a consumer
+is answering is whether this picture is a card's surface or a page's.
+`--image-radius` moves it for the case that is neither. */
+  shape?: (HelixImage["shape"]) | undefined;
   /** What it shows, for a reader who cannot see it.
 
 Empty is a real answer and means decoration. Omitting the attribute is not
@@ -5605,7 +5737,7 @@ which React reports as a mismatch and answers by rebuilding the subtree. The
 narrow exception the server specs describe covers a mirror that can only
 become true long after hydration, and a viewport measured before the first
 paint is the opposite case. See `MixinControllerOpen` on `open`. */
-  "full-below"?: (HelixMegamenu["fullBelow"] | `${number}`) | undefined;
+  "band-below"?: (HelixMegamenu["bandBelow"] | `${number}`) | undefined;
   /** The width, in pixels, under which a card becomes a band. Zero never does.
 
 A card is a panel hung off one word, and there is no room to hang anything
@@ -5629,7 +5761,7 @@ which React reports as a mismatch and answers by rebuilding the subtree. The
 narrow exception the server specs describe covers a mirror that can only
 become true long after hydration, and a viewport measured before the first
 paint is the opposite case. See `MixinControllerOpen` on `open`. */
-  fullBelow?: (HelixMegamenu["fullBelow"]) | undefined;
+  bandBelow?: (HelixMegamenu["bandBelow"]) | undefined;
   /** The section's name, which names the default trigger and the panel. */
   label?: (HelixMegamenu["label"]) | undefined;
   /** Whether hovering the trigger opens the panel, or only a press does.
@@ -5649,16 +5781,23 @@ heavy enough that opening it on the way past is rude. */
   /** Whether the panel is a card under the trigger or a band across the page.
 
 The resting one is the card, hanging off the trigger and as wide as it
-needs to be. `full` is the other shape navigations use: a band from edge to
+needs to be. `band` is the other shape navigations use: a run from edge to
 edge under the header, with its contents held to the page's own measure, so
 a set of destinations too wide to sit under one word gets the whole width
 to lay out in.
 
-It changes where the panel goes as well as how it looks, which is why this
-tier knows about it at all: a band spans the viewport, so there is nothing
-to measure it against and nothing to flip or shift to, and the placing pass
-is told not to run. Everything else the popover gives, the top layer and
-the dismissal, is exactly what such a band needs. */
+**A band and not a width, which is why the word is not `full`.** It changes
+where the panel goes as well as how wide it is, which is why this tier
+knows about it at all: a band spans the viewport, so there is nothing to
+measure it against and nothing to flip or shift to, and the placing pass is
+told not to run. Everything else the popover gives, the top layer and the
+dismissal, is exactly what such a band needs. `full` is the registry's word
+for a width, and `Button` and `Dialog` are the two families answering that
+question; borrowing it here would put a third meaning on it.
+
+`variant` and not an axis, for the reason the registry gives: a card under
+a word and a band under a header are two arrangements this family has, and
+no other family is being asked the same question. */
   variant?: (HelixMegamenu["variant"]) | undefined;
 };
 
@@ -6463,6 +6602,13 @@ the name of the tool being run, or the file being read. */
   label?: (HelixOrb["label"]) | undefined;
   /** Diameter relative to the surrounding text.
 
+**`Loader`'s three steps, because the two are swapped for each other.** An
+orb and a spinner are the same job drawn differently, a wait a reader is
+looking at, and a product that replaces one with the other should not find
+that a step it was writing has stopped existing. `md` is the resting one
+and selects nothing, landing on the base rule the way a written resting
+value does everywhere else.
+
 Reflected because the stylesheet selects on it. The mesh is chosen from the
 rendered box rather than from this, so `--orb-size` and a consumer's own
 `inline-size` get the same treatment as the named steps. */
@@ -7146,9 +7292,9 @@ export type HelixRadioVueProps = {
 Unnecessary under `chip`, which has no room for a circle beside its mark
 and hides it already.
 
-`card` only, and it is a graphic that goes rather than a radio: the control
-in the shadow root is untouched, so the row is still focusable, still
-reported to a screen reader, and still the thing a form submits.
+A separated choice only, and it is a graphic that goes rather than a radio:
+the control in the shadow root is untouched, so the row is still focusable,
+still reported to a screen reader, and still the thing a form submits.
 
 Safe because the card already carries the answer in its surface, a raised
 fill inside a primary edge and a three-pixel ring of it. Without that ring
@@ -7163,9 +7309,9 @@ card with no box loses the only thing that says you may pick several. */
 Unnecessary under `chip`, which has no room for a circle beside its mark
 and hides it already.
 
-`card` only, and it is a graphic that goes rather than a radio: the control
-in the shadow root is untouched, so the row is still focusable, still
-reported to a screen reader, and still the thing a form submits.
+A separated choice only, and it is a graphic that goes rather than a radio:
+the control in the shadow root is untouched, so the row is still focusable,
+still reported to a screen reader, and still the thing a form submits.
 
 Safe because the card already carries the answer in its surface, a raised
 fill inside a primary edge and a three-pixel ring of it. Without that ring
@@ -7175,21 +7321,41 @@ Not on `Checkbox`, deliberately. A radio card with no circle is still
 unmistakably one-of-many because its siblings behave that way; a checkbox
 card with no box loses the only thing that says you may pick several. */
   hideControl?: (HelixRadio["hideControl"]) | undefined;
-  /** How the choice presents itself.
+  /** Where the choice's own surface ends.
 
-- `plain` is the default and is never written: a circle beside its words,
-  which is what a list of choices should be almost always.
-- `card` puts it in a bounded surface, for options that need room to
+The question `separation` asks everywhere else, asked of one option, so it
+is that word: what these values pick is a surface, and `plain` is already
+the registry's own word for the answer this family used it for.
+
+- `plain` is the resting one and is never written: a circle beside its
+  words, which is what a list of choices should be almost always.
+- `outlined` puts it in a bounded surface, for options that need room to
   explain themselves: a description, an icon, a price. It is the half a
   `data-card` link cannot do, because a link reports no value and belongs
   to no group, so a card that is genuinely an answer has to be this.
-- `chip` is the answer as its own small surface, for a row of short
-  choices read at a glance. It hides the circle, the surface being the
-  whole mark, which is why `hide-control` says it is unnecessary here.
-
-The circle stays in both. A card whose only marker was its own border would
-ask a reader to compare surfaces across a row to find the answer, and would
-leave nothing for a high-contrast display. */
+- `filled` is that same card on a ground of its own with no edge, which is
+  what a column of choices wants where a hairline around every one of them
+  is a grid of lines rather than a set of answers.
+
+**`elevated` is the one value of the axis this family does not take.** A
+raised choice competes with a dialog: the top layer is where a thing that
+interrupts you lives, and an option in a form is not one of those, so a
+column of lifted cards reads as a stack of floating things none of which is
+settled.
+
+The circle stays in all of them. A card whose only marker was its own
+border would ask a reader to compare surfaces across a row to find the
+answer, and would leave nothing for a high-contrast display. */
+  separation?: (HelixRadio["separation"]) | undefined;
+  /** The answer as its own small surface, for a row of short choices read at a
+glance.
+
+**Not a separation, which is why it is still `variant`.** The other values
+pick where a surface ends around a row that keeps its circle and its words;
+a chip has neither. It hides the circle, the surface being the whole mark,
+which is why `hide-control` says it is unnecessary here, and it takes the
+words out of the flow to be the accessible name. That removes the
+distinction `separation` exists to make rather than answering it. */
   variant?: (HelixRadio["variant"]) | undefined;
   /** Whether this one can be chosen. */
   disabled?: (HelixRadio["disabled"]) | undefined;
@@ -7256,23 +7422,28 @@ export type HelixRatingHelixBeforeChangeElementEvent =
   HelixRatingElementEvent<HelixBeforeChangeEvent>;
 
 export type HelixRatingVueProps = {
-  /** Which mark the row is drawn with.
-
-`marks` is the star, and is what a rating means to most readers. `dots`
-drops the glyph for a plain circle, which says how much rather than how
-good: a star carries a judgment that a level of spice, a difficulty or a
-confidence has not earned.
-
-Both are one shape repeated and clipped to the score, so halves work in
-either, and both are only a choice of drawing. A scale whose marks are
+  /** The geometry one mark is drawn to.
+
+The registry's word, because the question is the registry's: `Avatar`,
+`Skeleton`, `IconButton`, `Meter` and `Progress` each ask what geometry
+their own thing is cut to under this name, and `dots` is already a value
+the axis holds. What is picked here is the outline of one mark and nothing
+else, which is a shape and not a component-specific choice.
+
+`dots` drops the glyph for a plain circle, which says how much rather than
+how good: a star carries a judgment that a level of spice, a difficulty or
+a confidence has not earned. Either way it is one shape repeated and
+clipped to the score, so halves work in both. A scale whose marks are
 *different* drawings is a set of choices rather than a quantity: that is
 `Radio.Group`, whose options already carry a value and a name each.
 
-**Undefaulted, because it reflects.** A default of `marks` writes
-`variant="marks"` onto every server-rendered rating, which React holds no
-prop for and reports as a hydration mismatch. The stylesheet names only
-`dots`, so an unset one draws marks anyway. */
-  variant?: (HelixRating["variant"]) | undefined;
+**The star is the resting one and has no word**, which is the rule every
+axis follows and is also what this family needed anyway: it reflects, so a
+default would write the resting value onto every server-rendered rating,
+an attribute React holds no prop for and so a hydration mismatch for each
+one. The stylesheet names only `dots`, so an unset one draws the star by
+landing on the base rule. */
+  shape?: (HelixRating["shape"]) | undefined;
   /** The value the markup declared, which is where a reset returns to. */
   "default-value"?: (HelixRating["defaultValue"]) | undefined;
   /** The value the markup declared, which is where a reset returns to. */
@@ -7795,11 +7966,11 @@ takes, where a trigger's loudness is its frame rather than its ink.
 `outlined` is what the unset frame already draws, so writing it would be
 writing the resting state out.
 
-**The other three fields want this too and do not have it yet.** `Input`,
-`Textarea` and `Combobox` wear the same frame from the same shared
-stylesheet, and an inline one of each is as reasonable as an inline select.
-They are left alone rather than swept, because each has a different thing
-inside the frame and guessing at three is how an axis ends up meaning four
+**Every field wearing `field-frame.css` wants this too and does not have it
+yet**, which this trigger is not one of: it draws its own frame below. An
+inline number input in a toolbar is as reasonable as an inline select. They
+are left alone rather than swept, because each has a different thing inside
+the frame and guessing at a set of them is how an axis ends up meaning four
 things, which is the fault `appearance` was retired for. */
   emphasis?: (HelixSelect["emphasis"]) | undefined;
   /** Whether the element is open.
@@ -8601,26 +8772,6 @@ export type HelixTableColumnHelixBeforeResizeElementEvent =
   HelixTableColumnElementEvent<HelixBeforeResizeEvent>;
 
 export type HelixTableColumnVueProps = {
-  /** Which edge the values line up against.
-
-`end` is what a column of numbers wants, so digits of the same magnitude
-sit above each other. Left unset the cell inherits the table's own
-alignment, which is `start` for text in either writing direction.
-`DataTable` aligns the cells it draws. A `Table`'s cells are markup the
-consumer wrote, so the table writes nothing onto them: it publishes the
-edge to each cell under this column as `--table-cell-align`, which
-`@fusion.dev/helix` reads. The heading is this element's own, and
-`@fusion.dev/helix` sets it to the same edge in either table. `end` is the
-inline end, so in a right-to-left table it is the left.
-
-**Reflected, because the heading is drawn by a stylesheet and has no other
-way to learn it.** Set as a property, which is how React sets it, an
-unreflected `align` left no attribute to select on, so the heading stayed at
-the start over a column of digits set to the end. It is the author's
-declaration and nothing moves it afterwards, so an attribute cannot come to
-disagree with the element, which is the reason `open` records a custom
-state instead. No default, so an unset column writes nothing onto its host. */
-  align?: (HelixTableColumn["align"]) | undefined;
   /** The key this column reads out of a row.
 
 Dot paths resolve, so `field="owner.name"` reads a nested value: a result
@@ -8655,6 +8806,62 @@ how React sets it, an unreflected `sortable` left no attribute to match.
 `false` reflects as no attribute at all, so an unset column writes nothing
 onto its host. */
   sortable?: (HelixTableColumn["sortable"]) | undefined;
+  /** Which edge the values line up against.
+
+**Text alignment, and the name says so.** `Flex` and `Grid` ask the CSS
+box-alignment question, where a thing sits in a container, and they are
+named for the properties they mirror; this is `text-align` down a column of
+values, and `Dialog` answers the same question under the same name. One
+word for both questions is how a consumer who learned it on a layout writes
+it here and gets no error, a value a component does not have leaving the
+default in place and looking deliberate.
+
+`end` is what a column of numbers wants, so digits of the same magnitude
+sit above each other. Left unset the cell inherits the table's own
+alignment, which is `start` for text in either writing direction.
+`DataTable` aligns the cells it draws. A `Table`'s cells are markup the
+consumer wrote, so the table writes nothing onto them: it publishes the
+edge to each cell under this column as `--table-cell-align`, which
+`@fusion.dev/helix` reads. The heading is this element's own, and
+`@fusion.dev/helix` sets it to the same edge in either table. `end` is the
+inline end, so in a right-to-left table it is the left.
+
+**Reflected, because the heading is drawn by a stylesheet and has no other
+way to learn it.** Set as a property, which is how React sets it, an
+unreflected edge left no attribute to select on, so the heading stayed at
+the start over a column of digits set to the end. It is the author's
+declaration and nothing moves it afterwards, so an attribute cannot come to
+disagree with the element, which is the reason `open` records a custom
+state instead. No default, so an unset column writes nothing onto its host. */
+  "text-align"?: (HelixTableColumn["textAlign"]) | undefined;
+  /** Which edge the values line up against.
+
+**Text alignment, and the name says so.** `Flex` and `Grid` ask the CSS
+box-alignment question, where a thing sits in a container, and they are
+named for the properties they mirror; this is `text-align` down a column of
+values, and `Dialog` answers the same question under the same name. One
+word for both questions is how a consumer who learned it on a layout writes
+it here and gets no error, a value a component does not have leaving the
+default in place and looking deliberate.
+
+`end` is what a column of numbers wants, so digits of the same magnitude
+sit above each other. Left unset the cell inherits the table's own
+alignment, which is `start` for text in either writing direction.
+`DataTable` aligns the cells it draws. A `Table`'s cells are markup the
+consumer wrote, so the table writes nothing onto them: it publishes the
+edge to each cell under this column as `--table-cell-align`, which
+`@fusion.dev/helix` reads. The heading is this element's own, and
+`@fusion.dev/helix` sets it to the same edge in either table. `end` is the
+inline end, so in a right-to-left table it is the left.
+
+**Reflected, because the heading is drawn by a stylesheet and has no other
+way to learn it.** Set as a property, which is how React sets it, an
+unreflected edge left no attribute to select on, so the heading stayed at
+the start over a column of digits set to the end. It is the author's
+declaration and nothing moves it afterwards, so an attribute cannot come to
+disagree with the element, which is the reason `open` records a custom
+state instead. No default, so an unset column writes nothing onto its host. */
+  textAlign?: (HelixTableColumn["textAlign"]) | undefined;
   /** The track this column takes, as CSS.
 
 A single track value, so anything valid in `grid-template-columns` works:
@@ -11152,7 +11359,7 @@ export type CustomCssProperties = {
   "--image-placeholder-color"?: (string) | undefined;
   /** Which part survives a crop. */
   "--image-position"?: (string) | undefined;
-  /** Corner radius, under `rounded`. */
+  /** Corner radius, under `shape="rounded"`. */
   "--image-radius"?: (string) | undefined;
   /** Fill behind the text. */
   "--input-background-color"?: (string) | undefined;
@@ -11370,6 +11577,10 @@ export type CustomCssProperties = {
   "--progress-ring-size"?: (string) | undefined;
   /** Thickness of its stroke. */
   "--progress-ring-width"?: (string) | undefined;
+  /** Thickness of the bar. */
+  "--progress-size"?: (string) | undefined;
+  /** Fill of the part that is not. */
+  "--progress-track-color"?: (string) | undefined;
   /** The value as a fraction of the range, 0 to 1. Pinned to 1 while indeterminate. */
   "--progress-fraction"?: (string) | undefined;
   /** Behind them, including the quiet zone. */