@loadbare/app 0.8.2 → 0.10.0

package/docs/testing.md

@@ -49,8 +49,8 @@ application override a built-in.
 ## The console is an interface
 
 The browser half of Loadbare App reports every failure it survives through
-`console.error` and `console.warn` — a query with no scope, a list widget
-with no template, a change event with no coordinates. These are not
+`console.error` and `console.warn` — a query nothing names, a row with no
+key column, a request missing what it needs. These are not
 diagnostics. They are the framework's entire error channel on the client, and
 the behavior under test is frequently *that Loadbare reported and carried on*
 rather than that it produced a value.
@@ -71,11 +71,23 @@ the most of what Loadbare promises, so it is first.
 - `exp-foo` supplied to a definition with no `{{foo}}`
 - `{{camelCase}}` in a definition, which no tag could ever supply
 - a cycle in the definition graph
-- two `lb-template` destinations with one name
+- two `lb-exp-template` destinations with one name
 - two authored templates for one destination
 - a template naming a destination the definition does not have
-- content written inside a definition with no `lb-slot`
-- more than one `lb-slot`
+- content written inside a definition with no `lb-exp-slot`
+- more than one `lb-exp-slot`
+
+**Markup checks.** The assembled chrome and every page are checked before
+anything ships:
+
+- an `lb-` attribute that is not one the developer writes
+- `lb-request="lb-…"` naming none of the requests Loadbare provides
+- `lb-url-link` off an `<a>`, `lb-url-push` without `lb-request`, and
+  `lb-url-unknown` off a `<dialog>` or outside `<lb-hub>`
+- `lb-show` on a `<template>`, on a row template's root, or with no row
+  around it
+
+A page file's `<title>` is lifted out and stamped as `lb-page-title`.
 
 **Substitution.** An unset placeholder drops the attribute rather than
 emitting it empty, which is what HTML's boolean attributes require and what
@@ -113,48 +125,59 @@ needs a browser either.
 `server/lb-server.ts` opens a socket, so the fixtures are counting stubs.
 
 - `onPageEnter` runs before any query, and the whole query set runs after it
-- an unknown page answers `{}` and says so
+- an unknown page answers `[]` and says so
+- every answer goes out as a response item carrying the kind and key its
+  query declared; an answer of the wrong kind is left out and reported
 - an unknown query name in a refresh set is skipped, and its siblings run
-- an action the page did not declare is refused — the rule that keeps the
-  wire from reaching anything the page has not published
-- the refresh set runs after the action, against the same context
-- **what the action stated wins over what the refresh produced**, because
+- a declared request the page did not declare under `handlers`, and a row
+  request with no `crud` entry for its query, are refused — the rule that
+  keeps the wire from reaching anything the page has not published
+- a reserved name declared as a query or a handler is refused at startup
+- the refresh set runs after the handler, against the same context
+- what the handler stated wins over what the refresh produced, because
   that is how a `patch` reaches the browser at all, and it is one spread
   operator away from silently reversing
+- a handler returning `url()` answers with the `lb-url` item alone, and runs
+  no refresh set
 
 `tests/lb-express.test.ts` runs against a listening app: the page comes from
-the query string, an undeclared operation is refused with a 400, and a
+the path, the query parms reach `contextFor`, a `url()` answer is followed by
+the page loaded at the new URL, an undeclared request is refused, and a
 malformed body does not throw.
 
 ## Tier 3 — Landing
 
-`applyData`, `applyRow` and `applyList` are the most intricate code in the
-framework and the most likely to break in ways nobody notices. They are also
-pure DOM: no fetch, no widget upgrade, no history. jsdom is real evidence
-here.
-
-- a native element receives its value as text, a hyphenated one as `lb-value`
-- the root of a scope counts as a cell if it carries one, which is what makes
+`applyResponse`, `applyRow` and `applyRows` are the most intricate code in
+the framework and the most likely to break in ways nobody notices. They are
+also pure DOM: no fetch, no custom element upgrade, no history. jsdom is real
+evidence here.
+
+- a control receives its value as `value`, any other native element as text,
+  a custom element that is not a control as `lb-column-value` alone, and
+  every one carries `lb-column-value`
+- the four combinations of kind and row template: a `row` with no row
+  template lands on the element itself and stamps its `lb-key-value`
+- a live row's root counts as a column if it carries one, which is what makes
   an `<option>` row possible
