@fusion.dev/helix-headless 0.54.0 → 0.56.0

package/types/vue.d.ts

@@ -536,19 +536,12 @@ is showing a count must not lose the count for being handed one. */
 export type HelixHeadlessBadgeVueEvents = {};
 
 export type HelixHeadlessBarChartVueProps = {
-  /** 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?: (HelixHeadlessBarChart["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
@@ -584,6 +577,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?: (HelixHeadlessBarChart["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?: (HelixHeadlessBarChart["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
@@ -4694,7 +4697,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"?: (HelixHeadlessMegamenu["fullBelow"] | `${number}`) | undefined;
+  "band-below"?: (HelixHeadlessMegamenu["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
@@ -4718,7 +4721,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?: (HelixHeadlessMegamenu["fullBelow"]) | undefined;
+  bandBelow?: (HelixHeadlessMegamenu["bandBelow"]) | undefined;
   /** The section's name, which names the default trigger and the panel. */
   label?: (HelixHeadlessMegamenu["label"]) | undefined;
   /** Whether hovering the trigger opens the panel, or only a press does.
@@ -4738,16 +4741,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?: (HelixHeadlessMegamenu["variant"]) | undefined;
   /** Whether the element is open.
 
@@ -7190,26 +7200,6 @@ export type HelixHeadlessTableColumnHelixBeforeResizeElementEvent =
   HelixHeadlessTableColumnElementEvent<HelixBeforeResizeEvent>;
 
 export type HelixHeadlessTableColumnVueProps = {
-  /** 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?: (HelixHeadlessTableColumn["align"]) | undefined;
   /** The key this column reads out of a row.
 
 Dot paths resolve, so `field="owner.name"` reads a nested value: a result
@@ -7244,6 +7234,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?: (HelixHeadlessTableColumn["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"?: (HelixHeadlessTableColumn["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?: (HelixHeadlessTableColumn["textAlign"]) | undefined;
   /** The track this column takes, as CSS.
 
 A single track value, so anything valid in `grid-template-columns` works:
@@ -9435,7 +9481,7 @@ export interface WcToolkitVueGlobalComponents {
     HelixHeadlessCopyButtonVueProps,
     HelixHeadlessCopyButtonVueEvents
   >;
-  /** **The schema is markup and the data is a property.** Columns are declared as 'TableColumn' children, because a schema is small and something a reader should see in the HTML; rows are handed over as an array, because a table that draws ten thousand elements cannot window them.  '''html <helix-headless-data-table .rows=${rows} sort="name:asc" page-size="20">   <helix-headless-table-column field="name" sortable>Name</helix-headless-table-column>   <helix-headless-table-column field="size" align="end" sortable .cell=${bytes}>Size</helix-headless-table-column> </helix-headless-data-table> '''  'Table' takes rows as markup and is the right component for a table of twelve things a person wrote out.  **Sort and filter apply to the whole set, never the page.** Sorting the drawn window is correct on the first screen and wrong on every other one.  **The cell values do not server-render.** The headings do, and the row elements do, but reading a cell needs the columns, and the columns are markup children Lit SSR does not hand this element. So a crawler sees a table of the right shape with nothing in it. That is the cost of the first paragraph: use 'Table' where the served HTML has to carry the values.  **'selectable' adds a column of checkboxes, keyed on 'row-key'.** A row is selected by its identity rather than its position, so a selection survives a sort, a filter and a page. 'selected' is the chosen keys, comma separated, the shape Listbox uses for a multiple choice, and like 'sort' writing it applies while 'default-selected' is what the markup declared. The box in the heading selects every row in the result, across pages, and shows a dash while only some are chosen. Choosing one of many, rather than several, is opening a row, and that is a link or a button in a cell rather than a selection.  **A reader can size and order the columns.** 'resizable' on a column puts a separator on its edge; 'reorderable' on the table puts a grip on each heading that has a 'field', moved by dragging or with the arrow keys. The order lands in 'order' as fields, and the consumer's own markup is never rewritten: the table assigns the headings to its header in that order instead.  **'csv()' hands back the result as text**: every row the filter lets through, in the order on screen, in the columns on screen. Saving it is the page's business, the same as any other file.  **There is no 'columns' attribute here, and Table has one.** The difference is what a column is in each: here it is the schema, so a table without one has nothing to read a row with, and every column is a place to write a 'width'. A Table holds cells a consumer wrote and can be written with no column at all, so its 'columns' is where such a table is sized from. Written on this element the attribute is inert, which is the trap worth knowing when moving between the two. */
+  /** **The schema is markup and the data is a property.** Columns are declared as 'TableColumn' children, because a schema is small and something a reader should see in the HTML; rows are handed over as an array, because a table that draws ten thousand elements cannot window them.  '''html <helix-headless-data-table .rows=${rows} sort="name:asc" page-size="20">   <helix-headless-table-column field="name" sortable>Name</helix-headless-table-column>   <helix-headless-table-column field="size" text-align="end" sortable .cell=${bytes}>Size</helix-headless-table-column> </helix-headless-data-table> '''  'Table' takes rows as markup and is the right component for a table of twelve things a person wrote out.  **Sort and filter apply to the whole set, never the page.** Sorting the drawn window is correct on the first screen and wrong on every other one.  **The cell values do not server-render.** The headings do, and the row elements do, but reading a cell needs the columns, and the columns are markup children Lit SSR does not hand this element. So a crawler sees a table of the right shape with nothing in it. That is the cost of the first paragraph: use 'Table' where the served HTML has to carry the values.  **'selectable' adds a column of checkboxes, keyed on 'row-key'.** A row is selected by its identity rather than its position, so a selection survives a sort, a filter and a page. 'selected' is the chosen keys, comma separated, the shape Listbox uses for a multiple choice, and like 'sort' writing it applies while 'default-selected' is what the markup declared. The box in the heading selects every row in the result, across pages, and shows a dash while only some are chosen. Choosing one of many, rather than several, is opening a row, and that is a link or a button in a cell rather than a selection.  **A reader can size and order the columns.** 'resizable' on a column puts a separator on its edge; 'reorderable' on the table puts a grip on each heading that has a 'field', moved by dragging or with the arrow keys. The order lands in 'order' as fields, and the consumer's own markup is never rewritten: the table assigns the headings to its header in that order instead.  **'csv()' hands back the result as text**: every row the filter lets through, in the order on screen, in the columns on screen. Saving it is the page's business, the same as any other file.  **There is no 'columns' attribute here, and Table has one.** The difference is what a column is in each: here it is the schema, so a table without one has nothing to read a row with, and every column is a place to write a 'width'. A Table holds cells a consumer wrote and can be written with no column at all, so its 'columns' is where such a table is sized from. Written on this element the attribute is inert, which is the trap worth knowing when moving between the two. */
   "helix-headless-data-table": DefineCustomElement<
     HelixHeadlessDataTable,
     HelixHeadlessDataTableVueProps,
@@ -9861,7 +9907,7 @@ export interface WcToolkitVueGlobalComponents {
     HelixHeadlessTableCellVueProps,
     HelixHeadlessTableCellVueEvents
   >;
-  /** **The column is the source of both its heading and its track.** Add one and the table has another track; remove one and it does not. That is what ties the two together, and a table-level track list on its own does not: a list that is accidentally the headings is invalid CSS a grid ignores in silence, drawing the whole table as one column. 'Table''s 'columns' is dealt out a track at a time against the columns declared under it, so a heading among the widths costs its own column a width and no more, and a list longer or shorter than the columns is trimmed or shared rather than being a second count of them. A column's own 'width' wins over the track in its place.  **It is also where every per-column fact goes**, which is the reason 'DataTable' needs no column config object. 'field' names the key the cell reads, 'sortable' says a reader may reorder by it, 'align' says which edge the values line up against, and 'cell' takes a function for anything the field alone cannot express. The schema is markup and the data is a property: a schema is small, declarative, and something a reader should be able to see in the HTML, and data is large and windowed.  **The same element serves both tables**, the markup one and the data one. It is identified by a flag rather than by 'instanceof', so a 'TableColumn' works inside either without the two roots sharing anything else.  **It generates no box of its own**, the same as a row: the heading is a grid item of the table, so it lines up with the cells under it rather than sitting in a wrapper that has to be kept the same width.  **'hidden' takes the column out of the grid**, its heading and its track both, so the columns after it keep their own widths and every row keeps its cells under their headings. 'hidden="until-found"' keeps its track, the heading being left drawn, as every Helix element leaves one with that value. 'DataTable' draws the cells, so it leaves out the ones under a hidden column. A 'Table''s cells are markup the consumer wrote, so hide them with the column, as removing a column means removing its cells: a row with a cell more than the table has tracks wraps into the next.  **A heading that does something holds a control that does it.** The host is the column header, and a header is not focusable, so a sortable heading is a '<button>' inside it: the pattern for a sortable table, and the only way a reader on a keyboard reaches the sort at all. A column a reader may resize carries a 'separator' on its end edge, moved by dragging it or with the arrow keys, and a column in a table that lets a reader reorder its columns carries a grip the table moves. */
+  /** **The column is the source of both its heading and its track.** Add one and the table has another track; remove one and it does not. That is what ties the two together, and a table-level track list on its own does not: a list that is accidentally the headings is invalid CSS a grid ignores in silence, drawing the whole table as one column. 'Table''s 'columns' is dealt out a track at a time against the columns declared under it, so a heading among the widths costs its own column a width and no more, and a list longer or shorter than the columns is trimmed or shared rather than being a second count of them. A column's own 'width' wins over the track in its place.  **It is also where every per-column fact goes**, which is the reason 'DataTable' needs no column config object. 'field' names the key the cell reads, 'sortable' says a reader may reorder by it, 'text-align' says which edge the values line up against, and 'cell' takes a function for anything the field alone cannot express. The schema is markup and the data is a property: a schema is small, declarative, and something a reader should be able to see in the HTML, and data is large and windowed.  **The same element serves both tables**, the markup one and the data one. It is identified by a flag rather than by 'instanceof', so a 'TableColumn' works inside either without the two roots sharing anything else.  **It generates no box of its own**, the same as a row: the heading is a grid item of the table, so it lines up with the cells under it rather than sitting in a wrapper that has to be kept the same width.  **'hidden' takes the column out of the grid**, its heading and its track both, so the columns after it keep their own widths and every row keeps its cells under their headings. 'hidden="until-found"' keeps its track, the heading being left drawn, as every Helix element leaves one with that value. 'DataTable' draws the cells, so it leaves out the ones under a hidden column. A 'Table''s cells are markup the consumer wrote, so hide them with the column, as removing a column means removing its cells: a row with a cell more than the table has tracks wraps into the next.  **A heading that does something holds a control that does it.** The host is the column header, and a header is not focusable, so a sortable heading is a '<button>' inside it: the pattern for a sortable table, and the only way a reader on a keyboard reaches the sort at all. A column a reader may resize carries a 'separator' on its end edge, moved by dragging it or with the arrow keys, and a column in a table that lets a reader reorder its columns carries a grip the table moves. */
   "helix-headless-table-column": DefineCustomElement<
     HelixHeadlessTableColumn,
     HelixHeadlessTableColumnVueProps,