@loadbare/app 0.8.2 → 0.10.0

package/docs/TECHREF-1.0.md

@@ -19,7 +19,8 @@ Loadbare/app enforces no data types on values between the database and the
 browser.  A uniform and useful approach is difficult to discern, and we do
 not want to pollute 1.0 with a potentially sub-optimal solution.  Until then
 a value is rendered by browser coercion when it lands on an HTML text
-element, or by whatever the widget does when it lands on a widget.
+element or a control, and by whatever the custom element does with
+`lb-column-value` when it lands on one that is not a control.
 
 We will then see if a useful solution emerges that Loadbare/app should
 handle.
@@ -27,24 +28,21 @@ handle.
 ### Form controls
 
 - **Checkboxes and radio buttons are not implemented.** A value does not
-  land on one and a form does not gather one.  Landing needs a decision on
+  land on one and the hub does not gather one.  Landing needs a decision on
   what counts as checked, which waits on [Data types](#data-types), and a
-  radio group is several elements answering to one cell.
+  radio group is several elements answering to one column.
 
-### Run-time state attributes
+### Run-time stamps
 
-The hub stamps `lb-row-count`, `lb-pending` and `lb-error` for a
-stylesheet to read.  Their consumer is CSS rather than code.
+The hub stamps `lb-query-row-count`, `lb-request-pending` and
+`lb-request-error` for a stylesheet to read.  Their consumer is CSS rather
+than code.
 
-- **Decide `data-` against `lb-`.** These are the only names the hub writes
-  outside its own namespace, which is either a deliberate signal that CSS
-  owns them or an inconsistency.
-- **Say what `lb-row-count` holds.** It is stamped and never explained.
-- **Decide whether an unarrived value needs a signal.** The roadmap proposes
-  deriving it from an absent `lb-value`.  Recommend confirming that and
-  adding nothing.
+- **Decide whether an unarrived value needs a signal.** An element whose
+  column has not landed carries no `lb-column-value`.  Recommend confirming
+  that as the signal and adding nothing.
 
-### The widget protocol
+### Custom element hooks
 
 Loadbare/app owns every method name beginning with `lb` on a custom element.
 That decision is firm; what the set contains is not.
@@ -52,45 +50,43 @@ That decision is firm; what the set contains is not.
 - **Decide what the build does with an unknown `lb*` method.** An element
   carrying a method beginning with `lb` that Loadbare/app does not define may
   be an error, a warning, or ignored.
-- **Decide whether a widget may receive a whole row.** A cell lands one
-  element at a time and offers no escape hatch.  An optional `lbAcceptRow`
-  would sit beside `lbPlaceRow` and `lbRowsLanded`, and this is the most
-  likely first request from a widget author.
+- **Decide whether a custom element may receive a whole row.** A column
+  lands one element at a time and offers no escape hatch.  An optional
+  `lbAcceptRow` would sit beside `lbPlaceRow` and `lbRowsLanded`, and this is
+  the most likely first request from a custom element author.
 
-### Lists
+### Nested queries
 
-Imagine we have an HTML `<select>` that displays a fixed list for all
-rows in a table, such as `customer_type` for a table of customers.  When
-all customers can be any customer type, our system as written today
-is fine, because all HTML `<select>` elements get the same list.
+Imagine an HTML `<select>` that shows a fixed set of choices on every row of
+a table, such as `customer_type` for a table of customers.  When every
+customer may take every customer type, the system as written today is
+fine, because every `<select>` receives the same rows.
 
-But it may be that the list of allowed values is dependent on other values
-in the row.   
+But the allowed values may depend on other values in the row.
 
-
-- **Decide how a new row fills a nested list.** A row added to the outer
-  list starts with an empty nested list, which fills only when the nested
-  list's name lands again.  See [Master-detail](#master-detail) for what a
-  nested list is for.
+- **Decide how a new live row fills a nested query.** A row added to the
+  outer query starts with its nested query empty, and it fills only when the
+  nested query's name lands again.  See [Master-detail](#master-detail) for
+  what a nested query is for.
 
 ```html
-<tbody lb-list="accounts">
-  <template lb-key="id"><tr>
-    <td lb-cell="name"></td>
-    <td><select lb-list="statuses"><template lb-key="id"><option lb-cell="label"></option></template></select></td>
+<tbody lb-query="accounts">
+  <template><tr>
+    <td lb-column="name"></td>
+    <td><select lb-query="statuses" lb-column="status"><template><option lb-column="label"></option></template></select></td>
   </tr></template>
 </tbody>
 ```
 
 ### The server API
 
-- **Give the chrome a way to state its own queries.** A widget in the chrome
-  bound to a query forces every page to declare that query, since the page
-  data run covers one page's set.  `lb-navigation` shows the pattern from the
+- **Give the chrome a way to state its own queries.** A custom element in
+  the chrome naming a query forces every page to declare that query, since
+  the page load covers one page's set.  `lb-url` shows the pattern from the
   framework side, and an application has no equivalent.  Recommend a
   chrome-level query set on `createHub`.
-- **State that only `createHub` implements `Hub`.** Otherwise a sixth
-  operation breaks anyone who wrote the interface by hand.
+- **State that only `createHub` implements `Hub`.** Otherwise a third call
+  breaks anyone who wrote the interface by hand.
 - **Decide the options-argument shape once.** Global hooks, transaction
   wrapping, error handling and a CSRF token all want the same trailing
   parameter on `createHub` and `hubRoutes`.  Build none of them, but pick
@@ -110,9 +106,9 @@ in the row.
   definition would let the builder ship only what survives expansion.
   Recommend deferring the mechanism and reserving the configuration key, so
   that it lands as an opt-in rather than as a silent drop.
-- **Land the remaining validations.** One `lb-hub`, one empty `<main>`, and
-  every `lb-` attribute known.  Recommend landing these now, because refusing
-  markup that used to build is the kind of change 1.0 gives up.
+- **Land the remaining validations.** One `lb-hub` and one empty `<main>`.
+  Recommend landing these now, because refusing markup that used to build is
+  the kind of change 1.0 gives up.
 - **Confirm the three output names.** `app.html`, `client.js` and `app.css`
   are about to be fixed in `staticRoutes` as well as in the builder.
 
@@ -162,12 +158,12 @@ The builder bundles `client.js` from a `client-entry.ts` it generates into
 `--out` and leaves there.  Nothing reads it after the bundle, and an
 application neither writes nor imports it.
 
-Every `.css` file in every origin joins `app.css`.  There is no widget, page
+Every `.css` file in every origin joins `app.css`.  There is no custom element, page
 or chrome stylesheet: the builder concatenates them all, with nothing added,
 removed or scoped, so what ships is what was authored.  Within one origin
 they are ordered by filename, the full path breaking a tie, and a
 subdirectory never affects the order.  Origins follow the cascade — this
-package's own widgets, then each package named in `imports.ts`, then `--src`
+package's own custom elements, then each package named in `imports.ts`, then `--src`
 last — so an application's own stylesheet always lands after the ones it
 imported.  A file named `00-global.css` sorts first by saying so.
 
@@ -210,71 +206,78 @@ the whole of `--src` is one flat namespace, as stated in
 
 Three kinds of file hold HTML.
 
-| File               | Holds                                | Found in     |
-| ------------------ | ------------------------------------ | ------------ |
-| `chrome.html`      | The one HTML document                | `--src`      |
-| `<stub>.page.html` | One page's markup, as a fragment     | `--src`      |
-| `<tag-name>.html`  | One widget definition, as a fragment | Every origin |
+| File               | Holds                                     | Found in     |
+| ------------------ | ----------------------------------------- | ------------ |
+| `chrome.html`      | The one HTML document                     | `--src`      |
+| `<stub>.page.html` | One page's markup, as a fragment          | `--src`      |
+| `<tag-name>.html`  | One custom element's markup, as a fragment | Every origin |
 
 As stated in [Chrome](#chrome), `chrome.html` is a required singleton. 
 
 As stated in [Pages](#pages), the `<stub>` of a `.page.html` is the path the
 page maps to.  The builder puts all pages into `dist/app.html` as HTML `<template>` objects
-that carry `lb-page="<stub>"`.
+that carry `lb-page="<stub>"`, and `lb-page-title` when the page file has a
+`<title>`.
 
-A widget file is exactly `<kebab-case-name>.html`. A [widget](#widgets) is 
-an HTML custom element, suitable for organizing large HTML trees, or adding
-custom behavior, or both.  A widget definition is named for the tag it expands.
+An element file is exactly `<kebab-case-name>.html`. A
+[custom element](#custom-elements) is suitable for organizing large HTML
+trees, or adding custom behavior, or both.  An element file is named for the
+tag it expands.
 
 Any other HTML file, one that is not `chrome.html`, or `<stub>.page.html` or
 `<kebab-case-name>.html` will either:
-- be an error if it looks like a widget with capitalization
+- be an error if it looks like an element file with capitalization
 - be skipped
 
+
 ## HTML
 
 In a Loadbare/app application, HTML is static after the build, and once
 it is sent to the browser on initial page load, no HTML is ever sent
 again.
 
-### Widget Expansion
+The developer writes `lb-*` attributes in markup.  Script never assigns
+them.  The hub and the builder write only their stamps.  See
+[The markup checks](#the-markup-checks).
+
+### Expansion
 
 The builder executes a process we call "expansion".  When it finds
 a custom element in the HTML it is processing, such as `<my-element>`,
-it looks for the file `<my-element>.html`, and follows the expansion
-rules to place the contents of `<my-element>.html`.
+it looks for the element file `my-element.html`, and follows the expansion
+rules to place its contents.
 
-A custom element with no definition file is left alone.  A custom element
-with neither a definition nor a `.browser.ts` script is a build error, as
-stated in [Widgets](#widgets).
+A custom element with no element file is left alone.  A custom element
+with neither an element file nor a `.browser.ts` script is a build error, as
+stated in [Custom elements](#custom-elements).
 
 #### Build time parameters
 
 A build time parameter is supplied as an attribute on a custom element,
 and is converted to a fixed value within the HTML by the builder.
 
-The attribute value carries an `exp-` prefix, as in `exp-label`, and
-the substitution locations use `{{label}}` (no exp-prefix) inside the
-widget's HTML definition file:
+The attribute name carries an `exp-` prefix, as in `exp-label`, and
+the substitution locations use `{{label}}` (no prefix) inside the
+element file:
 
 ```html
-<!-- lb-input.html, the definition -->
+<!-- note-field.html, the element file -->
 <label>{{label}} <input readonly="{{readonly}}" /></label>
 ```
 
 ```html
 <!-- a page -->
-<lb-input lb-cell="name" exp-label="Name"></lb-input>
+<note-field exp-label="Name"></note-field>
 ```
 
 ```html
 <!-- dist/app.html -->
-<lb-input lb-cell="name" exp-label="Name"
+<note-field exp-label="Name"
   ><label>Name <input /></label
-></lb-input>
+></note-field>
 ```
 
-A definition states a default with `{{name|default}}`, as in
+An element file states a default with `{{name|default}}`, as in
 `{{button-label|OK}}`.  Whitespace around the name and around the default is
 discarded.  The default is a literal.
 
@@ -297,48 +300,61 @@ A parameter value cannot become markup.
 
 #### Slots and templates
 
-A widget definition may contain any number of named templates and optionally
+An element file may contain any number of named templates and optionally
 one slot.
 
-This simplified definition of `lb-table` names two templates, `head` and
+| Attribute         | The builder                                             |
+| ----------------- | ------------------------------------------------------- |
+| `lb-exp-slot`     | Puts in it the rest of the custom element's content     |
+| `lb-exp-template` | Puts in it the content of the template of the same name |
+| `exp-<name>`      | Replaces `{{name}}` in the element file with its value  |
+
+- `lb-exp-slot` goes on one element in an element file.
+- `lb-exp-template` goes on an element in an element file, and on a
+  `<template>` in the custom element's content.  Both name the same
+  template.
+- `exp-<name>` goes on a custom element.
+
+This simplified element file for `lb-table` names two templates, `head` and
 `foot`, and marks `<tbody>` as the slot.  A page supplies whichever templates
 it wants, and everything else it writes goes to the slot.
 
 ```html
-<!-- lb-table.html, the definition -->
+<!-- lb-table.html, the element file -->
 <table>
   <caption>
     {{caption}}
   </caption>
-  <thead lb-template="head"></thead>
-  <tbody lb-slot></tbody>
-  <tfoot lb-template="foot"></tfoot>
+  <thead lb-exp-template="head"></thead>
+  <tbody lb-exp-slot></tbody>
+  <tfoot lb-exp-template="foot"></tfoot>
 </table>
 ```
 
-When we use `lb-table` in HTML, the example below supplies the header
-template and an unnamed template.  The unnamed one names neither `head` nor
-`foot`, so it goes to the slot.  This usage writes no footer.
+The page below supplies the `head` template and a row template.  The row
+template names no destination, so it goes to the slot.  This page writes no
+footer.
 
 ```html
 <!-- a page -->
-<lb-table lb-list="staff" exp-caption="Everyone, by team">
-  <template lb-template="head">
+<lb-table lb-query="staff" exp-caption="Everyone, by team">
+  <template lb-exp-template="head">
     <tr><th>Name</th><th>Role</th></tr>
   </template>
-  <template lb-key="id">
-    <tr><td lb-cell="name"></td><td lb-cell="role"></td></tr>
+  <template>
+    <tr><td lb-column="name"></td><td lb-column="role"></td></tr>
   </template>
 </lb-table>
 ```
 
 When a named template is expanded, the `<template>` tag is discarded and its
-contents are placed as children of the tag that names it.  The built document
-holds:
+contents are placed as children of the element that names it.  Both
+`lb-exp-slot` and `lb-exp-template` are gone from what ships.  The built
+document holds:
 
 ```html
 <!-- dist/app.html -->
-<lb-table lb-list="staff" exp-caption="Everyone, by team"
+<lb-table lb-query="staff" exp-caption="Everyone, by team"
   ><table>
     <caption>
       Everyone, by team
@@ -350,10 +366,10 @@ holds:
       </tr>
     </thead>
     <tbody>
-      <template lb-key="id">
+      <template>
         <tr>
-          <td lb-cell="name"></td>
-          <td lb-cell="role"></td>
+          <td lb-column="name"></td>
+          <td lb-column="role"></td>
         </tr>
       </template>
     </tbody>
@@ -363,75 +379,147 @@ holds:
 
 These are build errors:
 
-- A definition with two templates of one name
-- A definition with more than one `lb-slot`
-- A page naming a template the definition does not have
+- An element file with two destinations of one name
+- An element file with more than one `lb-exp-slot`
+- A page naming a template the element file does not have
 - A page giving two templates for one name
-- Content written in a widget whose definition has no slot
+- Content written in a custom element whose element file has no slot
 
-### Binding
+### Names
 
-Binding attributes determine how the hub updates the DOM, either by
-directly updating a plain HTML element or instructing 
-custom widgets to update themselves.
+Loadbare owns the `lb-` prefix in several namespaces: attribute names, the
+values of its attributes, query names, the column names of its own queries,
+request names, custom element names and custom event names.  It also owns
+custom element method names beginning with `lb`.
 
+The application should never name anything with the `lb-` prefix anywhere.
 
-| Attribute    | Assigned By | Behavior                                                                                        |
-| ------------ | ----------- | ----------------------------------------------------------------------------------------------- |
-| lb-list      | Developer   | Scopes DOM children to a named set of rows; a nested lb-list or lb-row begins a new scope       |
-| lb-row       | Developer   | Scopes DOM children to one named row; a nested lb-list or lb-row begins a new scope             |
-| lb-cell      | Developer   | This DOM node displays this column of the row in scope                                          |
-| lb-show      | Developer   | This DOM node is present when this column of the row in scope is neither null nor false         |
-| lb-key       | Developer   | Names the column that identifies a row, on the row template inside an lb-list                   |
-| lb-key-value | Hub         | Stamped on a live row: that row's value of `lb-key`                                             |
-| lb-value     | Hub         | The value that landed on a cell; a widget updates itself from it and a stylesheet selects on it |
+`createHub` refuses, at startup, a page that declares a query or a handler
+whose name begins with `lb-`.
 
-#### How a value lands
+### Landing
 
-A cell lands one of three ways, and the element decides which.  Every cell
-that receives a value also carries it as `lb-value`.
+A query is a name for rows, of kind `row` or `rows`, with a key.  The server
+declares a page's queries in `<stub>.queries.ts`, and answers every request,
+a page load included, with response items.  A response item carries a query
+name, its kind, its key's column name, and one of a row, all rows, or a
+patch.  See [The wire](#the-wire).
 
-| Element                                | Receives the value as             |
-| -------------------------------------- | --------------------------------- |
-| A custom element, tag hyphenated       | Its `lb-value` attribute          |
-| `<select>`, `<textarea>`, or `<input>` | Its `value`, and `lb-value`       |
-| Any other native element               | Its `textContent`, and `lb-value` |
+The hub lands a response item on every element whose `lb-query` names its
+query.
 
-A widget owns whatever control it wraps, so it is handed the value and
-renders it itself.  A form control shows its state as its `value`, so a
-`<select>` keeps its options.  Any other native element has no behavior of its
-own, so its value is its text.
+| Attribute   | Names    | The hub                                            |
+| ----------- | -------- | -------------------------------------------------- |
+| `lb-query`  | a query  | Puts its rows in the element's content             |
+| `lb-column` | a column | Sets the element from that column                  |
+| `lb-show`   | a column | Removes it while the named column is null or false |
 
-A form gathers from the same controls it lands on, so a value read back on
-submit is the one that landed.
+| Stamp                | The hub stamps it with           |
+| -------------------- | -------------------------------- |
+| `lb-column-value`    | The value it set                 |
+| `lb-key-value`       | The row's key                    |
+| `lb-query-row-count` | The number of live rows it holds |
 
-An `<input>` of type `checkbox`, `radio`, or `file` receives nothing, not even
-`lb-value`, and the hub reports it to the console.  A form gathering one skips it the same way.
+The markup names a query and the columns it shows.  The kind and the key are
+the server's, and the markup states neither.
 
-A `<select>` with no option for the value shows no selection.
+The row template is the first `<template>` among the descendants of an
+element with `lb-query`, outside any nested `lb-query`.  A live row is an
+element the hub cloned from a row template for one row.
+
+| Kind   | Row template | The hub                             |
+| ------ | ------------ | ----------------------------------- |
+| `row`  | no           | Lands the row on the element itself |
+| `row`  | yes          | Lands one live row                  |
+| `rows` | yes          | Lands one live row per row          |
+| `rows` | no           | Lands nothing                       |
+
+A `rows` query with no row template names the query without showing it,
+which is what an insert form naming the query it adds to is.
+
+The nearest ancestor row of an element is the nearest of: the element
+itself when it is a live row, an ancestor that is a live row, and an
+ancestor that carries `lb-query` of kind `row`.  The hub reads `lb-column`
+and `lb-show` from the nearest ancestor row.  A nested `lb-query` begins a
+new query, and what is inside it is that query's.
 
-Only the hyphen and these three form controls are recognized.  The hub holds
-no other knowledge of any particular element, and the hyphen also decides
-that the hub leaves a widget's own clicks alone — see [Requests](#requests).
+An element's own `lb-query` names what the element holds, and its own
+`lb-column` reads from the row around it.  So a
+`<select lb-query="statuses" lb-column="status">` in a live row of
+`accounts` holds the statuses as its options and shows that account's
+`status`.  `lb-column` on an element with `lb-query` is undefined unless the
+element is a control.
 
-Nothing an application writes ever sets `lb-value`.  Loadbare writes it, and
-a widget or a stylesheet reads it.
+Name one query on more than one element to show it in more than one place.
+Every one of them receives it.
+
+A query that arrives with nowhere to land is reported to the console.
+
+#### How a column lands
+
+| Element                                          | The hub sets                   |
+| ------------------------------------------------ | ------------------------------ |
+| A control                                        | Its `value`                    |
+| A custom element that is not a control           | `lb-column-value` only         |
+| Any other element                                | Its text content               |
+
+A control is an `<input>`, `<select>` or `<textarea>`, or a form-associated
+custom element with a `value` property that fires `change`.  A
+form-associated custom element declares `static formAssociated = true`.
+
+The hub stamps `lb-column-value` with the value on every element it sets.
+It never replaces the content of a custom element, which the builder placed
+there from its element file.  A custom element that is not a control
+renders `lb-column-value` itself.
+
+The hub gathers from the same controls it lands on, so a value read back is
+the one that landed.
+
+An `<input>` of type `checkbox`, `radio`, or `file` receives nothing, not
+even `lb-column-value`, and the hub reports it to the console.  The hub does
+not gather one either.
+
+A `<select>` with no option for the value shows no selection.
 
-Loadbare also removes it, when a successful insert resets the cells it
-gathered — see [The round trip](#the-round-trip).  A widget reads a removed
-`lb-value` as "nothing landed here" and returns its control to its default,
-the way a form control with no `value` attribute shows its default.  A blank
-`lb-value` is a value like any other.
+An element with `lb-column` and no ancestor row receives nothing.  The hub
+still gathers from it.
 
 The value arrives as the query produced it, with no conversion, so the
 browser decides what a non-string looks like.
 
-A cell holds one value.  A set of values is a list of its own, never an array
-in a cell.
+A column holds one value.  A set of values is a query of its own, never an
+array in a column.
 
-A widget sees `attributeChangedCallback` for an `lb-value` already present
-when it upgrades, so a widget cannot tell a first landing from a refresh,
-and does not need to.
+A custom element sees `attributeChangedCallback` for an `lb-column-value`
+already present when it upgrades, so it cannot tell a first landing from a
+refresh, and does not need to.
+
+#### Rows
+
+The hub matches each row to a live row by its key.  It stamps
+`lb-key-value` on each live row, and on an element a `row` lands on itself.
+
+All rows decide membership and order: every row is placed in the order
+given, and a live row whose key did not arrive is removed.  A patch touches
+only the rows it names and leaves every other live row's contents and
+position alone.
+
+A new live row lands immediately before the row template, so rows
+accumulate in the order they arrive.  A custom element carrying `lb-query`
+and a row template may place them itself — see [Row hooks](#row-hooks).
+
+After every landing the hub stamps the element with `lb-query-row-count`,
+the number of live rows it holds.  The server answers with rows and says
+nothing about how many survived, so this is the one fact a page cannot be
+sent.  It makes an empty query a stylesheet rule:
+
+```css
+[lb-query-row-count="0"] .roster-empty {
+  display: revert;
+}
+```
+
+A row missing its key column is reported to the console and not landed.
 
 #### Displaying by condition
 
@@ -440,163 +528,236 @@ and does not need to.
 so `"false"` is on, and a query spells a condition as a boolean or a null.
 
 ```html
-<template lb-key="id">
+<template>
   <tr>
-    <td lb-cell="name"></td>
-    <td><button lb-action="lb-row-delete" lb-show="removable">Remove</button></td>
+    <td lb-column="name"></td>
+    <td><button lb-request="lb-row-delete" lb-show="removable">Remove</button></td>
   </tr>
 </template>
 ```
 
-It binds as `lb-cell` does, to the row on the nearest scoped ancestor, and on
-an element that is itself a scope the column belongs to the row around it.  A row
-that does not carry the column leaves the element as it is.
-
-An element that is off is moved into a `<template lb-show="column">` standing
-where it stood, and moved back out when the column turns on.  It is not
-rendered, focused, clicked, announced or gathered.  It is moved and never
-rebuilt, so a widget keeps its instance.  Landing reaches into that template,
-and nothing else does, so the element and every cell and scope inside it
-return current.  A custom element sees `disconnectedCallback` then
-`adoptedCallback` going in, and `adoptedCallback` then `connectedCallback`
-coming out, and still receives `lb-value` while it is away.
+It reads from the nearest ancestor row, as `lb-column` does, and on an
+element that carries `lb-query` the column belongs to the row around it.  A
+row that does not carry the column leaves the element as it is.
+`lb-show` with no ancestor row is undefined.
+
+An element that is off is moved into a `<template lb-show="column">`
+standing where it stood, and moved back out when the column turns on.  It is
+not rendered, focused, clicked, announced or gathered.  It is moved and
+never rebuilt, so a custom element keeps its instance and a control keeps
+what was typed into it.  Landing reaches into that template, so the element
+and everything inside it return current.  A custom element sees
+`disconnectedCallback` then `adoptedCallback` going in, and
+`adoptedCallback` then `connectedCallback` coming out, and still receives
+`lb-column-value` while it is away.
 
 The builder ships every `lb-show` element already inside its template, so
 nothing conditional shows until its row lands.  An absent element's template
 keeps its place among its siblings, and a position selector counts it.
 
-These are build errors: `lb-show` on a row template's root, with no row
-around it (outside every scope, on a scope with none around it, or in a list
-scope outside its row template), or on a `<template>`.
+These are build errors: `lb-show` on a row template's root, `lb-show` with
+no `lb-query` around it, and `lb-show` on a `<template>`.
 
 Hiding is presentation, and the server still refuses what a request may not
 do.
 
 #### Master-detail
 
-A master is a row and its detail is a list, as two names answered side by
-side.  A cell never holds rows.
+A master is a `row` query and its detail is a `rows` query, as two names
+answered side by side.  A column never holds rows.
 
 ```html
-<section lb-row="invoice">
-  <h2 lb-cell="number"></h2>
-  <span lb-cell="customer"></span>
+<section lb-query="invoice">
+  <h2 lb-column="number"></h2>
+  <span lb-column="customer"></span>
 </section>
 
 <table>
-  <tbody lb-list="invoiceLines">
-    <template lb-key="id"><tr><td lb-cell="item"></td><td lb-cell="amount"></td></tr></template>
+  <tbody lb-query="invoiceLines">
+    <template><tr><td lb-column="item"></td><td lb-column="amount"></td></tr></template>
   </tbody>
 </table>
 ```
 
-Many masters, each with its own detail, is one list of joined rows: each
-detail row carries its master's columns.  A widget's `lbPlaceRow` groups them
-for display, as `lb-table` builds sections and `lb-options` builds
-`<optgroup>`s.
+Many masters, each with its own detail, is one `rows` query of joined rows:
+each detail row carries its master's columns.  A custom element's
+`lbPlaceRow` groups them for display, as `lb-table` builds sections and
+`lb-options` builds `<optgroup>`s.
 
-A list nested in another list's rows receives the same rows in every outer
-row.  That serves a picker offering the same choices on every row, and is
-not a way to show a different detail per row.
+A query nested in another query's row template receives the same rows in
+every live row.  That serves a picker offering the same choices on every
+row, and is not a way to show a different detail per row.
 
 Which master a page shows is a query parm, which a query reads off `ctx`
 since it takes no argument from the browser — see [Query parms](#query-parms).
+When a write creates or removes the master, the server response moves the
+URL — see
+[When a server response moves the URL](#when-a-server-response-moves-the-url).
 
 ### Requests
 
 ---- UNEDITED ----
 
-Any element can carry the `lb-action` attribute.  The hub listens for
-events `click` and `submit`, and fires a server request when it catches
-one of those events.
-
-The hub does not act on `click` or `submit` on a custom widget, they
-must fire their own event.  The assumption is a custom widget is present
-because custom behavior is desired, and we don't want the hub to conflict
-with that custom behavior.  A widget is told apart by the hyphen in its tag
-name, the same test that decides how a value lands — see
-[How a value lands](#how-a-value-lands).
-
-| lb-action      | Written on                                        |
-| -------------- | ------------------------------------------------- |
-| lb-row-insert  | a `<form>`, or a button in a `<tr>`, in a list    |
-| lb-row-delete  | anything inside a live row                        |
-| lb-row-update  | a `<form>`, a button in a live row, or a widget cell |
-| anything else  | must be a named routine in the page's server code |
-
-The wire format is not visible to the user, but uses the same lb-*
-attributes minus their prefix, so that it is intelligible when working on
-Loadbare/app itself.
-
-The hub scopes every request, whether a native element or a widget
-dispatched it.  It reads the scope from the dispatching element before any
-ancestor sees the event, and never overwrites a field the request already
-carries.
-
-| `action`         | Filled from scope              | Required               |
-| ---------------- | ------------------------------ | ---------------------- |
-| a declared name  | `list` or `row`, `key`, `cell` | nothing                |
-| `lb-row-insert`  | `list`                         | `list`, and `values`   |
-| `lb-row-delete`  | `list`, `key`                  | both                   |
-| `lb-row-update`  | `list`, `key`                  | both, and `values`     |
-
-An element's own `lb-list` or `lb-row` names what it displays, never where
-its request goes.  A request belongs to the scope around the element, the
-way a control belongs to the form around it.  `list` or `row` comes from the
-nearest ancestor scope, `key` from the nearest live row inside that scope,
-and `cell` from the dispatching element's own `lb-cell`.
-A request missing a required field is not sent.  The hub never fills
-`value`.  An `lb-row-insert` or `lb-row-update` from an element carrying
-`lb-cell` is a record of one cell, the way a control has a value and a form
-has values: `values` holds that cell alone, taken from the `value` the widget
-sent or else read from the control it is or wraps, and `value` is not sent
-beside it.  A widget that sends a `value` from an element carrying no
-`lb-cell` is refused, since nothing names the column.  Any other
-`lb-row-insert` or `lb-row-update` gathers the row it belongs
-to: `values` holds every `lb-cell` with a control to read in the nearest
-`<form>`, `<tr>` or live row around the dispatching element, itself
-included, inside its scope.  The cells are found the way a row lands, so a
-cell inside a scope nested in the row is that scope's and is not gathered,
-while an element carrying a scope and `lb-cell` both is the row's cell.
-This is a button's form owner: what else sits
-beside the element never changes what is sent.  A `<tr>` counts because a
-form cannot go around a table row's controls, so a new row in a table is its
-own form; a live row counts because it is the row the key names.  The scope
-itself is never the row, since its cells belong to other rows.  A request
-from an element in no form or row is not sent, and the hub reports that its
-cells belong in a `<form>`.  A request that already carries `values` keeps
-them, and one whose row has no cell to read is not sent.  A click on a
-native element that carries either operation and is a cell or
-holds cells is not sent, since clicking into one of its controls
-would send the row: put the action on a form, on a button, or on a widget
-that decides when its cell has changed.
-
-A widget dispatches the action and, where it wraps a control, that control's
-value.
+| Attribute    | Names     | The hub                                      |
+| ------------ | --------- | -------------------------------------------- |
+| `lb-request` | a request | Issues that request when the element commits |
+
+| Stamp                | The hub stamps it                          |
+| -------------------- | ------------------------------------------ |
+| `lb-request-pending` | While the round trip is in flight          |
+| `lb-request-error`   | When the round trip fails, until the next  |
+
+The request name is the attribute value of `lb-request`.  It names either a
+request Loadbare provides or a declared request: a name the page declares
+under `handlers`, which runs application code.
+
+Every request has one shape, on the event and on the wire:
 
 ```
-{ action: "lb-row-insert",  list: "rosterList", values: {...} }
-{ action: "lb-row-delete",  list: "rosterList", key: "42" }
-{ action: "lb-row-update",  list: "rosterList", key: "42", values: {...} }
-{ action: "lb-row-update",  list: "rosterList", key: "42", values: { name: "Ann" } }
-{ action: "selectTab",      row: "prefs", cell: "active_tab", value: "two" }
+{ name: "lb-row-insert", query: "roster", values: { name: "Ann" } }
+{ name: "lb-row-update", query: "roster", key: "42", values: { name: "Ann" } }
+{ name: "lb-row-delete", query: "roster", key: "42" }
+{ name: "mailRoster",    query: "roster", key: "42" }
 ```
 
+The hub sends `query`, `key` and `values` as present.
+
+#### Committing
+
+An element commits on `submit` when it is a form, on `change` when it is a
+control, and on `click` otherwise.
+
+A submit button with a form owner never commits on `click`.  On a form's
+`submit`, the hub issues the submitter's `lb-request` when it carries one,
+and the form's otherwise, the way `formaction` replaces `action`.
+
+A click on a descendant of an element carrying `lb-request` commits that
+element, as long as the element is inside `<lb-hub>` and no interactive
+content lies between them.  Interactive content is HTML's: `<a href>`,
+`<button>`, `<input>` other than hidden, `<select>`, `<textarea>`, `<label>`,
+`<details>`, `<iframe>`, `<embed>`, `<audio controls>`, `<video controls>`
+and `<img usemap>`, plus any form-associated custom element.  A click on
+one of them belongs to it: a click into an input inside a deletable row
+focuses the input and deletes nothing.
+
+The hub ignores a commit on an element carrying `lb-request-pending`.
+
+#### Gathering
+
+The hub gathers values when it issues a request.  It gathers each control
+value under the column its `lb-column` names.
+
+| Attribute      | The hub                                     |
+| -------------- | ------------------------------------------- |
+| `lb-query`     | Issues the request for it                   |
+| `lb-column`    | Gathers the control value under that column |
+| `lb-key-value` | Takes `key` from it                         |
+
+- When the element carrying `lb-request` has `lb-column`, the hub gathers
+  its value alone, and sends `values` with one member.
+- Otherwise, when the element is a `<form>`, the hub gathers every
+  `lb-column` whose form owner is the element.
+- Otherwise, when the element is in a live row, the hub gathers every
+  `lb-column` in that live row.
+- Otherwise the hub gathers every `lb-column` whose form owner is the
+  element's form owner.
+
+The form owner includes a control that names the form with the HTML `form`
+attribute from anywhere in the document, which is how a table row's
+controls belong to a form that cannot wrap a `<tr>`:
+
+```html
+<form id="add-member" lb-request="lb-row-insert"></form>
+<table lb-query="roster">
+  <tbody>
+    <template>
+      <tr><td lb-column="name"></td><td lb-column="role"></td></tr>
+    </template>
+  </tbody>
+  <tfoot>
+    <tr>
+      <td><input lb-column="name" form="add-member" /></td>
+      <td>
+        <input lb-column="role" form="add-member" />
+        <button form="add-member">Add</button>
+      </td>
+    </tr>
+  </tfoot>
+</table>
+```
+
+The hub gathers from controls only.  It skips a control whose nearest
+ancestor `lb-query` is a descendant of the live row or form, since that
+control belongs to a nested query.  An element carrying `lb-query` and
+`lb-column` both, such as a picker, belongs to the row around it and is
+gathered.
+
+The hub issues the request for the nearest ancestor `lb-query` of the
+controls it gathered, and takes `key` from their nearest ancestor row when
+that row is of the same query.  When the gathered controls have different
+nearest ancestor `lb-query`, the hub reports an error and sends nothing.
+
+When it gathers nothing, the hub issues the request for the nearest
+ancestor `lb-query` of the element carrying `lb-request`, and takes `key`
+from that element's nearest ancestor row when that row is of the same
+query.
+
+A field the request already carries is its issuer's and is kept.  A custom
+element that dispatches its own request with `values` is not gathered over.
+
+#### The request names
+
+| Request name    | Needs                    | Runs under `crud` |
+| --------------- | ------------------------ | ----------------- |
+| `lb-row-insert` | `query`, `values`        | `rowInsert`       |
+| `lb-row-update` | `query`, `key`, `values` | `rowUpdate`       |
+| `lb-row-delete` | `query`, `key`           | `rowDelete`       |
+
+The hub issues one of these only when it has what the table lists.  An
+`lb-row-insert` or `lb-row-update` that gathers nothing is not issued.  A
+request that is not issued is reported to the console.
+
+Loadbare provides the handlers for these names: each runs the page's `crud`
+entry for the request's query.  A declared request runs the application's
+handler under `handlers`, and the hub issues it with whatever it found.
+
+A request name beginning with `lb-` that is none of these three is refused
+by the builder in markup, and by the hub when a script dispatches it.
+
+For a query the hub serves, the hub answers the request itself, with no
+round trip.  The hub serves `lb-url`, and answers `lb-row-update` for it —
+see [Query parms](#query-parms).
+
 #### The request event
 
-The hub does not send a request the moment it catches a click or a submit.
-It builds the request, dispatches it from the element that acted as a
-bubbling `lb-request` event carrying the request as its `detail`, and a
-listener on the hub sends it.
+The hub dispatches every request as the bubbling `lb-request` event before
+sending it, with the request as its `detail`.  The event is dispatched from
+the element that committed.
 
-A widget uses that same event, and it is the only channel a widget has for
-firing a request of its own.  A native element and a hand-written widget
+A custom element uses the same event to issue a request of its own, with at
+least `name` in its `detail`.  A native element and a custom element
 therefore produce identical events.
 
-An ancestor sees the request on its way up and may stop it.  The event is
-not cancelable, so an interceptor calls `stopPropagation`, not
-`preventDefault`.  This is what makes a confirmation wrapper possible
-without the wrapped element knowing about it.
+The hub completes the request on the event's way down, so every ancestor
+sees it whole on the way up.  A request that cannot be issued is stopped
+there.  An ancestor may stop it too: the event is not cancelable, so an
+interceptor calls `stopPropagation`, not `preventDefault`.  This is what
+makes a confirmation wrapper possible without the wrapped element knowing
+about it.
+
+#### Request state
+
+The hub stamps `lb-request-pending` on the element that issued a request
+while its round trip is in flight, together with `aria-busy="true"`, and
+removes both when it settles.  It stamps `lb-request-error` when the round
+trip fails, and clears it when that element issues its next request.
+
+A custom element observes them by naming them in `observedAttributes`.  On
+plain HTML a stylesheet is the only consumer: dim a pending button, mark a
+failed one.
+
+The hub ignores a commit on an element carrying `lb-request-pending`, so a
+pending element is disabled in fact and a stylesheet only has to show it.
 
 #### The round trip
 
@@ -605,77 +766,63 @@ aborts it and treats it as a failure, since `fetch` imposes no deadline of
 its own.  An application cannot change the deadline.
 
 A round trip fails on a server error, on a network failure, or on that
-deadline, and all three set `lb-error` on the element that dispatched the
-request — see [Request state](#request-state).
-
-After a write succeeds, the cells it gathered show what the server holds.
-An `lb-row-update` does this by landing the row on them.  An
-`lb-row-insert` does it by resetting them, the way `form.reset()` resets a
-form, because the row they held now lives in the list.  The hub resets
-after it lands the response, and only what it gathered:
-
-- Each control returns to its default: an `<input>` or `<textarea>` to its
-  `defaultValue`, a `<select>` to the options marked `selected`.  A page
-  that wants a prefilled insert writes a `value` attribute, as in plain
-  HTML.
-- A control showing something other than the value the hub read holds an
-  edit made during the round trip.  That edit was not sent, and is left.
-- `lb-value` comes off each reset cell, and off its control, before the
-  control resets — see [How a value lands](#how-a-value-lands).
-- Values a widget supplied in the request were not gathered, and are not
-  reset.
-- Nothing is dispatched, as `form.reset()` fires no `change`.
-
-A failed insert resets nothing, so the entry can be corrected.
-
-A navigation that fails to load its data sets nothing.  No element
-dispatched it, so there is nothing to stamp, and the hub reports it to the
-console.  A load started by a control writing a query parm stamps that
-control, as a request stamps its origin.
-
-### Links
+deadline, and all three stamp `lb-request-error` on the element that issued
+the request — see [Request state](#request-state).
 
----- UNEDITED ----
+After a successful `lb-row-insert` gathered from a form, the hub resets the
+form, after it lands the response.  A failed insert resets nothing, so the
+entry can be corrected.  An `lb-row-update` resets nothing: the row it sent
+lands back on its controls.
 
-An anchor carrying `lb-nav-link` navigates inside the application: the hub
-catches the click, pushes the anchor's path and query string onto history,
-and swaps the page host in `<main>`.  An anchor without it is left alone and behaves like any
-other link, so leaving the application is the default and staying in it is
-the opt-in.
+A reset of any form, whether the hub's, a reset button's or a script's,
+returns its controls to their defaults, and the hub removes
+`lb-column-value` from each of them.  A cancelled reset keeps both.
 
-| Attribute   | Assigned By | Behavior                                                                                |
-| ----------- | ----------- | --------------------------------------------------------------------------------------- |
-| lb-nav-link | Developer   | On an `<a>`: the hub shows the page the anchor's path names, without loading a document |
+A page load that fails lands nothing and is reported to the console.  A load
+started by a request for `lb-url` stamps the element that issued it, as any
+request stamps its element.
 
-The attribute takes no value.  The hub looks for the nearest ancestor 
-link to determine the path.
+### The URL
 
-Path space is flat.  A path such as `/members` links to the `members.*` files
-on the server.
+---- UNEDITED ----
 
-The query string is kept.  `/transactions?date_begin=2026-09-01` opens the
-transactions page narrowed to those dates, and a link to the page it is
-already on loads that page again at the new URL without replacing its DOM —
-see [Query parms](#query-parms).
+The hub serves the query `lb-url`, of kind `row`, keyed by `lb-path`.  It
+lands wherever an element names it, like any server query.
 
-The bare path `/` resolves to `index`.
+| Column            | The hub sets it to                             |
+| ----------------- | ---------------------------------------------- |
+| `lb-path`         | The path.  The row's key                       |
+| `lb-page-label`   | The page's title, or its stub when it has none |
+| `lb-page-unknown` | Whether no page's stub matches the path        |
+| any other name    | That query parm                                |
 
-A path that names no page is detected in the browser, after a successful
-200: every route gets the same document, so there is no server-delivered
-404.  A chrome that declares an `lb-unknown-page` dialog gets it opened.
-One that declares none gets a console error and nothing on screen.  See
-[Chrome](#chrome).
+| Attribute        | The hub                                                  |
+| ---------------- | -------------------------------------------------------- |
+| `lb-url-link`    | On a plain primary click, sets `lb-path` from the `href` |
+| `lb-url-push`    | Pushes a history entry for this element's update         |
+| `lb-url-unknown` | Calls `showModal()` when `lb-page-unknown` is `true`     |
+
+- `lb-url-link` goes on an `<a>`.
+- `lb-url-push` goes on an element with `lb-request`.
+- `lb-url-unknown` goes on a `<dialog>` inside `<lb-hub>`.
+
+The hub shows in `<main>` the page whose stub is `lb-path`.  `/` is
+`index`.  When `lb-path` takes a new value, the hub loads the page: the
+server runs its `onPageEnter`, then its queries.  When a query parm takes a
+new value, the hub reloads the page's queries, and keeps the page's DOM, so
+live rows that come back keep their place.
+
+The page's title is the text of the page file's `<title>`, which the builder
+stamps on the page as `lb-page-title`.  The hub sets the document title to
+`lb-page-label` when it is not null.
 
 ```html
-<nav>
-  <a href="/" lb-nav-link>Home</a>
-  <a href="/members" lb-nav-link>Members</a>
-  <a href="https://example.com/docs">Docs</a>
-</nav>
+<header lb-query="lb-url">
+  <h1>Membership Roster</h1>
+  <h2 lb-column="lb-page-label"></h2>
+</header>
 ```
 
-See also [Navigation Row lb-navigation](#lb-navigation).
-
 #### What a URL names
 
 The path names a page, a place in the application.  It never names a
@@ -687,101 +834,182 @@ The query string describes what that page has on screen:
 remembers nothing, so a URL is a reproducible view.  Reload it, bookmark it,
 or mail it to someone, and what they see is what the sender saw.
 
-A page declares what it shows, its queries, and what it allows, its actions.
-Loading a page runs its queries.  A request performs an action at a position.
-A row is addressed by `list` and `key`, taken from where the element sits,
-which is how the database already names it.  Nothing is fetched by URL, so an
-application designs no endpoints.
+A page declares what it shows, its queries, and what it allows, its
+requests.  Loading a page runs its queries.  A request names a query and,
+where it has one, a key, taken from where the element sits, which is how the
+database already names a row.  Nothing is fetched by URL, so an application
+designs no endpoints.
 
 That last is where query parms move Loadbare's position.  A query still takes
 no argument from the browser, and a parm arrives the way the session cookie
 does, as part of the request the context is built from.  But a user who
-types `?acct=99999` now influences what a query returns.  A query parm is
-user input, validated like any other where the application reads it, and a
+types `?acct=99999` influences what a query returns.  A query parm is user
+input, validated like any other where the application reads it, and a
 per-session database role means an id outside the caller's reach finds
 nothing.
 
 Loadbare is for applications, not sites.  Every route is answered with the
 same document, and a path that names no page is found out in the browser —
-see [Links](#links).
+see [An unknown page](#an-unknown-page).
 
-#### Query parms
+#### Links
 
-A control that narrows what a page shows writes its value into the query
-string, rather than sending it:
+An `<a>` carrying `lb-url-link` moves within the application.  On a plain
+primary click — the first button, no modifier key, not already handled — the
+hub pushes a history entry for the `href`'s path and query string, and loads
+the page there.  Any other click, and any anchor without `lb-url-link`,
+behaves like any other link, so leaving the application is the default and
+staying in it is the opt-in.
 
 ```html
-<lb-options lb-list="teams" lb-query-parm="team" exp-label="Team:">
-  <option value="">Every team</option>
-  <template lb-key="id"><option lb-cell="name"></option></template>
-</lb-options>
+<nav>
+  <a href="/" lb-url-link>Home</a>
+  <a href="/members" lb-url-link>Members</a>
+  <a href="https://example.com/docs">Docs</a>
+</nav>
 ```
 
-| Attribute            | Written by | Behavior                                                        |
-| -------------------- | ---------- | --------------------------------------------------------------- |
-| `lb-query-parm`      | Developer  | On a control: its `change` writes this parm and reloads the page |
-| `lb-query-parm-push` | Developer  | With `lb-query-parm`: the write pushes a history entry          |
+The attribute takes no value.
 
-On `change`, the hub reads the control's value the way a form reads a cell,
-and sets that one parm in the URL.  Every other parm is left as it is, since
-it may have arrived by link with no control on screen to say it again.  An
-empty value takes the parm out, so a URL is as long as the user has narrowed
-the page.  A value the URL already carries does nothing.
+Path space is flat.  A path such as `/members` links to the `members.*` files
+on the server.
 
-The write replaces the current history entry: changing what a page shows is
-not going anywhere, so Back leaves the page rather than walking back through
-every choice.  `lb-query-parm-push` makes the write push an entry instead.
+The query string is kept.  `/transactions?date_begin=2026-09-01` opens the
+transactions page narrowed to those dates.
 
-The page then loads at the new URL exactly as a cold load of that URL would:
-`onPageEnter`, then every query.  The page's DOM is kept, and the answer
-lands by key, so a list that gets its rows back keeps them and its scroll
-position.
+The browser's Back and Forward load the page at the URL they arrive at, the
+same way.
 
-After every load — cold, by link, by Back, by a write — the hub lands each
-parm on the control that writes it, and an absent parm lands empty.  A
-control therefore shows what the address bar says.
+#### Query parms
 
-A control that writes a query parm sends no request.  One that also carries
-`lb-action` has that request refused, since the choice would otherwise be
-sent twice.
+A control that narrows what a page shows updates `lb-url` rather than
+sending a request.  Put it inside an element naming `lb-url`, with
+`lb-column` naming the parm and `lb-request="lb-row-update"`:
 
-Every round trip carries the query string the browser is showing, a page
-load and an action alike.  The server reads the parms off `req.query` in
-`contextFor` — see [The Express server](#the-express-server).  Nothing in
-Loadbare assigns a parm a meaning.
+```html
+<div lb-query="lb-url">
+  <select lb-column="team" lb-request="lb-row-update">
+    <option value="">Every team</option>
+    <option value="Engines">Engines</option>
+  </select>
+</div>
+```
 
-### lb-navigation
+The hub answers the request itself.  It sets the parms the request names in
+the URL and leaves every other parm as it is, since one may have arrived by
+link with no control on screen to say it again.  An empty value takes the
+parm out, so a URL is as long as the user has narrowed the page.  A request
+that leaves the URL as it was does nothing.  `lb-page-label` and
+`lb-page-unknown` are the hub's, and a request never sets them.
 
----- UNEDITED ----
+The update replaces the current history entry: changing what a page shows is
+not going anywhere, so Back leaves the page rather than walking back through
+every choice.  `lb-url-push` on the element carrying `lb-request` makes the
+update push an entry instead.
 
-Status: 1.0-RC.
+When `lb-path` takes a new value, the hub pushes a history entry, and the
+new URL carries only the query parms the request names.
 
-Current page, published by the hub as a row.  Can be bound anywhere just
-like a server-produced result.
+Every load lands `lb-url`, and a parm the URL does not carry lands empty on
+every element naming it as a column, so a control shows what the address
+bar says after Back as well as after a reload.  This is the one exception
+to landing, where a row sets the columns it names and leaves the rest as
+they were: the hub reads the column names under `lb-query="lb-url"` and
+names each one in the row it lands.
 
-| Cell         | Holds                                                               |
-| ------------ | ------------------------------------------------------------------- |
-| `page-label` | The text of the link to the current page, empty if no link names it |
-| `page-uri`   | The path and query string as the browser has them, such as `/members?team=Engines` |
+The hub sends the query parms with every round trip, a page load and a
+request alike.  The server passes them to `contextFor` — see
+[The Express server](#the-express-server).  Nothing in Loadbare assigns a
+parm a meaning.
 
-The `page-uri` is taken from the current URL.  The `page-label` is taken from the first
-`lb-nav-link` link in the document (presumably in a nav bar) whose path matches the
-current path, so the query string does not change it.
+#### An unknown page
 
-The row lands before the page is looked up, so a path that names no page has
-it too, and an `lb-unknown-page` dialog, where the chrome has one, displays
-it by naming the row like any other subtree.
+When no page's stub matches the path, `lb-page-unknown` is `true` and
+`lb-page-label` is null.  The hub calls `showModal()` on the
+`<dialog lb-url-unknown>`, where the chrome has one, and reports the path to
+the console.  A chrome with none shows nothing.
 
-It lands only where a subtree names it.  A chrome that displays no
-navigation is not warned about a row with nowhere to go.
+`lb-url` lands before the page is looked up, so the dialog shows it by
+naming it like any other element:
 
 ```html
-<header lb-row="lb-navigation">
-  <h2 lb-cell="page-label"></h2>
-</header>
+<dialog lb-url-unknown lb-query="lb-url">
+  The URL <span lb-column="lb-path"></span> is not in this app.
+</dialog>
+```
+
+A path that names no page is detected in the browser, after a successful
+200: every route gets the same document, so there is no server-delivered
+404.
+
+#### When a server response moves the URL
+
+Some query parms can only be known once a write has run.  After an insert,
+the key of the new row exists only on the server.  After a delete, only the
+server knows that the row the page was showing is gone.
+
+The usual web answer is Post/Redirect/Get: the server answers the write with
+a redirect to a URL naming the result, and the browser makes a second request
+to load it.  Loadbare/app does the same work in one round trip.
+
+A handler returns `url()`, a new row for `lb-url`.  The server loads the page
+at the resulting URL, as a cold load of it would: `onPageEnter`, then every
+query.  The response carries the `lb-url` item followed by that load.  The
+hub writes the URL and then lands the load.
+
+```ts
+rowInsert: {
+  run: async (ctx, { values }) => {
+    const id = await ctx.db.addAccount(values);
+    return url({ acct: String(id) });
+  },
+  refresh: [],
+},
 ```
 
-See also [Links](#links).
+- A column other than `lb-path` is a query parm.  Parms the row does not
+  name are kept, and an empty value removes its parm.
+- A row carrying `lb-path` for another page enters that page with only the
+  parms the row names, and pushes a history entry.  Otherwise the update
+  replaces the history entry, or pushes one when the element that issued the
+  request carries `lb-url-push`.
+- The row names at least one column, and every value is a string.  Otherwise
+  the server warns, ignores the row, and runs the refresh set as usual.
+- The refresh set does not run, and anything else the handler returned is
+  dropped.  Both were answers for the URL the page is leaving.
+- If loading the page fails, the write has still happened.  The response
+  carries the `lb-url` item alone, and the hub loads the page itself.  A
+  failure there is a page load's, and is not stamped on the element that
+  issued the request.
+- A user who has left the page by the time the response arrives keeps the
+  URL they are on.
+
+The page is loaded with a second context, built by `contextFor` from the new
+parms — see [The Express server](#the-express-server).
+
+### The markup checks
+
+The builder checks the chrome and every page, after expansion, and refuses
+to build on any of these:
+
+- An `lb-` attribute that is not a developer attribute: `lb-query`,
+  `lb-column`, `lb-show`, `lb-request`, `lb-url-link`, `lb-url-push`,
+  `lb-url-unknown`.  Every other `lb-` attribute is a stamp.
+  `lb-exp-slot` and `lb-exp-template` are consumed by expansion and never
+  reach the check.
+- `lb-request` naming a value that begins with `lb-` and is not one of the
+  three request names.
+- `lb-url-link` on anything but an `<a>`.
+- `lb-url-push` on an element with no `lb-request`.
+- `lb-url-unknown` on anything but a `<dialog>`, and in the chrome, outside
+  `<lb-hub>`.
+- `lb-show` on a `<template>`, on a row template's root, or with no
+  `lb-query` around it.
+
+`lb-column` with no ancestor row is allowed: the hub gathers from it.
+
+Script never assigns an `lb-` attribute, so the markup states every one
+that exists, and checking the markup is sound.
 
 ## Application files
 
@@ -801,10 +1029,9 @@ The file is an HTML document, which must contain:
 
 It may also contain:
 - `/app.css`, the stylesheet bundle
-- A `<dialog>` marked with attribute `lb-unknown-page`, which the hub
-  will display to the user if an attempt is made to navigate to an
-  unknown page.  It goes inside `<lb-hub>`, like everything the hub acts
-  on; the builder rejects one placed elsewhere.
+- A `<dialog lb-url-unknown>`, which the hub opens when the path names no
+  page.  It goes inside `<lb-hub>`, like everything the hub acts on; the
+  builder rejects one placed elsewhere.
 - The `hidden` attribute on `<body>`, which the hub removes once the first page has landed.
 
 ```html
@@ -819,52 +1046,66 @@ It may also contain:
   </head>
   <body hidden>
     <lb-hub>
-      <header lb-row="lb-navigation">
+      <header lb-query="lb-url">
         <h1>Membership Roster</h1>
-        <h2 lb-cell="page-label"></h2>
+        <h2 lb-column="lb-page-label"></h2>
       </header>
       <nav>
-        <a href="/" lb-nav-link>Home</a>
-        <a href="/members" lb-nav-link>Members</a>
+        <a href="/" lb-url-link>Home</a>
+        <a href="/members" lb-url-link>Members</a>
         <a href="https://example.org/">Our website</a>
       </nav>
       <main></main>
-      <dialog lb-unknown-page lb-row="lb-navigation">
-        The URL <span lb-cell="page-uri"></span> is not in this app.
+      <dialog lb-url-unknown lb-query="lb-url">
+        The URL <span lb-column="lb-path"></span> is not in this app.
       </dialog>
     </lb-hub>
   </body>
 </html>
 ```
 
-The `lb-row`, `lb-cell` and `lb-nav-link` attributes in that example are
-ordinary Loadbare/app binding.  See [Binding](#binding),
-[Links](#links) and [lb-navigation](#lb-navigation).
+The chrome's `<title>` shows until the first page lands, and each page's
+title replaces it — see [The URL](#the-url).
 
 ### Pages
 
 The page namespace is flat.  Loadbare/app does not care where in the `--src`
 the page files are located, but they must be unique across the application.
-A page `/deep/path/to/mypage.html` is routed to `/mypage`.
+A page `/deep/path/to/mypage.page.html` is routed to `/mypage`.
 
 Pages are grouped as
-- <stub>.page.html is recognized as navigable and capable of
+- `<stub>.page.html` is recognized as navigable and capable of
   having associated queries and requests
-- <stub>.queries.ts are the queries for a page
-- <stub>.requests.ts respond to the requests from the browser
+- `<stub>.queries.ts` are the queries for a page
+- `<stub>.requests.ts` respond to the requests from the browser
 
-The <stub> value for a page must match the path used in links,
-so that `<a href='/members' lb-nav-link>Members</a>` has matching
-files `members.pages.html` et al.
+The stub of a page must match the path used in links,
+so that `<a href="/members" lb-url-link>Members</a>` has matching
+files `members.page.html` et al.
 
 #### Page HTML
 
 The markup in `<stub>.page.html` is the same HTML as everywhere else
 in a Loadbare/app application, see [HTML](#html).
 
-The builder wraps each expanded page in `<template lb-page="<stub>">` and
-puts it in the built document.  The application never writes `lb-page`; the
-hub reads it to find the page a path names.
+A page file may carry a `<title>`.  The builder removes it and stamps its
+text content as `lb-page-title` on the page, and the hub shows it as
+`lb-page-label`.
+
+```html
+<!-- src/pages/members.page.html -->
+<title>Members</title>
+<h1>Members</h1>
+```
+
+The builder wraps each expanded page in
+`<template lb-page="<stub>" lb-page-title="...">` and puts it in the built
+document.  The hub reads `lb-page` to find the page a path names.
+
+| Stamp           | The builder stamps it with                    |
+| --------------- | --------------------------------------------- |
+| `lb-page`       | The page's stub, which the hub reads          |
+| `lb-page-title` | The text content of the page file's `<title>` |
 
 ## The server
 
@@ -928,18 +1169,24 @@ Explaining Express is beyond the scope of this technical reference.  The
 only real requirement is that the catch-all for app.html is at the end,
 so it does not catch any other files.
 
-`hubRoutes` answers `POST /lb/<page>`, with the query string the browser is
-showing after it, verbatim.  So `req.query` holds the page's query parms, and
-`contextFor` puts on the context whatever a query reads from them.  They are
-user input:
+`hubRoutes` answers `POST /lb/<stub>`, with the query string the browser is
+showing after it, verbatim.  It hands `contextFor` that query string's parms
+as a second argument, and `contextFor` puts on the context whatever a query
+reads from them.  They are user input:
 
 ```ts
-function contextFor(req: Request): HubContext {
-  const { acct } = req.query;
-  return { db: openDb(), acct: typeof acct === "string" ? acct : "" };
+function contextFor(req: Request, parms: URLSearchParams): HubContext {
+  return { db: openDb(), acct: parms.get("acct") ?? "" };
 }
 ```
 
+Read the parms from that argument, not from `req.query`.  After a request
+whose handler returned `url()`, `contextFor` is called a second time for
+the same request, with the new parms, to load the page at them.  So it must
+be safe to call twice, and a write must be visible to the second context by
+the time its `run` returns.  A handle opened per request without a
+transaction around it is both.
+
 Give the server the origin root.  The hub reaches its own endpoints by
 absolute path, so an application cannot be hosted under a subpath such as
 `example.com/myapp/`, and anything proxying in front of the server passes
@@ -948,28 +1195,37 @@ the whole path space through unchanged.
 ### Page Queries
 
 `<stub>.queries.ts` exports one object named `queries`, typed `Queries`.
-Each key is a query name, and the markup binds to that name through
-`lb-list` or `lb-row`.
-
-Cardinality belongs to the named query.  One named query always returns a single
-row or an array of rows.  Build a query using `row()` or `list()` to return
-the two shapes.  A query cannot be built without one of these functions.
+Each key is a query name, which the markup names with `lb-query`.
 
-Queries names cannot begin with `lb-`, that namespace is reserved for
-Loadbare/app queries the hub makes available in the browser, such
-as [lb-navigation](#lb-navigation).
+A query's kind and key belong to its name.  Declare each query with
+`row(key, run)` or `rows(key, run)`, naming the key column first.  A query
+cannot be built without one of these functions.  Every query has a key; an
+aggregate row answers with a constant one.
 
 ```ts
 // members.queries.ts
-import { list, row, type Queries } from "@loadbare/app/server";
+import { row, rows, type Queries } from "@loadbare/app/server";
 
 export const queries: Queries = {
-  roster: list((ctx) => ctx.db.members()),
-  summary: row(async (ctx) => ({ count: String(await ctx.db.memberCount()) })),
+  roster: rows("id", (ctx) => ctx.db.members()),
+  summary: row("id", async (ctx) => ({
+    id: "all",
+    count: String(await ctx.db.memberCount()),
+  })),
 };
 ```
 
-Every query and every request receives `ctx`, the application's own request
+A `row` query returns one object, and a `rows` query returns an array of
+objects in the order the page shows them.  An answer that disagrees with
+its declared kind is left out of the response, with a warning naming the
+query.
+
+Query names cannot begin with `lb-`, that namespace is reserved for
+Loadbare/app queries the hub serves in the browser, such as
+[`lb-url`](#the-url).  `createHub` refuses at startup a page that declares
+such a name as a query, a handler or a `crud` entry.
+
+Every query and every handler receives `ctx`, the application's own request
 context.  The application builds it once per request and hands it to the hub,
 see [The Express server](#the-express-server).  Loadbare/app declares it empty
 and never reads it, so a query finds exactly what the application put there,
@@ -985,37 +1241,40 @@ It has three optional keys.
 
 | Key           | Keyed by              | Answers                                            |
 | ------------- | --------------------- | -------------------------------------------------- |
-| `actions`     | The `lb-action` value | Anything the page chooses to declare               |
-| `crud`        | A query name          | The three reserved `lb-action` values              |
+| `handlers`    | The request name      | The page's declared requests                       |
+| `crud`        | A query name          | The three requests Loadbare provides               |
 | `onPageEnter` | Nothing               | Runs once on entering the page, before its queries |
 
+The server resolves a declared request against `handlers`, and a request
+Loadbare provides against `crud` under the request's query.  A name with no
+entry there logs a server console warning naming the page and the missing
+entry, and answers 200 with no response items, so nothing lands and
+`lb-request-pending` clears from the element that issued the request.  A
+request carrying no name answers 400, and a `run` that throws answers 500.
 
-The hub resolves an `lb-action` value against `actions`, and a reserved
-operation against `crud` under the bound list name.  A name with no entry
-there logs a server console warning naming the page and the missing entry,
-and answers 200 with `{}`.  The browser applies `{}`, so no cell is set and
-no row is added or removed, and `lb-pending` clears from the element that
-sent the request.  A request carrying no action answers 400, and a `run`
-that throws answers 500.
+Every handler under `handlers` and `crud` has the same two members.  `run`
+performs the work, and `refresh` names the queries to re-run once it has.
 
-Every entry under `actions` and `crud` has the same two members.  `run`
-performs the work, and `refresh` names the queries to re-run once the action
-is complete.
+`run` receives the same `ctx` and the request less its name: `query`, `key`
+and `values`, as present.
 
-`run` receives the same `ctx` and a `where`: the binding in scope when the
-interaction happened, as `list`, `row`, `key`, `cell` and `value`.  Under
-`crud` the `where` carries only what that operation is typed to carry.
+`run` may also return answers of its own, by query name, which are laid over
+the refreshed ones.  That is how a delta reaches the browser: wrap it in
+`patch()`, naming the rows that arrived or changed and the keys that went.
 
-`run` may also return results of its own, which are laid over the refreshed
-ones.  That is how a delta reaches the browser: wrap it in `patch()`, naming
-the rows that arrived or changed and the keys that went.
+`run` may instead return `url()`, a new row for `lb-url`, naming query parms
+only the write can know, such as the key of a row it inserted.  The page
+then loads at them in the same round trip, in place of the refresh set — see
+[When a server response moves the URL](#when-a-server-response-moves-the-url).
+A `rowDelete` that removes the row on screen returns `url({ acct: "" })`
+and leaves any other delete to its refresh set.
 
 ```ts
 // members.requests.ts
 import { patch, type Requests } from "@loadbare/app/server";
 
 export const requests: Requests = {
-  actions: {
+  handlers: {
     resetRoster: {
       run: (ctx) => ctx.db.resetMembers(),
       refresh: ["roster"],
@@ -1024,9 +1283,9 @@ export const requests: Requests = {
   crud: {
     roster: {
       rowDelete: {
-        run: async (ctx, where) => {
-          await ctx.db.deleteMember(where.key);
-          return { roster: patch({ drop: [where.key] }) };
+        run: async (ctx, { key }) => {
+          await ctx.db.deleteMember(key);
+          return { roster: patch({ drop: [key] }) };
         },
         refresh: [],
       },
@@ -1035,86 +1294,118 @@ export const requests: Requests = {
 };
 ```
 
-Each key under a `crud` entry is a reserved `lb-action` value with its prefix
-stripped and the rest camel-cased, so the attribute, the wire and this key
-are one vocabulary.  All three operate on a list, because each needs a key and
-a key exists only on a live row.
+Each key under a `crud` entry is a request name with its prefix stripped and
+the rest camel-cased, so the attribute, the wire and this key are one
+vocabulary.  A query with no `crud` entry permits none of them.
 
-| `lb-action`      | Key under `crud` | `where` carries        |
-| ---------------- | ---------------- | ---------------------- |
-| `lb-row-delete`  | `rowDelete`      | `key`                  |
-| `lb-row-insert`  | `rowInsert`      | `values`               |
-| `lb-row-update`  | `rowUpdate`      | `key`, `values`        |
+| Request name    | Key under `crud` | `run` receives  |
+| --------------- | ---------------- | --------------- |
+| `lb-row-insert` | `rowInsert`      | `values`        |
+| `lb-row-update` | `rowUpdate`      | `key`, `values` |
+| `lb-row-delete` | `rowDelete`      | `key`           |
 
 A `rowUpdate` sets the columns `values` names and leaves the rest as they
-are, as an SQL `UPDATE` does.  A form sends the cells it holds and a widget
-cell sends itself, so one handler answers both.
+are, as an SQL `UPDATE` does.  A form sends the controls it holds and a
+control carrying `lb-request` sends itself, so one handler answers both.
 
-## Widgets
+### The wire
 
 ---- UNEDITED ----
 
-A widget is an HTML custom element following these fixed rules:
-- Element name must contain a hyphen, as per hTML rules, like <my-custom-element>
-- HTML code, if present, is `my-custom-element.html`
-- TS code, if present, is in `my-custom-element.browser.ts`.  The
-  'browser' segment is a safety feature, requiring the file to be
-  explicitly named as a browser file, to help prevent unfortunate
-  naming collisions where a server file happens to have the name of
-  a widget and gets built into the browser bundle.
+One path, one method.  The hub sends every round trip as
+`POST /lb/<stub>?<query string>`, with the query string the browser is
+showing.  An empty body asks for the page load.  Any other body is a
+request:
 
-A widget must have either one or the other of HTML and Typescript, and
-it may have both.  If it has neither, the builder reports an error.
+```ts
+interface HubRequest {
+  name: string;
+  query?: string;
+  key?: string;
+  values?: Record<string, string>;
+}
+```
 
-To use a widget from a library, add the library to `imports.ts` anywhere
-in the builders `--src`:
+Every response is an array of response items:
 
 ```ts
-export default ["@scope/library-name"];
+interface ResponseItem {
+  query: string;
+  kind: "row" | "rows";
+  key: string;
+  row?: Row;
+  rows?: Row[];
+  patch?: { rows?: Row[]; drop?: unknown[] };
+}
 ```
 
-### Widget authoring
+A response item carries exactly one of `row`, `rows` or `patch`.  A patch
+answers a `rows` query only: rows named in `rows` are added or updated, keys
+in `drop` are removed, and every other row is left alone.
+
+`createHub(pages)` builds the `Hub`, which has two calls, both answering
+with response items: `dataForPage(page, ctx)` for a page load, and
+`runRequest(page, request, ctx)` for a request.
+
+## Custom elements
 
 ---- UNEDITED ----
 
-The expansion grammar, `exp-`, `lb-slot`, `lb-template`, the reserved `LB-`
-namespace, then `lbPlaceRow` and `lbRowsLanded`. One bucket spanning build
-time and run time, because a widget is a definition and a script together.
+A custom element is an element defined by `customElements.define`, and
+follows these fixed rules in a Loadbare/app application:
+- Its name contains a hyphen, as HTML requires, like `<my-custom-element>`.
+- Its element file, if present, is `my-custom-element.html`.
+- Its script, if present, is `my-custom-element.browser.ts`.  The
+  `browser` segment is a safety feature, requiring the file to be
+  explicitly named as a browser file, to help prevent unfortunate
+  naming collisions where a server file happens to have the name of
+  a custom element and gets built into the browser bundle.
 
-#### Request state
+A custom element must have one or the other of an element file and a
+script, and it may have both.  If it has neither, the builder reports an
+error.
 
-The hub stamps these on the element that dispatched a request, which is the
-widget itself when a widget fired it.  A widget observes them and reacts; it
-must name them in `observedAttributes` to see them change.
+To use custom elements from a widget library, add the library to
+`imports.ts` anywhere in the builder's `--src`:
 
-| Attribute      | Written on              | Holds                                                                                   |
-| -------------- | ----------------------- | --------------------------------------------------------------------------------------- |
-| `lb-pending`   | The dispatching element | The round trip is in flight                                                             |
-| `lb-error`     | The dispatching element | The last round trip failed, cleared on the next — see [The round trip](#the-round-trip) |
-| `lb-row-count` | A list scope            | How many rows the scope is showing                                                      |
+```ts
+export default ["@scope/library-name"];
+```
 
-They are also stamped on plain HTML, where a stylesheet is the only
-consumer: dim a pending button, mark a failed one, and style an empty list
-against `lb-row-count` rather than carrying an empty-state element.
+Import every attribute name from `@loadbare/app/constants` — see
+[Constants](#constants).  Never write one as a string literal.
 
-The hub reads one of them.  A native `lb-action` element, a button or a
-form, that is performed again while it carries `lb-pending` is ignored: the
-click or submit is cancelled and nothing is sent.  A pending native action is
-therefore disabled in fact, and a stylesheet only has to show it.  A widget is
-not held back this way, because a widget that sends on change must have its
-latest value sent rather than dropped.
+### Controls
 
-Alongside `lb-pending` the hub sets `aria-busy="true"` on the same element and
-removes it when the round trip settles, so assistive technology hears the
-state a stylesheet shows.
+A form-associated custom element with a `value` property that fires
+`change` is a control.  The hub sets its `value` when a column lands, and
+gathers its `value` when a request is issued, exactly as for a native
+`<input>`.  It commits on `change`, and belongs to its form owner, which the
+browser tracks and the `form` attribute names.
 
-#### Row hooks
+```ts
+class NoteField extends HTMLElement {
+  static formAssociated = true;
+  // a `value` property, and a `change` event when the edit commits
+}
+```
+
+A custom element that is not a control receives `lb-column-value` and
+renders it; its content is never replaced.
+
+### Row hooks
+
+| Method                          | Implemented By | The hub calls it                                   |
+| ------------------------------- | -------------- | -------------------------------------------------- |
+| `lbPlaceRow(el, row, template)` | Developer      | To place a live row, detached, on its first arrival and whenever all rows decide the order |
+| `lbRowsLanded()`                | Developer      | After the rows land                                |
 
-| Name                            | Implemented By | Behavior                                                    |
-| ------------------------------- | -------------- | ----------------------------------------------------------- |
-| `applyRow(root, row)`           | Loadbare       | Fills one scope from one row                                |
-| `lbPlaceRow(el, row, template)` | Developer      | Optional on a list scope: where a row goes                  |
-| `lbRowsLanded()`                | Developer      | Optional on a list scope: scaffolding derived from the rows |
+The hub calls both on a custom element with `lb-query` and a row template.
+Both are optional.  The `RowsHost` interface in `@loadbare/app/types`
+declares them.
+
+`applyRow(root, row)`, exported by `@loadbare/app`, fills `root` from one
+row, the same operation that fills a live row.
 
 ## Internal linkage
 
@@ -1148,16 +1439,16 @@ Loadbare/app owns every file name and pattern in this table.  A file so
 named carries its meaning wherever it sits in the `--src` tree, so an
 application must not use one of these names for anything else.
 
-| File                    | How many               | Holds                                                    | Defined in                                              |
-| ----------------------- | ---------------------- | -------------------------------------------------------- | ------------------------------------------------------- |
-| `chrome.html`           | Exactly one            | The application's one HTML document                      | [Chrome](#chrome)                                       |
-| `imports.ts`            | Zero or one            | Default-exports an array of widget library package names | [Imported widget libraries](#imported-widget-libraries) |
-| `<stub>.page.html`      | One per page           | One page's markup, as a fragment                         | [Pages](#pages)                                         |
-| `<stub>.queries.ts`     | Zero or one per page   | That page's queries                                      | [Page Queries](#page-queries)                           |
-| `<stub>.requests.ts`    | Zero or one per page   | That page's requests                                     | [Page Requests](#page-requests)                         |
-| `<tag-name>.html`       | Zero or one per widget | One widget definition, as a fragment                     | [Widgets](#widgets)                                     |
-| `<tag-name>.browser.ts` | Zero or one per widget | One widget's script, `.js` also accepted                 | [Widgets](#widgets)                                     |
-| `*.css`                 | Any number             | A stylesheet, concatenated into `app.css`                | [Running the builder](#running-the-builder)             |
+| File                    | How many                       | Holds                                                    | Defined in                                              |
+| ----------------------- | ------------------------------ | -------------------------------------------------------- | ------------------------------------------------------- |
+| `chrome.html`           | Exactly one                    | The application's one HTML document                      | [Chrome](#chrome)                                       |
+| `imports.ts`            | Zero or one                    | Default-exports an array of widget library package names | [Imported widget libraries](#imported-widget-libraries) |
+| `<stub>.page.html`      | One per page                   | One page's markup, as a fragment                         | [Pages](#pages)                                         |
+| `<stub>.queries.ts`     | Zero or one per page           | That page's queries                                      | [Page Queries](#page-queries)                           |
+| `<stub>.requests.ts`    | Zero or one per page           | That page's requests                                     | [Page Requests](#page-requests)                         |
+| `<tag-name>.html`       | Zero or one per custom element | One element file, as a fragment                          | [Custom elements](#custom-elements)                     |
+| `<tag-name>.browser.ts` | Zero or one per custom element | One custom element's script, `.js` also accepted         | [Custom elements](#custom-elements)                     |
+| `*.css`                 | Any number                     | A stylesheet, concatenated into `app.css`                | [Running the builder](#running-the-builder)             |
 
 ### Build outputs
 
@@ -1169,7 +1460,7 @@ only when some origin has a stylesheet, `pages.ts` only when some page has a
 | Path               | Written           | Holds                                                              | Read by    | Defined in                                  |
 | ------------------ | ----------------- | ------------------------------------------------------------------ | ---------- | ------------------------------------------- |
 | `/app.html`        | Always            | The chrome, built                                                  | The server | [Chrome](#chrome)                           |
-| `/client.js`       | Always            | `<lb-hub>` and every widget the application uses                   | The chrome | [Chrome](#chrome)                           |
+| `/client.js`       | Always            | `<lb-hub>` and every custom element the application uses           | The chrome | [Chrome](#chrome)                           |
 | `/client-entry.ts` | Always            | The generated entry `client.js` is bundled from                    | Nothing    | [Running the builder](#running-the-builder) |
 | `/app.css`         | With a stylesheet | Every stylesheet in the cascade, concatenated                      | The chrome | [Chrome](#chrome)                           |
 | `/pages.ts`        | With page data    | The one `createHub()` call, over every page's queries and requests | The server | [The Express server](#the-express-server)   |
@@ -1179,57 +1470,64 @@ only when some origin has a stylesheet, `pages.ts` only when some page has a
 Loadbare/app owns every key in this table. A widget library declares them.
 An application never does.
 
-| Key                | Value                     | Means                                                                        | Defined in                                              |
-| ------------------ | ------------------------- | ---------------------------------------------------------------------------- | ------------------------------------------------------- |
-| `loadbare.widgets` | A path inside the package | Where this package's widgets are. Absent means the whole installed directory | [Imported widget libraries](#imported-widget-libraries) |
+| Key                | Value                     | Means                                                                                | Defined in                                              |
+| ------------------ | ------------------------- | ------------------------------------------------------------------------------------ | ------------------------------------------------------- |
+| `loadbare.widgets` | A path inside the package | Where this package's custom elements are. Absent means the whole installed directory | [Imported widget libraries](#imported-widget-libraries) |
 
 ### Reserved namespaces
 
 Loadbare/app owns every namespace in this table. Ownership of a name and
 ownership of its behavior are stated separately, because they differ.
 
-| Namespace | Applies to                 | Loadbare owns                                | Defined in                                      |
-| --------- | -------------------------- | -------------------------------------------- | ----------------------------------------------- |
-| `lb-*`    | HTML attributes            | The names and their behavior                 | [The lb-* namespace](#the-lb--namespace)        |
-| `exp-*`   | HTML attributes            | The behavior; widget authors pick the values | [Build time parameters](#build-time-parameters) |
-| `lb*`     | Methods on custom elements | The names and their behavior                 | [Row hooks](#row-hooks)                         |
+| Namespace | Applies to                                                  | Loadbare owns                                       | Defined in                                      |
+| --------- | ----------------------------------------------------------- | --------------------------------------------------- | ----------------------------------------------- |
+| `lb-*`    | Attributes, their values, queries, columns of `lb-` queries, requests, custom elements, events | The names and their behavior | [The lb-* namespace](#the-lb--namespace)        |
+| `exp-*`   | Attributes on a custom element                              | The behavior; element file authors pick the names   | [Build time parameters](#build-time-parameters) |
+| `lb*`     | Methods on custom elements                                  | The names and their behavior                        | [Row hooks](#row-hooks)                         |
 
 #### The lb-* namespace
 
-Every HTML attribute beginning with `lb-` belongs to Loadbare/app.  An
-application writes the ones this table names and invents none of its own,
-because a name Loadbare has not defined today it may define tomorrow.
-
-The prefix reaches past HTML.  A query name cannot begin with `lb-` either,
-which is what keeps the three operations apart from an application's own
-actions on the wire — see [Page Queries](#page-queries).
-
-Each attribute is defined in one section, and this table says which.
-
-| Attribute         | Written by    | Defined in                                          |
-| ----------------- | ------------- | --------------------------------------------------- |
-| `lb-list`         | Developer     | [Binding](#binding)                                 |
-| `lb-row`          | Developer     | [Binding](#binding)                                 |
-| `lb-cell`         | Developer     | [Binding](#binding)                                 |
-| `lb-show`         | Developer     | [Displaying by condition](#displaying-by-condition) |
-| `lb-key`          | Developer     | [Binding](#binding)                                 |
-| `lb-key-value`    | Hub           | [Binding](#binding)                                 |
-| `lb-value`        | Hub           | [How a value lands](#how-a-value-lands)             |
-| `lb-action`       | Developer     | [Requests](#requests)                               |
-| `lb-nav-link`     | Developer     | [Links](#links)                                     |
-| `lb-query-parm`   | Developer     | [Query parms](#query-parms)                         |
-| `lb-query-parm-push` | Developer  | [Query parms](#query-parms)                         |
-| `lb-pending`      | Hub           | [Request state](#request-state)                     |
-| `lb-error`        | Hub           | [Request state](#request-state)                     |
-| `lb-row-count`    | Hub           | [Request state](#request-state)                     |
-| `lb-unknown-page` | Developer     | [Chrome](#chrome)                                   |
-| `lb-slot`         | Widget author | [Slots and templates](#slots-and-templates)         |
-| `lb-template`     | Widget author | [Slots and templates](#slots-and-templates)         |
-| `lb-page`         | Builder       | [Pages](#pages)                                     |
-
-An attribute the builder does not recognize is left alone today.  Refusing
-one is on the list of validations still to land — see
-[The builder](#the-builder).
+Every name beginning with `lb-` belongs to Loadbare/app — see
+[Names](#names).  An application writes the attributes this section names,
+and invents none of its own, because a name Loadbare has not defined today
+it may define tomorrow.
+
+| Attribute         | Written by    | On                                  | Defined in                                    |
+| ----------------- | ------------- | ----------------------------------- | --------------------------------------------- |
+| `lb-query`        | Developer     | Any element                         | [Landing](#landing)                           |
+| `lb-column`       | Developer     | Any element                         | [Landing](#landing)                           |
+| `lb-show`         | Developer     | Any element but a `<template>`      | [Displaying by condition](#displaying-by-condition) |
+| `lb-request`      | Developer     | Any element                         | [Requests](#requests)                         |
+| `lb-url-link`     | Developer     | An `<a>`                            | [Links](#links)                               |
+| `lb-url-push`     | Developer     | An element with `lb-request`        | [Query parms](#query-parms)                   |
+| `lb-url-unknown`  | Developer     | A `<dialog>` inside `<lb-hub>`      | [An unknown page](#an-unknown-page)           |
+| `lb-exp-slot`     | Developer     | One element in an element file      | [Slots and templates](#slots-and-templates)   |
+| `lb-exp-template` | Developer     | An element file, and a `<template>` | [Slots and templates](#slots-and-templates)   |
+| `lb-column-value` | Hub           | Every element set from a column     | [How a column lands](#how-a-column-lands)     |
+| `lb-key-value`    | Hub           | A live row, and an element a `row` lands on | [Rows](#rows)                         |
+| `lb-query-row-count` | Hub        | An element with a row template      | [Rows](#rows)                                 |
+| `lb-request-pending` | Hub        | The element that issued a request   | [Request state](#request-state)               |
+| `lb-request-error`   | Hub        | The element that issued a request   | [Request state](#request-state)               |
+| `lb-show` on a `<template>` | Hub and builder | Where an absent element stands | [Displaying by condition](#displaying-by-condition) |
+| `lb-page`         | Builder       | A page's `<template>`               | [Page HTML](#page-html)                       |
+| `lb-page-title`   | Builder       | A page's `<template>`               | [Page HTML](#page-html)                       |
+
+The builder refuses any other `lb-` attribute in markup — see
+[The markup checks](#the-markup-checks).
+
+### Reserved queries
+
+| Query    | Kind  | Key       | Columns                                                         | Defined in          |
+| -------- | ----- | --------- | --------------------------------------------------------------- | ------------------- |
+| `lb-url` | `row` | `lb-path` | `lb-path`, `lb-page-label`, `lb-page-unknown`, every query parm | [The URL](#the-url) |
+
+### Reserved request names
+
+| Request name    | Runs under `crud` | Defined in                          |
+| --------------- | ----------------- | ----------------------------------- |
+| `lb-row-insert` | `rowInsert`       | [The request names](#the-request-names) |
+| `lb-row-update` | `rowUpdate`       | [The request names](#the-request-names) |
+| `lb-row-delete` | `rowDelete`       | [The request names](#the-request-names) |
 
 ### Reserved tags
 
@@ -1245,16 +1543,53 @@ never defines them.
 Loadbare/app owns every DOM event in this table, both the name and what its
 `detail` carries.
 
-| Event        | Dispatched from        | Bubbles | Cancelable | Defined in                              |
-| ------------ | ---------------------- | ------- | ---------- | --------------------------------------- |
-| `lb-request` | The element that acted | Yes     | No         | [The request event](#the-request-event) |
-
-### Reserved attributes
-
-Loadbare/app owns every attribute in this table, both the name and its
-behavior.
-
-| Attribute         | Written on                          | Takes a value | Defined in        |
-| ----------------- | ----------------------------------- | ------------- | ----------------- |
-| `lb-unknown-page` | A `<dialog>` in chrome              | No            | [Chrome](#chrome) |
-| `lb-page`         | A `<template>`, by the builder only | Yes           | [Pages](#pages)   |
+| Event        | Dispatched from                  | Bubbles | Cancelable | Defined in                              |
+| ------------ | -------------------------------- | ------- | ---------- | --------------------------------------- |
+| `lb-request` | The element that committed       | Yes     | No         | [The request event](#the-request-event) |
+
+### Reserved methods
+
+| Method         | On                                                 | Defined in              |
+| -------------- | -------------------------------------------------- | ----------------------- |
+| `lbPlaceRow`   | A custom element with `lb-query` and a row template | [Row hooks](#row-hooks) |
+| `lbRowsLanded` | A custom element with `lb-query` and a row template | [Row hooks](#row-hooks) |
+
+### Constants
+
+`@loadbare/app/constants` exports every name above.  Custom element code
+imports them rather than writing a string.
+
+| Constant                  | Value                                   |
+| ------------------------- | --------------------------------------- |
+| `ATTR_QUERY`              | `lb-query`                              |
+| `ATTR_COLUMN`             | `lb-column`                             |
+| `ATTR_SHOW`               | `lb-show`                               |
+| `ATTR_COLUMN_VALUE`       | `lb-column-value`                       |
+| `ATTR_KEY_VALUE`          | `lb-key-value`                          |
+| `ATTR_QUERY_ROW_COUNT`    | `lb-query-row-count`                    |
+| `ATTR_REQUEST`            | `lb-request`                            |
+| `ATTR_REQUEST_PENDING`    | `lb-request-pending`                    |
+| `ATTR_REQUEST_ERROR`      | `lb-request-error`                      |
+| `ATTR_URL_LINK`           | `lb-url-link`                           |
+| `ATTR_URL_PUSH`           | `lb-url-push`                           |
+| `ATTR_URL_UNKNOWN`        | `lb-url-unknown`                        |
+| `ATTR_EXP_SLOT`           | `lb-exp-slot`                           |
+| `ATTR_EXP_TEMPLATE`       | `lb-exp-template`                       |
+| `ATTR_PAGE`               | `lb-page`                               |
+| `ATTR_PAGE_TITLE`         | `lb-page-title`                         |
+| `DEVELOPER_ATTRIBUTES`    | The seven attributes a developer writes |
+| `LB_EVENT_NAME`           | `lb-request`                            |
+| `LB_RESERVED_PREFIX`      | `lb-`                                   |
+| `REQUEST_ROW_INSERT`      | `lb-row-insert`                         |
+| `REQUEST_ROW_UPDATE`      | `lb-row-update`                         |
+| `REQUEST_ROW_DELETE`      | `lb-row-delete`                         |
+| `LB_ROW_REQUESTS`         | All three request names                 |
+| `KIND_ROW`                | `row`                                   |
+| `KIND_ROWS`               | `rows`                                  |
+| `URL_QUERY`               | `lb-url`                                |
+| `URL_COLUMN_PATH`         | `lb-path`                               |
+| `URL_COLUMN_PAGE_LABEL`   | `lb-page-label`                         |
+| `URL_COLUMN_PAGE_UNKNOWN` | `lb-page-unknown`                       |
+| `HUB_TAG_NAME`            | `lb-hub`                                |
+| `LB_ENDPOINT`             | `/lb`                                   |
+| `LB_REQUEST_TIMEOUT_MS`   | `10000`                                 |