-- an element carrying both a scope and `lb-cell` is a cell of the row around
-  it, and the cells inside it are its own scope's
-- a query with no scope is reported and skipped; several scopes for one query
-  are all filled; a set of rows landing on a scope bound with `lb-row`
-  is reported rather than thrown
-- `rows` decides membership and order, so a key that did not arrive is gone
-- `patch` disturbs only what it names, in contents and in position
-- `lb-row-count` is counted from the DOM after reconciliation, so a set and a
-  patch ending in the same state report the same number
-- the `place` callback is called for a fresh row always, and for an existing
-  row only under `rows`. That is today's behavior, not a decision — a patch
-  therefore never re-places a row whose sort key changed. The test states what
-  is true now, and is the one that flips if that changes.
-
-**Two properties**, written as loops rather than with a library. Applying the
-same set twice is applying it once. And a set reached through any
-sequence of patches is that set reached from empty. Convergence is the
-actual contract of a reconciler, and those two say it better than twenty
-examples.
+- an element carrying both `lb-query` and `lb-column` takes its column from
+  the row around it, and the columns inside it are its own query's
+- a query nothing names is reported and skipped; several elements naming one
+  query are all filled
+- all rows decide membership and order, so a key that did not arrive is gone
+- a patch disturbs only what it names, in contents and in position
+- `lb-query-row-count` is counted from the DOM after reconciliation, so all
+  rows and a patch ending in the same state report the same number
+- `lbPlaceRow` is called for a fresh row always, and for an existing row
+  only under all rows. That is today's behavior, not a decision — a patch
+  therefore never re-places a row whose sort key changed. The test states
+  what is true now, and is the one that flips if that changes.
+- `lb-show` moves an element into a template and back, and landing reaches
+  inside it
+
+Two properties, written as loops rather than with a library. Applying the
+same rows twice is applying them once. And rows reached through any sequence
+of patches are those rows reached from empty. Convergence is the actual
+contract of a reconciler, and those two say it better than twenty examples.
 
 ## Tier 4 — The hub
 
@@ -179,41 +202,47 @@ help.
 
 What the hub is tested for here:
 
-- `requestFor` builds each of the three operations a native element can
-  send, and refuses a reserved name it cannot turn into one
-- a click finds the nearest `lb-action`, and skips a hyphenated tag and a
-  form, both of which own the interaction themselves
-- a submit gathers the form's cells, and reports a cell with no control
-- an insert or update gathers the nearest form, `<tr>` or live row inside
-  its scope, whatever shares the button's cell: one ghost row among its
-  neighbours, a whole live row, a form nested in a row, a button's form
-  owner; and refuses a `<div>` holding cells, pointing to `<form>`
-- an insert or update from an element carrying `lb-cell` sends that cell
-  alone, from the value a widget sent or else its control; refuses a value
-  with no `lb-cell` to name its column; and refuses a click on a native
-  element that is a cell
-- gathering skips the cells of a nested scope, so a picker in a row sends
-  its own cell and nothing about its options
-- a request arriving with no action, or with a reserved name that is not one
-  of the three, is refused before it reaches the wire
-- `lb-pending` lands on the element that dispatched, `lb-error` replaces it
-  on failure, and the next request clears it
-- `aria-busy` comes and goes with `lb-pending`; a native button or form
-  performed again while pending sends nothing, and a widget still sends
-- a path with no page host reports and opens the unknown-page dialog; two
-  hosts for one name report and take the first
-- `lb-navigation` lands with the path and the label of the link that names it
-- `lb-nav-link` pushes state and swaps the host, `popstate` reverses it, and
-  an ordinary anchor is left alone
+- an element commits on its own event: a form on `submit`, a control on
+  `change`, anything else on `click`; a submit button with a form owner
+  never commits on click, and the submitter's `lb-request` wins over the
+  form's
+- gathering follows the order: an element with `lb-column` alone, a
+  `<form>`'s controls, a live row's controls, the form owner's controls,
+  including controls joined by the `form` attribute and form-associated
+  custom elements
+- gathering skips the controls of a nested `lb-query`, so a picker in a row
+  sends its own column and nothing about its options
+- the request goes to the nearest ancestor `lb-query` of what was gathered,
+  and takes `key` from the nearest ancestor row of that query
+- `lb-row-insert`, `lb-row-update` and `lb-row-delete` missing what they
+  need are not sent, and a reserved name that is not one of the three is
+  refused before it reaches the wire
+- an ancestor may stop the `lb-request` event, and a request is complete
+  before an ancestor sees it
+- `lb-request-pending` lands on the element that committed,
+  `lb-request-error` replaces it on failure, and the next request clears
+  it; `aria-busy` comes and goes with `lb-request-pending`, and a commit on
+  a pending element is ignored
+- a successful insert gathered from a form resets the form
+- a path with no page reports, lands `lb-page-unknown`, and opens the
+  `lb-url-unknown` dialog; two pages for one stub report and take the first
+- `lb-url` lands with the path, the page's `lb-page-title` or stub as
+  `lb-page-label`, and a column per query parm, and sets the document title
+- `lb-url-link` pushes state and swaps the page on a plain primary click,
+  `popstate` reverses it, and an ordinary anchor is left alone
+- a control inside `lb-query="lb-url"` writes its parm, replacing the history
+  entry or pushing one with `lb-url-push`, and the page's queries reload
+- an `lb-url` item in a server answer writes the URL and lands the page
+  loaded there
 - `hidden` comes off the body once a page has landed, including the page
   that failed to load
 
 Widgets are small and their logic is local, so jsdom carries them: a value
