@fusion.dev/helix-headless 0.46.1 → 0.47.1

package/types/vue.d.ts

@@ -985,6 +985,27 @@ clamps to the last *slide*, so three of the six indicators point at an
 offset the track has already reached: pressing next walks the dots to the
 end while the slides stop moving a third of the way through.
 
+**The number is published to the styles rather than enumerated by them**,
+as `--carousel-per-view` on the track, which is what keeps a width and a
+count from disagreeing. A sheet can only name a value it wrote a rule for,
+so the styled tier enumerated `per-view="2"` through `5` and called five a
+judgment; above it the pane fell back to one across while this file went on
+counting positions. Measured in Chromium over eight slides, six across gave
+three dots, a pane taking the whole track and five slides reachable only by
+dragging. Written from here there is no ceiling to exceed, and a consumer's
+own sheet reads the same declaration the styled one does. `runEnd` publishes
+its correction the same way and for the same reason.
+
+**On the track and not on the host.** A custom property on the host is a
+reflected attribute by another name: it would arrive on upgrade, and a
+consumer's server markup never had it. Inside the component's own shadow
+root it serializes with the rest of the template on the server, and the
+track's own declaration beats anything a consumer inherits in, so the
+attribute is the one answer to how wide a pane is.
+
+A value the track cannot honor is taken to the nearest one it can, by
+`across`, and both tiers read that rather than this.
+
 No default, because it reflects. A reflected property with a value writes
 its attribute on upgrade, and the host then carries something a consumer's
 server markup never had, which React reports as a mismatch. The one-across
@@ -1001,6 +1022,27 @@ clamps to the last *slide*, so three of the six indicators point at an
 offset the track has already reached: pressing next walks the dots to the
 end while the slides stop moving a third of the way through.
 
+**The number is published to the styles rather than enumerated by them**,
+as `--carousel-per-view` on the track, which is what keeps a width and a
+count from disagreeing. A sheet can only name a value it wrote a rule for,
+so the styled tier enumerated `per-view="2"` through `5` and called five a
+judgment; above it the pane fell back to one across while this file went on
+counting positions. Measured in Chromium over eight slides, six across gave
+three dots, a pane taking the whole track and five slides reachable only by
+dragging. Written from here there is no ceiling to exceed, and a consumer's
+own sheet reads the same declaration the styled one does. `runEnd` publishes
+its correction the same way and for the same reason.
+
+**On the track and not on the host.** A custom property on the host is a
+reflected attribute by another name: it would arrive on upgrade, and a
+consumer's server markup never had it. Inside the component's own shadow
+root it serializes with the rest of the template on the server, and the
+track's own declaration beats anything a consumer inherits in, so the
+attribute is the one answer to how wide a pane is.
+
+A value the track cannot honor is taken to the nearest one it can, by
+`across`, and both tiers read that rather than this.
+
 No default, because it reflects. A reflected property with a value writes
 its attribute on upgrade, and the host then carries something a consumer's
 server markup never had, which React reports as a mismatch. The one-across
@@ -7083,7 +7125,20 @@ on the column it sizes, which is the more particular statement, and it is
 where a resize lands: a reader dragging a column's edge writes `width`, so
 were this list to win, the drag would move the separator and leave the
 track where the list put it. This is the table's default for its columns,
-and each column may say otherwise. */
+and each column may say otherwise.
+
+**It is also the only track list a server can send.** The shim has no tree
+to walk, so a render there knows of no columns and this attribute is the
+whole answer: a table given one lays its grid out in the first paint, and a
+table sized only by its columns is one track wide until it upgrades.
+
+**`helix-data-table` has none of this, and should not.** Its columns are
+its schema rather than an option, so there is always a column to write a
+`width` on and a list here would be a second way to say what that says.
+This table's cells are markup, and a table written as rows of cells with no
+`helix-table-column` in it has nowhere else to be sized from. Both families
+take the same CSS hook, `--table-columns` and `--data-table-columns`, which
+wins over whichever list the element worked out. */
   columns?: (HelixHeadlessTable["columns"]) | undefined;
   /** Accessible name for the table. */
   label?: (HelixHeadlessTable["label"]) | undefined;
@@ -8316,13 +8371,6 @@ Unset by default, and unreflected: a tree of choosable nodes is not a tree
 of links, and an empty `href` written onto every row would be a link to the
 current page on every item a consumer never asked to be one. */
   href?: (HelixHeadlessTreeItem["href"]) | undefined;
-  /** Depth from the root, set by the tree so indentation needs no CSS nesting.
-
-Not reflected. The tree assigns this after it upgrades, so an attribute
-here would be a change to markup the consumer rendered and hydration would
-report it. The indent it drives is written onto the row instead, inside the
-shadow root, which is not part of the tree React hydrates. */
-  level?: (HelixHeadlessTreeItem["level"]) | undefined;
   /** What the link declares about where it goes.
 
 Set by the consumer rather than derived from `target`: `noreferrer` is a
@@ -8332,7 +8380,7 @@ this library supports implies it for `target="_blank"` already. */
   rel?: (HelixHeadlessTreeItem["rel"]) | undefined;
   /** Whether this item is the current one.
 
-Not reflected, for the reason `level` below gives in full: the tree assigns
+Not reflected, for the reason `level` above gives in full: the tree assigns
 this after it upgrades, so the attribute would be a change to markup the
 consumer rendered and hydration would report it. Mirroring to
 `data-selected` on the host instead is the same fault under another name.
@@ -8361,6 +8409,24 @@ the resolved state for stylesheets, which is what the mirror is for. */
   "default-open"?: (HelixHeadlessTreeItem["defaultOpen"]) | undefined;
   /** Initial open state for uncontrolled use, where nothing declared one. */
   defaultOpen?: (HelixHeadlessTreeItem["defaultOpen"]) | undefined;
