staffa 0.13.0 → 0.15.0

package/README.md

@@ -154,11 +154,11 @@ The first key that matches wins, and a segment a param refuses simply doesn't ma
 
 **Navigating is just links.** Write ordinary `<a href="/...">` links; Staffa handles the clicks (so don't also call Aberdeen's `interceptLinks()`).
 
-The open panels form a **stack**, and one of them is the **current** panel: the one the URL names, and the rightmost column on screen. Usually that's the newest panel — but going back along the stack moves the cursor without closing anything (see the breadcrumbs below), so panels can sit *after* the current one too, parked just past the viewport's right edge.
+The open panels form a **stack**, and its last panel is the **current** one: the panel the URL names, and the rightmost column on screen. Whatever you navigate to lands there.
 
-- A link inside a panel opens its target on top of that panel, closing everything after it first. That's why clicking a second project replaces the open project instead of adding a third column — and why the panels you'd browsed past don't pile up.
-- A `data-panel` attribute on the link picks a different one of the three navigations. `push` is the default just described; `replace` puts the target in place of the link's own panel rather than on top of it, which is what prev/next buttons want; and `open` leaves that panel behind altogether and gives the target its own stack, exactly as a nav item would — for a link that points somewhere else in the app, a search hit or a mention, where the panel you clicked from isn't the context you want to keep.
-- A link to something that's already open goes back to it instead of opening it twice — a move along the stack, closing nothing. The same path is never in the stack twice.
+- A link inside a panel opens its target on top of that panel, closing everything after it first. That's why clicking a second project replaces the open project instead of adding a third column.
+- A `data-panel` attribute on the link picks a different one of the three navigations, which differ only in how much of the link's own context the target keeps: `push` (the default just described) keeps the link's panel and builds on it; `replace` keeps everything under that panel but not the panel itself — what prev/next buttons want; and `open` keeps none of it, giving the target its own stack exactly as a nav item would — for a search hit or a mention, where the panel you clicked from is coincidence, not context.
+- A plain link to something that's already open goes back to it instead of opening it twice, closing whatever was stacked on top of it; a `replace` or `open` applies its usual shape instead, the open panel moving into place with its state intact. Either way the same path is never in the stack twice.
 - A link that isn't inside a panel (a nav item, or one in a dialog) has no panel to build on, so it replaces the stack as a whole: the panel you asked for, with its ancestor panels opened beneath it (see [below](#ancestors)). Panels that the new stack also contains stay as they are, so clicking the nav item for the section you're already in won't reset it. Clicking a nav item and opening that same URL in a fresh tab therefore give you the same columns.
 
 **The stack is an object, not a global.** In routed mode `S.main()` hands back the panel stack, and every panel gets the same object as `$panel.stack` — which is what a route handler uses, since it runs while the `S.main()` call is still going and can't see its return value yet.