-reaches the control the widget owns, a change dispatches the declared action,
-an absent control or absent action is reported rather than thrown,
-`lb-options` turns a key into a value and removes an emptied `<optgroup>`,
-`lb-table` groups and sorts, removes an emptied section heading, and takes
-its `colSpan` from the row template the page wrote.
+reaches the control the widget owns, the widget is a form-associated control
+the hub commits and gathers, `lb-options` turns a key into a value and
+removes an emptied `<optgroup>`, `lb-table` groups and sorts, removes an
+emptied section heading, and takes its `colSpan` from the row template the
+page wrote.
 
 A widget extends `HTMLElement` and registers itself as its module loads, so
 unlike tier 3 it needs a window before the module exists. `installWindow()`

package/docs/theory.md

@@ -425,33 +425,45 @@ database, but it does force server code to return data in the shapes of
 rows and sets of rows.
 
 That scoping decision allowed us to reduce the data binding vocabulary
-to four foundations:
-
-| Attribute | Relational idea | HTML precedent                                     |
-| --------- | --------------- | -------------------------------------------------- |
-| `lb-list` | A set of rows   | `<select>` or `<ul>`, a container of its items     |
-| `lb-row`  | A single row    | `<form>`, one record of fields                     |
-| `lb-cell` | A column        | `name` on a form control, which field this is      |
-| `lb-key`  | The primary key | `value` on an `<option>`, identity apart from text |
+to one idea: everything is a query.  A query is a name for rows, of kind
+`row` or `rows`, with a key.  The server declares all three facts about a
+query, so the markup names the query and the columns it shows, and
+repeats nothing the server already said.  Three attributes carry the whole
+of it:
+
+| Attribute   | Relational idea            | HTML precedent                                 |
+| ----------- | -------------------------- | ---------------------------------------------- |
+| `lb-query`  | A query, one row or many   | `<select>` or `<form>`, a container of records |
+| `lb-column` | A column                   | `name` on a form control, which field this is  |
+| `lb-show`   | A column deciding presence | `hidden`, whether an element is shown          |
+
+The key never appears in the markup.  The server declares it with the
+query, `rows("id", run)`, and the hub stamps each live row with its
+value as `lb-key-value`, the way an `<option>` carries a `value` apart
+from its text.
 
 A highly simplified page showing
 an invoice and its lines looks like this:
 
 ```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>
+  <tbody lb-query="invoiceLines">
+    <template>
+      <tr><td lb-column="item"></td><td lb-column="amount"></td></tr>
     </template>
   </tbody>
 </table>
 ```
 
+`invoice` is of kind `row`, and with no row template inside it the row
+lands on the `<section>` itself.  `invoiceLines` is of kind `rows`, and
+the hub clones the row template once per row.
+
 This decision proved decisive in keeping the browser code robust,
 expressive, and performant.
 
@@ -465,45 +477,58 @@ The idea is that user interaction triggers framework browser code
 that "knows what to do", assembling a request driven purely from
 attributes. 
 