+  /** Depth from the root, counted by the tree so indentation needs no CSS nesting.
+
+**Read rather than written, and no attribute at all.** The tree counts the
+items a row sits inside and assigns this on every sync, so a value declared
+here is overwritten before the first paint: measured at `level="2"` on three
+rows of a flat list, all three back to 1 with `--tree-level: 1` on every
+row. It carried an attribute and a shipped example setting it for as long as
+both existed, which is a depth a consumer could state and nothing would
+honor. Depth in this tree is where a row is, not what it claims: a branch's
+children go in its `children` slot, and that nesting is also what decides
+which rows a shut branch hides and which row the outward arrow moves to.
+
+Not reflected either. The tree assigns this after it upgrades, so an
+attribute here would be a change to markup the consumer rendered and
+hydration would report it. The indent it drives is written onto the row
+instead, inside the shadow root, which is not part of the tree React
+hydrates. */
+  level?: (HelixHeadlessTreeItem["level"]) | undefined;
   /** Whether this item holds the tree's single tab stop. */
   focusable?: (HelixHeadlessTreeItem["focusable"]) | undefined;
 };
@@ -8890,6 +8956,8 @@ export type CustomCssProperties = {
   "--carousel-gap"?: (string) | undefined;
   /** The size one pane is laid out at. A sheet sets it and the component measures the run with it. */
   "--carousel-pane"?: (string) | undefined;
+  /** How many slides go across, written onto the track by the component so a sheet divides the track by the same number the positions are counted from. Read it rather than selecting on `per-view`, which cannot be enumerated without a ceiling. See `perView`. */
+  "--carousel-per-view"?: (string) | undefined;
   /** How far short of a whole pixel the run ends, on the last slide alone, for a sheet to take up as `margin-inline-end`. See `runEnd`. */
   "--carousel-run-end"?: (string) | undefined;
   /** The chosen color, to paint over the transparency check. */
@@ -8994,8 +9062,6 @@ export type CustomCssProperties = {
   "--splitter-position"?: (string) | undefined;
   /** The edge the column this cell sits under is set to, `start`, `center` or `end`, and unset under a column that sets none. Written by the table around it, since the cell is the consumer's markup and nothing is written onto it; read by the sheet that draws the cell, where `justify-content` and `text-align` both take it as it comes and both follow the writing direction. */
   "--table-cell-align"?: (string) | undefined;
-  /** Track list for the columns. */
-  "--table-columns"?: (string) | undefined;
   /** The column track list this element worked out from the columns declared in it. Written by the component, read by the sheet that paints: a stylesheet takes it to lay the grid out, and setting it does nothing, because the component writes it inline on the very element that reads it and an inline declaration beats any sheet. `--table-columns` is the one to set. */
   "--table-template"?: (string) | undefined;
   /** How long this message stays, in milliseconds, for a progress hint. */
@@ -9188,7 +9254,7 @@ export interface WcToolkitVueGlobalComponents {
     HelixHeadlessCopyButtonVueProps,
     HelixHeadlessCopyButtonVueEvents
   >;
-  /** **The schema is markup and the data is a property.** Columns are declared as 'helix-table-column' 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-data-table .rows=${rows} sort="name:asc" page-size="20">   <helix-table-column field="name" sortable>Name</helix-table-column>   <helix-table-column field="size" align="end" sortable .cell=${bytes}>Size</helix-table-column> </helix-data-table> '''  'helix-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 'helix-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' it is controlled when set and seeded by 'default-selected'. 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. */
+  /** **The schema is markup and the data is a property.** Columns are declared as 'helix-table-column' 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-data-table .rows=${rows} sort="name:asc" page-size="20">   <helix-table-column field="name" sortable>Name</helix-table-column>   <helix-table-column field="size" align="end" sortable .cell=${bytes}>Size</helix-table-column> </helix-data-table> '''  'helix-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 'helix-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' it is controlled when set and seeded by 'default-selected'. 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 'helix-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 'helix-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. What both take is the CSS hook, '--data-table-columns' here and '--table-columns' there. */
   "helix-headless-data-table": DefineCustomElement<
     HelixHeadlessDataTable,
     HelixHeadlessDataTableVueProps,
@@ -9614,7 +9680,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. Declaring the widths separately, as a CSS track list on the table, leaves nothing tying the two together: a table with three headings and a two-track list renders without complaint, and a track list that is accidentally the headings is invalid CSS the grid silently ignores, collapsing the whole table into one column.  **It is also where every per-column fact goes**, which is the reason 'helix-data-table' 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 'helix-table-column' 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. 'helix-data-table' draws the cells, so it leaves out the ones under a hidden column. A 'helix-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. 'helix-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 'helix-data-table' 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 'helix-table-column' 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. 'helix-data-table' draws the cells, so it leaves out the ones under a hidden column. A 'helix-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,