@@ -180,21 +180,24 @@ Navigations settle asynchronously (closes travel through the browser's history),
 
 Navigating faster than the shell can settle is fine: closing travels through the browser's history, so it takes a moment to land, and anything asked for in the meantime waits for it rather than being dropped. Two quick Escapes (or back gestures) peel two panels, each aimed at the stack the one before it was heading for.
 
-**Every panel must work at 360–540px**, because that is what it gets whenever two columns fit. `$panel.maxWidth` says how much *more* it can usefully take. The content area is what `S.main()`'s `fullWidth` says it is — 1080px by default:
+**The content area is the window**, minus the nav sidebar — or, when `S.main({ maxWidth })` says so, that much of it, centred. Either way it is the same width whatever is open, so the sidebar, the top bar and the footer never move.
+
+The shell divides that area into columns: the narrowest whole number of them that keeps each one at least **360px** wide, and no column ever wider than **540**. (A content area narrower than 360 still gets one column — just a narrower one.) A 1080px content area is three columns of 360; a 1520px one is four of 380; below 720px there is a single column — of at most 540, centred. `$panel.maxWidth` counts in those columns:
 
 | `maxWidth` | How wide the panel gets | Good for |
 | --- | --- | --- |
-| `"half"` | Half the content area: 360 to 540px. | lists, detail forms — anything that reads well at phone width |
-| `"full"` (default) | The whole content area: up to 1080px. | ordinary screens; the safe default |
-| `"screen"` | The whole window, no upper limit: ~1720px on a 1920px screen. | boards, wide tables, dense dashboards |
+| `"small"` | One column — never above 540px. | lists, detail forms — anything that reads well at phone width |
+| `"medium"` (default) | Two columns — never above 1080px. | ordinary screens; the safe default |
+| `"large"` | Three columns — never above 1620px. | wide tables, dense forms |
+| `"none"` | The whole content area, unbounded. | boards, dashboards |
 
-Below the width two columns need, everything takes the whole content area whatever it asked for. Nothing fits beside a `"full"` on a standard page, but on a wide enough window a `"half"` still can, and the page grows to hold both.
+The ask is a promise about the top end: the shell never draws a panel wider than its column count × 540px, and every size is also capped at the content area — so a draw function never has to look right past its own ceiling. At the bottom end there is no promise, because a window can be any width: aim your layout at **360px**, which is about the narrowest phone still in common use, and let it degrade gracefully below that (`min-width` on a fixed-size block, a table that has to scroll) rather than assuming a floor.
 
-The standard page is those 1080px plus the nav sidebar's 200 — the 1280px an app is usually seen at, though neither figure is fixed: `S.main({ navWidth, fullWidth })` sets both, and everything above follows from them.
+A column's width depends only on the size of the window, never on what else is open. So opening or closing a panel never resizes the ones already on screen, and never reflows what someone was reading. As many columns as fit are shown, ending at the current panel; when they don't fill the content area they sit centred in it, so an arriving column nudges the others over to share the room.
 
-A column's width depends only on the size of the window, never on what else is open. So opening or closing a panel never resizes the ones already on screen, and never reflows what someone was reading. A lone `"half"` leaves its other half empty, and that is exactly where the next one lands. When more columns fit than the standard page holds (three halves, say), the page itself grows, staying centred, to hold them — though the top bar and footer keep to the standard width, so the chrome holds still while the columns come and go.
+`S.main({ navWidth, maxWidth })` sets the sidebar's width and the cap. Leave `maxWidth` off and the app simply fills the window — worth capping (`"1600px"`, say) if you'd rather it didn't march across a 4K display.
 
-Columns tile that area, separated by a hairline and no gutter — a column brings its own padding, so their contents stay comfortably apart regardless.
+Columns tile the area they're given, separated by a hairline and no gutter — a column brings its own padding, so their contents stay comfortably apart regardless.
 
 The panel is sized before your handler runs, and `$panel.width` is the resolved figure in pixels — so a chart, a virtualised list or a column count has the real width from the first frame, with nothing to measure. Set `maxWidth` at the top of your handler and you draw at the new width; set it later and the panel reflows without being redrawn, so nothing in it is rebuilt or loses its state.
 
@@ -212,11 +215,11 @@ function drawTask($panel: S.Panel<{ taskId: number }>) {
 
 On a wide screen the title becomes the stack's last crumb and the Save button sits in a quiet strip at the top of the column. On a phone the crumb is still there and Save moves into the top bar, where the app menu was. Nothing in your code measures the viewport, and no screen is written twice.
 
-**The breadcrumbs are the navigation.** The top bar's second line writes the open panels out as breadcrumbs — `Projects / Trackle / Task 42` — with the panels currently on screen in bold. Clicking an earlier crumb goes back to it *without closing anything*: the panels right of it stay open, parked just past the viewport's right edge, and clicking their crumbs brings them back. Browsing the stack is free — it's opening a *new* panel that closes the panels after the one it came from. The app's name and logo link to the app's home (the `home` option, `/` by default; `null` links neither), going back to it when it's already open and opening it when it isn't. A stack too long for the bar scrolls sideways, in an `S.scrollStrip` like the tab strip's.
+**The breadcrumbs are the navigation.** The top bar's second line writes the open panels out as breadcrumbs — `Projects / Trackle / Task 42` — with the panels currently on screen in bold. A crumb is an ordinary link to its panel, so clicking one goes back to that panel and closes what was stacked on top of it — and the browser's back button brings those columns back. The app's name and logo link to the app's home (the `home` option, `/` by default; `null` links neither), going back to it when it's already open and opening it when it isn't. A stack too long for the bar scrolls sideways, in an `S.scrollStrip` like the tab strip's.
 
 That line is the `subtitle`'s while the stack has nothing to add: one panel open, reachable from a nav item that is already highlighted in a visible sidebar. Otherwise the stack takes it, since it is then the only thing naming the screen.
 
-Right-click (or long-press) a crumb for **Close** — which takes just that panel out, wherever it sits in the stack — and **Pin**. A pinned panel — its crumb wears a pin — never closes as a side effect of navigation elsewhere: where opening a new panel would prune it, it rides along beneath the new panel instead, one crumb click away. Pin the reference you keep coming back to, then navigate freely. An *explicit* close (Escape, `close()`, the crumb menu, `data-panel=replace`) still closes it, and it's yours from code as `$panel.pinned`. Because a crumb is a real link whose right-click the menu takes over, the menu also offers **Open in new tab** and **Copy link**.
+Right-click (or long-press) a crumb for **Close** — which takes just that panel out, wherever it sits in the stack — and **Pin**. A pinned panel — its crumb wears a pin — never closes as a side effect of navigation elsewhere: where a navigation would prune it, it rides along beneath the new panel instead (or parks out of sight, when the panel you went back to was already beneath it), one crumb click away. Pin the reference you keep coming back to, then navigate freely. An *explicit* close (Escape, `close()`, the crumb menu, `data-panel=replace`) still closes it, and it's yours from code as `$panel.pinned`. Because a crumb is a real link whose right-click the menu takes over, the menu also offers **Open in new tab** and **Copy link**.
 
 A crumb can also wear a **●**: the panel holds unsaved work, and nothing will close it (see `$panel.unsaved` below).
 
@@ -261,7 +264,7 @@ Closing the current panel hands the focus to the panel on its left. Closing one
 
 A closed panel is torn down at once: its `A.clean()` hooks run the moment it closes, so subscriptions, timers and requests stop there and then. Only its element hangs around, inert and frozen, for the length of the exit animation.
 
-Escape steps one panel back along the stack: at the stack's end that closes the current panel, mid-stack it just moves left and parks the panel you leave, and at the stack's start it jumps to the navigation. The browser's back button replays whole arrangements — it re-opens what a navigation closed and re-parks what a crumb click brought back.
+Escape closes the current panel — or just steps left, when it holds unsaved work or panels sit parked beyond it — and at the stack's start it jumps to the navigation. The browser's back button replays whole arrangements, re-opening what a navigation closed.
 
 <a id="ancestors"></a>
 
@@ -293,7 +296,7 @@ Search params and the `#hash` belong to the current panel only. Anything another
 
 **A few more things.**
 
-- `columns: "single"` shows only the current panel, however wide the screen — the phone experience at every size. Only the display changes: the URL, the back button, unsaved panels and the panels' own close buttons all behave the same.
+- `columns: "single"` shows only the current panel, however wide the screen — one screen at a time at every size, each still at its asked width, centred. Only the display changes: the URL, the back button, unsaved panels and the panels' own close buttons all behave the same.
 - `linkNavigation` sets what a link *without* a `data-panel` attribute does: `"push"` (the default), `"replace"`, or `"open"`. With `"open"` every click replaces the content as a whole — which, with flat routes, is the conventional sidebar-and-content app: one pane, swapped on every click, the crumb line simply naming it.
 - Both are live: pass a proxied options object (or make the field a getter) and a change is adopted in place, every open panel keeping its state.
 - Only one routed `S.main()` can be mounted at a time; a second one throws — the URL is global, so two of them would fight over it. Nothing else is global: the stack belongs to its shell, and each handler gets its own `$panel`, since several panels are alive at once.

package/dist/components/dialog.js

@@ -14,7 +14,7 @@ A.insertGlobalCss({
         "&": "position:fixed z-index:200 top:50% left:50% " +
             "display:flex flex-direction:column " +
             "transform:translate(-50%,-50%) " +
-            "min-width:20rem max-width:min(90vw,44rem) max-height:min(88vh,800px) " +
+            "min-width:min(20rem,90vw) max-width:min(90vw,44rem) max-height:min(88vh,800px) " +
             "r: $s-radius-lg; overflow:hidden " +
             "transition: opacity 0.2s ease-out, transform 0.2s ease-out;",
         "> header": "display:flex align-items:center gap:$2 padding: $2 $3; " +

package/dist/components/main.d.ts

@@ -85,16 +85,15 @@ export interface MainOptions<R = Routes> {
      * Navigating is just links: the shell handles the clicks itself, so do *not*
      * also call Aberdeen's `interceptLinks()`. A link opens its target on top of
      * the panel it sits in, closing everything after that panel first. The
-     * `data-panel` attribute picks another of the three {@link PanelStack}
-     * navigations instead: `replace` puts the target in place of the link's own
-     * panel, and `open` leaves that panel behind and gives the target its own
-     * stack, the way a nav item does. A link
-     * to something already open goes back to it rather than opening it twice —
-     * a move along the stack that closes nothing: the panels right of it stay
-     * open, parked past the viewport's right edge, until a *new* panel prunes
-     * them (pinned panels excepted — see {@link Panel.pinned}).
-     * From code, use {@link pushPanel} and friends: navigating
-     * with `aberdeen/route`'s own `go()` works too — a panel with
+     * `data-panel` attribute keeps less of that context instead: `replace`
+     * drops the link's own panel too, putting the target in its place, and
+     * `open` drops it all, giving the target its own stack, the way a nav item
+     * does. A plain link to something already open goes back to it rather than
+     * opening it twice, closing whatever was stacked on top — pinned panels
+     * excepted (see {@link Panel.pinned}), and panels holding unsaved work,
+     * which park instead; a `replace` or `open` applies its usual shape, the
+     * open panel moving into it alive. From code, use {@link pushPanel} and
+     * friends: navigating with `aberdeen/route`'s own `go()` works too — a panel with
      * {@link Panel.unsaved} work still survives it — but builds the whole stack
      * from the path. A navigation guard the app registered with
      * `route.setGuard` (an auth redirect, say) keeps working: the shell
@@ -104,11 +103,11 @@ export interface MainOptions<R = Routes> {
      * is called ({@link Panel.title} — unset, its first line of text stands in)
      * and what it can do ({@link Panel.actions}); everything else in a column is
      * the panel's own content, boxes included. The shell writes the stack of
-     * open panels as breadcrumbs in the top bar — click one to go back to it,
-     * closing nothing — and places each panel's actions where the room is: on
-     * its own column while several fit, in the bar once the shell is narrow and
-     * the current panel *is* the screen. Nothing in an app measures the
-     * viewport to lay its screens out twice.
+     * open panels as breadcrumbs in the top bar — click one to go back to it —
+     * and places each panel's actions where the room is: on its own column while
+     * several fit, in the bar once the shell is narrow and the current panel *is*
+     * the screen. Nothing in an app measures the viewport to lay its screens out
+     * twice.
      *
      * Only one routed shell can be mounted at a time (a second one throws) —
      * the URL is global, so two of them would fight over it. Nothing else is:
@@ -180,9 +179,10 @@ export interface MainOptions<R = Routes> {
      * How many panels are *shown* at a time. `"auto"` (the default) shows as
      * many columns, side by side, as comfortably fit, ending at the current
      * panel; `"single"` shows only the current panel, however wide the screen
-     * — the phone experience at every size (the nav sidebar still sits beside
-     * it). Only the display differs: the stack, the breadcrumbs, the URL,
-     * Escape and the back button behave identically in both. Routed mode only.
+     * — one screen at a time at every size, each still at its asked width,
+     * centred (the nav sidebar still sits beside it). Only the display
+     * differs: the stack, the breadcrumbs, the URL, Escape and the back
+     * button behave identically in both. Routed mode only.
      *
      * Live: pass a proxied options object (or make this field a getter) and a
      * change is adopted in place — one layout pass, every panel keeping its
@@ -191,12 +191,13 @@ export interface MainOptions<R = Routes> {
     columns?: "auto" | "single";
     /**
      * What a link *without* a `data-panel` attribute does — the per-link
-     * attribute always wins. `"push"` (the default) opens the target on top of
-     * the panel the link sits in; `"replace"` opens it in that panel's place;
-     * `"open"` gives it its own stack, the way a nav item does. With `"open"`
-     * every click replaces the content as a whole — which, with flat routes,
-     * is the conventional sidebar-and-content app: one pane, swapped on every
-     * click, the crumb line simply naming it. Routed mode only.
+     * attribute always wins. The three keep less and less of the link's own
+     * context: `"push"` (the default) builds on the panel the link sits in,
+     * `"replace"` swaps that panel out, and `"open"` ignores it and gives the
+     * target its own stack, the way a nav item does. So with `"open"` every
+     * click replaces the content as a whole — which, with flat routes, is the
+     * conventional sidebar-and-content app: one pane, swapped on every click,
+     * the crumb line simply naming it. Routed mode only.
      *
      * Live, like {@link MainOptions.columns}: change it and the next click
      * uses the new default.
@@ -205,32 +206,23 @@ export interface MainOptions<R = Routes> {
     /** Footer content, pinned below the scroll area. */
     footer?: Slot;
     /**
-     * Max width for the panel's *content*, e.g. `"60rem"`. The header and footer
+     * Max width for the shell's *content*, e.g. `"80rem"`. The header and footer
      * backgrounds still span the full shell width, but their contents — and the
      * sidebar + separator + content trio (or just the content when there's no
      * sidebar) — cap to this width and centre horizontally. When unset, everything
      * fills the available width. Either way the content shares the panel surface —
      * it is not boxed.
      *
-     * Ignored when you pass {@link MainOptions.routes}: there the open panels
-     * decide the width (see {@link Panel.maxWidth}), and the header and footer line
-     * themselves up with them.
-     */
-    maxWidth?: string;
-    /**
-     * How wide a `"full"` panel gets, in pixels — and with it the whole content
-     * area, since a `"full"` fills it exactly. A `"half"` gets half of this, and
-     * a `"screen"` ignores it and takes the window. Defaults to 1080; the window
-     * caps it when there is less room than that. Routed mode only.
-     *
-     * This plus {@link MainOptions.navWidth} is the app's standard page — see
-     * there.
+     * In routed mode this is what the columns divide up (see
+     * {@link Panel.maxWidth}), which is the reason to set it on a very wide
+     * screen: left uncapped, a stack of small panels will happily march right
+     * across a 4K display.
      *
      * Live, like {@link MainOptions.columns}: pass a proxied options object (or
-     * make this field a getter) and a change is adopted in one layout pass,
-     * every panel keeping its state.
+     * make this field a getter) and a change is adopted in one layout pass, every
+     * open panel keeping its state.
      */
-    fullWidth?: number;
+    maxWidth?: string;
     /** Aberdeen attr/style string applied to the content area. */
     contentAttrs?: Attributes;
     /** Aberdeen attr/style string applied to the top bar. */
@@ -259,13 +251,9 @@ export interface MainOptions<R = Routes> {
     navPosition?: "left" | "right";
     /**
      * How wide the nav sidebar column is, in pixels — its hairline included.
-     * Defaults to 200.
-     *
-     * Together with {@link MainOptions.fullWidth} this is the app's *standard
-     * page*: the width the top bar and footer keep to, and the width the
-     * columns settle back to. The defaults come to the familiar 1280px.
+     * Defaults to 200. Whatever it takes comes off the content area beside it.
      *
-     * Live, like {@link MainOptions.fullWidth}.
+     * Live, like {@link MainOptions.maxWidth}.
      */
     navWidth?: number;
     /** Aberdeen attr/style string applied to the sidebar nav panel. */
@@ -285,7 +273,8 @@ export interface MainOptions<R = Routes> {
  * Instead of a single `content` slot, pass {@link MainOptions.routes} and the
  * shell takes over navigation: each route draws one screen, called a panel,
  * and as many columns as fit are shown at a time, side by side on a wide screen
- * and one at a time on a phone. Each panel *declares* its chrome — its
+ * and one at a time on a phone; {@link MainOptions.maxWidth} caps how much room
+ * they have between them. Each panel *declares* its chrome — its
  * {@link Panel.title} and its {@link Panel.actions} — and this shell places it:
  * the stack of titles as breadcrumbs in the bar, the actions on the panel's
  * column while several fit and in the bar once the shell is narrow enough

package/dist/components/main.js

@@ -8,16 +8,9 @@ import { drawMenu, isFloatingMenuOpen, consumeBranchNav, anyCurrent } from "./me
 import { menu as menuIcon, x as closeIcon } from "../icons.js";
 import { iconButton } from "./button.js";
 import { isDialogOpen } from "./dialog.js";
-import { PanelStackController } from "./panels.js";
-/**
- * The default nav column (hairline included) and the default width of a
- * `"full"` panel — see {@link MainOptions.navWidth} and
- * {@link MainOptions.fullWidth}. Side by side they come to the 1280px page the
- * shell is usually seen as, but that figure lives nowhere: the browser adds
- * these two up, and an app that changes either simply gets a different page.
- */
+import { PanelStackController, SMALL_MAX_PX } from "./panels.js";
+/** The default nav column, hairline included — see {@link MainOptions.navWidth}. */
 const NAV_W = 200;
-const FULL_W = 1080;
 A.insertGlobalCss({
     ".s-main": {
         // container-type so @container queries below can respond to shell width.
@@ -96,27 +89,6 @@ A.insertGlobalCss({
         // and the bar already comes from `.s-content`'s padding. Without a scrollbar
         // there's no margin, so the content keeps its single $3 edge — not 2×$3.
         ".s-body main.s-scroll-y": "margin-right:$3",
-        // Routed mode takes its width from the stack instead of from
-        // `maxWidth`: the layout engine publishes the ensemble width (sidebar +
-        // separator + content area) as --s-shell-w — the standard page
-        // normally, wider while the columns outgrow it (a "screen" page, or
-        // extra columns fitting a wide window) — and the body row caps itself
-        // to it, staying centred around the columns. Changing the custom
-        // property animates the max-width consuming it, with no JS in the loop:
-        // the body recentres in step with the panel whose arrival or departure
-        // moved it, over the same --s-panel-ms (see panels.ts). During a window
-        // resize (and the very first pass) the layout engine raises
-        // `.s-shell-snap` so the new width is adopted instantly instead of
-        // chasing the window through a transition.
-        "&.s-routed > .s-body > .s-body-inner": "max-width: var(--s-shell-w, 100%); transition: max-width var(--s-panel-ms) ease;",
-        "&.s-routed.s-shell-snap > .s-body > .s-body-inner": "transition:none",
-        // The bars don't follow the ensemble past the standard page: a header
-        // stretching to the window's edges and back with every "screen" panel
-        // reads as the whole app flexing, so the chrome holds still and only
-        // the columns grow. (Below the standard width the ensemble is simply
-        // the window, which only a resize changes — so the bars never animate,
-        // and take no part in the transition above.)
-        "&.s-routed > header > .s-bar, &.s-routed > footer > .s-bar": "max-width: calc(var(--s-nav-w) + var(--s-full-w))",
     },
     // Sidebar nav panel. Items reuse the shared `.s-menu-item` /
     // `.s-menu-sep` styles from menu.ts, so the sidebar and the floating
@@ -163,13 +135,20 @@ A.insertGlobalCss({
         // A phone's bar holds two lines of chrome in a screen's width, so it buys
         // the stack and the screen's actions room by spending less on air.
         ".s-main > header > .s-bar": "gap:$1 padding: $1 $2;",
-        // On phones a top-level content box becomes a full-bleed block: pull it out
-        // to negate the content padding and drop the rounded corners.
-        ".s-content > .s-box": "margin-inline: calc(-1 * $3); r:0 border-inline:0",
-        // At narrow widths, content boxes are full-bleed so there's no inset to
-        // align the scrollbar with — cancel the right margin.
+        // The narrow bar tucks its content in to $2 (above), so the $3 scrollbar
+        // inset no longer has a chrome edge to align with — cancel it.
         ".s-main .s-body main.s-scroll-y": "margin-right:0",
     },
+    // On phones a top-level content box becomes a full-bleed block: pull it out
+    // to negate the content padding and drop the rounded corners. Keyed on
+    // SMALL_MAX_PX, not the narrow threshold above: at or below it a column can
+    // never be narrower than the window (every size caps at the content area,
+    // and a lone column's cap is exactly this — see panels.ts), while just above
+    // it a small column floats centred, where a bleeding box would shed its card
+    // chrome over open ground.
+    [`@container (max-width: ${SMALL_MAX_PX}px)`]: {
+        ".s-content > .s-box": "margin-inline: calc(-1 * $3); r:0 border-inline:0",
+    },
 });
 export function main(opts = {}) {
     // Whether there is a nav to show is deliberately NOT worked out here: `items`
@@ -208,9 +187,6 @@ export function main(opts = {}) {
             notFound: opts.notFound,
             ancestors: opts.ancestors,
             title: opts.title,
-            // Corrected below, and on every change, from the app's own option:
-            // read here it would subscribe the whole shell to it.
-            fullWidth: FULL_W,
             $shell,
         })
         : null;
@@ -222,21 +198,18 @@ export function main(opts = {}) {
         // the new link default. Nothing else of the shell is touched.
         A(() => ctl.setColumns(opts.columns));
         A(() => ctl.setLinkNavigation(opts.linkNavigation));
-        A(() => ctl.setFullWidth(opts.fullWidth ?? FULL_W));
     }
     // Where the brand mark and the app's name link — or nowhere, when the app
     // said `home: null` (a title slot holding a control of its own, say).
     const homeHref = ctl && opts.home !== null ? opts.home ?? "/" : null;
-    // Routed mode caps the shell to the ensemble width the layout engine publishes,
-    // rather than to `maxWidth`.
-    const capWidth = ctl ? null : opts.maxWidth;
-    const root = A(`div.s-main${ctl ? ".s-routed" : ""}`, opts.attrs, () => {
-        // The two widths the CSS above works from, and with them the standard page
-        // the bars keep to. Each sits in a scope of its own — one that draws
-        // nothing, so re-running it is a single style write: an app that changes
-        // either on a proxied options object resizes the shell in place, panels
-        // and their state untouched.
-        A(() => A(`--s-full-w: ${opts.fullWidth ?? FULL_W}px`));
+    // The shell's one width cap, applied to the body row and to both bars, so the
+    // chrome and the content always line up. Each of the three reads it in a
+    // scope of its own — one that draws nothing, so re-running it is a single
+    // style write: an app that changes it on a proxied options object resizes the
+    // shell in place, panels and their state untouched.
+    const capWidth = () => { if (opts.maxWidth != null)
+        A("max-width:", opts.maxWidth); };
+    const root = A("div.s-main", opts.attrs, () => {
         // `--s-nav-w` is the sidebar's whole column, and nothing at all when there
         // is no sidebar to give it to — a shell without one lines its bars up with
         // the content. This scope also tags the shell with the side the sidebar is
@@ -267,10 +240,7 @@ export function main(opts = {}) {
             A("header.s-s.neutral", opts.topbarAttrs, () => {
                 A("div.s-bar", () => {
                     // Cap the bar's content to maxWidth and centre it within the full-width header.
-                    A(() => {
-                        if (capWidth != null)
-                            A("max-width:", capWidth);
-                    });
+                    A(capWidth);
                     // Leading: the ☰ once the nav has collapsed, the logo otherwise.
                     // Deliberately no back button, at any width: going back is the
                     // stack's job in both regimes (plus Escape and the browser's own
@@ -332,10 +302,7 @@ export function main(opts = {}) {
         // are identical with and without a sidebar nav.
         A("div.s-body", () => {
             A("div.s-body-inner", () => {
-                A(() => {
-                    if (capWidth != null)
-                        A("max-width:", capWidth);
-                });
+                A(capWidth);
                 // The sidebar, in its own scope so a changing item list redraws just
                 // it — never the content area beside it (see `nav` above).
                 A(() => {
@@ -359,10 +326,7 @@ export function main(opts = {}) {
             if (opts.footer != null) {
                 A("footer", () => {
                     A("div.s-bar", () => {
-                        A(() => {
-                            if (capWidth != null)
-                                A("max-width:", capWidth);
-                        });
+                        A(capWidth);
                         drawSlot(opts.footer);
                     });
                 });

package/dist/components/menu.d.ts

@@ -124,6 +124,14 @@ export interface FloatingMenuOptions {
      * context menu — whose anchor has no click handler — wants the click to close.
      */
     closeOnAnchorClick?: boolean;
+    /**
+     * The link this menu stands on, as a path or URL. A menu that takes over a
+     * link's right-click takes the browser's own link menu away, so it owes the
+     * two entries anyone actually reaches for there: with this set, **Open in
+     * new tab** and **Copy link** are prepended above a separator, where that
+     * menu would have had them. The shell's breadcrumbs use it.
+     */
+    link?: string;
     /** Aberdeen attr/style string on the floating panel. */
     dropdownAttrs?: Attributes;
 }

package/dist/components/menu.js

@@ -1,8 +1,9 @@
 import A from "aberdeen";
 import { matchCurrent, current as currentRoute, go } from "aberdeen/route";
 import { drawSlot, mountPortal, focusFirst } from "../core.js";
-import { menu as menuIcon, chevronRight } from "../icons.js";
+import { menu as menuIcon, chevronRight, externalLink as newTabIcon, link as linkIcon } from "../icons.js";
 import { button } from "./button.js";
+import { toast } from "./toast.js";
 // Styles shared by the floating dropdown and the sidebar nav, so both look
 // identical. The item styles aren't scoped to a container, so `drawMenu` can
 // render its items into either one.
@@ -16,7 +17,11 @@ A.insertGlobalCss({
     // invisible yet still hittable by tests and read by assistive tech.
     ".s-menu-list": "position:fixed z-index:350 min-width:10rem display:flex flex-direction:column p:$1 " +
         "r:$s-radius-lg " +
-        "overflow-y:auto max-height:min(80vh,28rem) " +
+        // The 16px off max-width is the 8px gap `positionMenu` leaves at either
+        // window edge: in a window too narrow for the menu, it narrows rather
+        // than hanging off the screen. (A `min-width` from the caller still wins,
+        // as CSS says it must — that ask is the app's to keep sensible.)
+        "max-width: calc(100vw - 16px); overflow-y:auto max-height:min(80vh,28rem) " +
         "transition: opacity 0.15s, transform 0.15s, visibility 0.15s;",
     ".s-menu-list.hidden": "opacity:0 pointer-events:none transform:translateY(-6px) visibility:hidden",
     // One class for both the `<a>` (link) and `<button>` forms — they look
@@ -407,12 +412,41 @@ function positionMenu(menuEl, rect) {
     menuEl.style.left = Math.max(8, x) + "px";
     menuEl.style.top = Math.max(8, y) + "px";
 }
+/**
+ * The standard entries for the link a menu stands on (see
+ * {@link FloatingMenuOptions.link}). "Open in new tab" is a real new tab, so
+ * the target arrives cold, exactly as the link middle-clicked would.
+ */
+function linkItems(href) {
+    return [
+        { label: "Open in new tab", icon: newTabIcon, click: () => { window.open(href, "_blank", "noopener"); } },
+        { label: "Copy link", icon: linkIcon, click: () => void copyLink(href) },
+    ];
+}
+/**
+ * Put the link's address on the clipboard, as the absolute URL someone can
+ * paste anywhere — what the browser's own "Copy link" would have given them.
+ * Confirmed with a toast, since a silent copy leaves you wondering; `writeText`
+ * needs a secure context, so a failure says so rather than lying.
+ */
+async function copyLink(href) {
+    const url = new URL(href, location.href).href;
+    try {
+        await navigator.clipboard.writeText(url);
+        toast({ message: "Link copied." });
+    }
+    catch {
+        toast({ message: "Couldn't copy the link.", type: "danger" });
+    }
+}
 mountPortal(() => {
     const f = $floating.opts;
     if (!f)
         return;
     const menuEl = A("div.s-menu-list.s-s.neutral.shadow create=hidden destroy=hidden", f.dropdownAttrs, () => {
-        drawMenu(f.items, closeFloating);
+        // One drawMenu call, not one per section: it owns the container's roving
+        // keyboard focus, and two of them would move it twice per keypress.
+        drawMenu(f.link != null ? [...linkItems(f.link), { separator: true }, ...f.items] : f.items, closeFloating);
     });
     // Capture-phase document handlers replace an invisible backdrop element:
     // any click outside the panel + anchor closes; Escape/Tab close.
@@ -539,13 +573,13 @@ export function addContextMenu(opts) {
         e.preventDefault();
         myEl = e.currentTarget;
         // Anchor at the exact click/tap point, and close on a plain click of the
-        // element (it has no toggle handler of its own).
+        // element (it has no toggle handler of its own). The rest of the options
+        // pass through whole, so a shared option can't be dropped on the way.
         showFloatingMenu({
-            items: opts.items,
+            ...opts,
             anchor: myEl,
             at: { x: e.clientX, y: e.clientY },
             closeOnAnchorClick: true,
-            dropdownAttrs: opts.dropdownAttrs,
         });
     });
 }