-This requirement is satisfied with a single new attribute, `lb-action`.
-Three values are reserved, and any other value is interpreted as the
-name of a routine on the server.
+This requirement is satisfied with a single new attribute, `lb-request`.
+Three request names are Loadbare's: `lb-row-insert`, `lb-row-update` and
+`lb-row-delete`.  Any other value names a request the page declares on
+the server.
 
-A request is an action and a position.  The author writes the action,
-and the hub supplies the position from the document, using the same
-ancestor rule that decides where a value lands.  To add a delete
-button to the invoice lines from the previous section, the template
-gains one element:
+A request is a name and a position.  The author writes the name, and
+the hub supplies the position from the document, using the same
+ancestor rule that decides where a value lands.  An element commits the
+way HTML already says it does: a form on `submit`, a control on
+`change`, anything else on `click`.  To add a delete button to the
+invoice lines from the previous section, the row template gains one
+element:
 
 ```html
-<template lb-key="id">
+<template>
   <tr>
-    <td lb-cell="item"></td>
-    <td lb-cell="amount"></td>
-    <td><button lb-action="lb-row-delete">Remove</button></td>
+    <td lb-column="item"></td>
+    <td lb-column="amount"></td>
+    <td><button lb-request="lb-row-delete">Remove</button></td>
   </tr>
 </template>
 ```
 
-The button names neither the list nor the key.  When it is clicked,
-the hub reads `invoiceLines` from the nearest list scope and the key
-from the live row around the button, and sends:
+The button names neither the query nor the key.  When it is clicked,
+the hub reads `invoiceLines` from the nearest ancestor `lb-query` and
+the key from the live row around the button, and sends:
 
 ```
-{ action: "lb-row-delete", list: "invoiceLines", key: "42" }
+{ name: "lb-row-delete", query: "invoiceLines", key: "42" }
 ```
 
+Every request has that one shape: a name, and `query`, `key` and
+`values` as present.  An insert or update gathers `values` from the
+controls around the element that committed: a form's controls, a live
+row's, or the controls whose form owner is the element's.
+
 But we need to be more modern than that.  Nowadays we expect the
 button to be disabled after it is clicked, and to display a wait
 state in case the network is congested.  In other words, the 
 framework browser code needs to notify the event target of its
 request state.
 
-To do this, framework browser code writes three attributes about a request, `lb-pending`,
-`lb-error` and `lb-row-count`.  The framework browser code ignores
-a button or form performed again while stamped with `lb-pending`,
-meaning the disabled state can be represented entirely by CSS, no
-JavaScript needed.
+To do this, framework browser code stamps two attributes about a
+request, `lb-request-pending` and `lb-request-error`, and a third about
+a query, `lb-query-row-count`.  The framework browser code ignores a
+commit on an element stamped with `lb-request-pending`, meaning the
+disabled state can be represented entirely by CSS, no JavaScript
+needed.
+
+The developer writes `lb-*` attributes in markup, and script never
+assigns them.  The hub and the builder write only their stamps.  That
+rule is what lets the builder check the markup once, at build time.
 
 Over many iterations I gradually reduced the core attributes to 
 these, from a larger set that had more overlapping behaviors and edge
@@ -524,24 +549,30 @@ chrome and ships it as `app.html`.  With all pages already present
 in the browser, providing an SPA is fairly simple.
 
 The hub catches anchor clicks, and checks if the anchor contains the
-attribute `lb-nav-link`.  If so, the hub interprets it as in-app
-navigation, swaps the anchor's `href` into `<main>`, and sends a request
-to the server for the page data.  The query string rides along, so the
-server always knows what URL the browser is showing.
+attribute `lb-url-link`.  If so, the hub interprets a plain primary
+click as in-app navigation, shows the page the `href` names in
+`<main>`, and sends a request to the server for the page data.  The
+query string rides along, so the server always knows what URL the
+browser is showing.
 
 Anchors without the attribute behave as normal links.
 
 #### Synthetic Context
 
 Synthetic context emerged as a useful feature near the very end of
-development.  Realizing that the hub knows about the current
-navigation state, we had it publish a syntheic query result,
-`lb-navigation`, that contains the URI and, if it can find it,
-the anchor text for any link to that URI.
-
-These can be bound to any HTML, same as any other query sent by
-the application, but the resulting values are always supplied by
-the hub.
+development.  Realizing that the hub knows about the current URL, we
+had it serve a query of its own, `lb-url`, of kind `row` and keyed by
+`lb-path`.  Its columns are the path, the page's title as
+`lb-page-label`, whether the path names no page as `lb-page-unknown`,
+and one column per query parm.
+
+These can be bound to any HTML, same as any other query the
+application declares, but the hub supplies the row.  The hub also
+answers requests for it: a control writing a query parm is
+`<input lb-column="q" lb-request="lb-row-update">` inside
+`lb-query="lb-url"`, an ordinary row update that the hub answers by
+writing the URL and reloading the page's queries.  A handler on the
+server moves the URL the same way, by returning `url({ q: "5" })`.
 
 There may be more synthetic context in the future.
 
@@ -562,8 +593,10 @@ files that share a name: `invoice.page.html`, `invoice.queries.ts`
 and `invoice.requests.ts`.  The HTML is the page as the user sees it,
 the queries provide the data, and the requests are what it allows.
 
-Each query is declared as a row or a list, the same two shapes the
-HTML binds to.  Each request declares the work it does and the
+Each query is declared with `row(key, run)` or `rows(key, run)`,
+naming its kind and its key.  Every response carries response items,
+each naming its query, kind and key beside the row, the rows, or a
+patch.  Each request declares the work it does and the
 queries to run again afterward.  Here is the delete button from
 Requests and Request State, as the server sees it:
 
@@ -575,9 +608,9 @@ export const requests: Requests = {
   crud: {
     invoiceLines: {
       rowDelete: {
-        run: async (ctx, where) => {
-          await ctx.db.deleteLine(where.key);
-          return { invoiceLines: patch({ drop: [where.key] }) };
+        run: async (ctx, { key }) => {
+          await ctx.db.deleteLine(key);
+          return { invoiceLines: patch({ drop: [key] }) };
         },
         refresh: ["invoice"],
       },
@@ -587,14 +620,15 @@ export const requests: Requests = {
 ```
 
 Deleting a line changes the invoice total, so the entry refreshes
-`invoice`.  The list itself does not need to be queried again, since
+`invoice`.  `invoiceLines` itself does not need to be queried again, since
 the only change is one row that went away, and `run` says so with a
-patch.  The response carries both: the refreshed invoice row, and the
-patch that removes one line.
+patch.  The response carries two response items: the refreshed invoice
+row, and the patch that removes one line.
 
 Loadbare, as it turns out, does not have "endpoints" as such.  If the
-HTML scopes an `lb-row-delete` to `lb-list="invoice_lines"`, then the
-server carries a CRUD entry `rowDelete` under object invoiceLines.
+HTML places an `lb-row-delete` inside `lb-query="invoiceLines"`, then the
+server carries a CRUD entry `rowDelete` under object invoiceLines.  A
+declared request is the same, keyed by its name under `handlers`.
 Since the browser and server exist to talk to each other in the same
 language, no additional abstraction is needed.
 
@@ -727,7 +761,7 @@ has been made to make them "set and forget".
 
 Second, Loadbare is missing entire categories of developer effort,
 while providing expected benefits.  HTML includes without imports,
-declarative browser data binding and actions, free tree shaking,
+declarative browser data binding and requests, free tree shaking,
 extendable with custom elements, a small set of mechanisms, and 
 nothing to learn about the "the Loadbare way for CSS", among many
 others.

package/docs/tutorials/010-pages-and-navigation.md

@@ -21,21 +21,28 @@ a page specified, Loadbare displays `index.page.html`.
 
 ```html
 <!-- src/pages/index.page.html -->
+<title>Home</title>
 <h1>Home</h1>
 <p>This is the home page.</p>
 ```
 
 ```html
 <!-- src/pages/about.page.html -->
+<title>About</title>
 <h1>About</h1>
 <p>This is the about page.</p>
 ```
 
+A page file's `<title>` names the page.  The builder removes it from the
+page and keeps its text, and the hub sets the document title to it whenever
+the page is showing.  A page without a `<title>` is named by its stub, the
+filename less `.page.html`.
+
 ## Linking between them
 
 Add a `<nav>` to the chrome, with one anchor per page.  
 
-Also add the `<dialog lb-unknown-page>` element, so the hub `<lb-hub>` can
+Also add a `<dialog lb-url-unknown>` element, so the hub `<lb-hub>` can
 display something to the user if they type a URL that has no matching page.
 
 ```html
@@ -52,32 +59,33 @@ display something to the user if they type a URL that has no matching page.
     <lb-hub>
       <nav>
         <!-- a bare link to "/" goes to page "index" -->
-        <a href="/" lb-nav-link>Home</a>
-        <a href="/about" lb-nav-link>About</a>
+        <a href="/" lb-url-link>Home</a>
+        <a href="/about" lb-url-link>About</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>
 ```
 
-Here we introduce the attribute `lb-nav-link`, which indicates the link
+Here we introduce the attribute `lb-url-link`, which indicates the link
 should navigate within the app.  When the user clicks, the hub `<lb-hub>`
 intercepts the event and swaps the page's HTML into the `<main>` element. 
 The hub ensures the back button works by calling `history.pushState` on 
 navigation, and catching the browser's `popstate` event.  
 
-An anchor without `lb-nav-link` is left alone and behaves like an ordinary
-link.
+An anchor without `lb-url-link` is left alone and behaves like an ordinary
+link, and so is a click with a modifier key or a middle click, which opens
+a new tab as usual.
 
-If a `<dialog lb-unknown-page>` element is present in the HTML, it will be
+If a `<dialog lb-url-unknown>` element is present in the HTML, it will be
 displayed to the user when a URL is entered that has no matching page in the app.
-The `lb-row` and `lb-cell` attributes will be explained when we get to data
-binding; for now, know that `lb-navigation` is a query the hub itself answers
-on every navigation, and `page-uri` is the path and query string that were
+The `lb-query` and `lb-column` attributes will be explained when we get to data
+binding; for now, know that `lb-url` is a query the hub itself serves, one
+row describing the URL, and its column `lb-path` is the path that was
 asked for.  The
 widget library ships this dialog ready-made as `<lb-unknown-page>`, which
 [Using Widget Libraries](./090-using-widget-libraries.md) covers.

package/docs/tutorials/020-css.md

@@ -42,6 +42,7 @@ Use the class in the page:
 
 ```html
 <!-- src/pages/about.page.html -->
+<title>About</title>
 <h1>About</h1>
 <p class="about-note">This is the about page.</p>
 ```
@@ -65,11 +66,13 @@ Add the stylesheet link to the chrome:
   <body hidden>
     <lb-hub>
       <nav>
-        <a href="/" lb-nav-link>Home</a>
-        <a href="/about" lb-nav-link>About</a>
+        <a href="/" lb-url-link>Home</a>
+        <a href="/about" lb-url-link>About</a>
       </nav>
       <main></main>
-      <dialog lb-unknown-page>The page <span lb-cell="page"></span> is not in this app.</dialog>
+      <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>

package/docs/tutorials/030-html-decomposition.md

@@ -33,14 +33,16 @@ element, not yet defined:
     <lb-hub>
       <!-- replace this from the previous tutorial...
       <nav>
-        <a href="/" lb-nav-link>Home</a>
-        <a href="/about" lb-nav-link>About</a>
+        <a href="/" lb-url-link>Home</a>
+        <a href="/about" lb-url-link>About</a>
       </nav>
       -->
       <!-- ...with this empty custom element: -->
       <app-nav></app-nav>
       <main></main>
-      <dialog lb-unknown-page>The page <span lb-cell="page"></span> is not in this app.</dialog>
+      <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>
@@ -51,8 +53,8 @@ of `<app-nav>` by writing `src/app-nav.html`.
 
 ```html
 <nav>
-    <a href="/" lb-nav-link>Home</a>
-    <a href="/about" lb-nav-link>About</a>
+    <a href="/" lb-url-link>Home</a>
+    <a href="/about" lb-url-link>About</a>
 </nav>
 ```
 
@@ -62,8 +64,8 @@ into the `<app-nav>` custom element, so the actual result will look like this:
 ```html
       <app-nav>
         <nav>
-          <a href="/" lb-nav-link>Home</a>
-          <a href="/about" lb-nav-link>About</a>
+          <a href="/" lb-url-link>Home</a>
+          <a href="/about" lb-url-link>About</a>
         </nav>
       </app-nav>
 ```