staffa 0.13.0 → 0.15.0

package/skill/MainOptions.md

@@ -105,16 +105,15 @@ aren't safe integers, such as snowflakes, want a plain `[id]`.
 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 `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 `Panel.pinned`).
-From code, use `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 `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 `pushPanel` and
+friends: navigating with `aberdeen/route`'s own `go()` works too — a panel with
 `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
@@ -124,11 +123,11 @@ registers none of its own.
 is called (`Panel.title` — unset, its first line of text stands in)
 and what it can do (`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:
@@ -207,9 +206,10 @@ answer without drawing anything. From code,
 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
@@ -220,12 +220,13 @@ state.
 ### mainOptions.linkNavigation · member
 
 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 `MainOptions.columns`: change it and the next click
 uses the new default.
@@ -240,34 +241,23 @@ Footer content, pinned below the scroll area.
 
 ### mainOptions.maxWidth · member
 
-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 `MainOptions.routes`: there the open panels
-decide the width (see `Panel.maxWidth`), and the header and footer line
-themselves up with them.
-
-**Type:** `string`
-
-### mainOptions.fullWidth · member
-
-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 `MainOptions.navWidth` is the app's standard page — see
-there.
+In routed mode this is what the columns divide up (see
+`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 `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.
 
-**Type:** `number`
+**Type:** `string`
 
 ### mainOptions.contentAttrs · member
 
@@ -310,13 +300,9 @@ chrome goes assumes they are one.
 ### mainOptions.navWidth · member
 
 How wide the nav sidebar column is, in pixels — its hairline included.
-Defaults to 200.
-
-Together with `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 `MainOptions.fullWidth`.
+Live, like `MainOptions.maxWidth`.
 
 **Type:** `number`
 

package/skill/Panel.md

@@ -89,35 +89,35 @@ visible at once, and both of them are really there.
 
 ### panel.maxWidth · member
 
-The widest this panel can usefully be. Every panel must work at 360–540px,
-because that is what it gets when two columns fit; this says how much
-*more* it can take.
-
-- `"half"` — nothing more. Half the content area (360px up to half of
-  `MainOptions.fullWidth`), so a second column fits beside it. For
-  lists and detail forms.
-- `"full"` (the default) — the whole content area, which is exactly
-  `MainOptions.fullWidth`: 1080px unless the app says otherwise.
-- `"screen"` — the whole window, unbounded: boards, wide tables, dense
-  dashboards. While one is open the columns stretch to the screen edges
-  instead of stopping at the standard page; the top bar and footer hold
-  the standard width throughout.
-
-Below the width two columns need, everything takes the content area
-whatever it asked for. Widths depend only on the window, never on what
-else is open, so opening or closing a panel never resizes another.
-
-This is a *layout regime*, not a width guarantee: handle whatever width
-the bucket yields, and ask only for what your content can actually use —
-a screen that would cap its own content narrower than its ask is holding
-room that would have let another column fit beside it.
+The widest this panel can usefully be — a ceiling the shell never
+exceeds, so the draw function never has to look right past it. It is
+counted in the shell's *columns*: the content area divides into the
+narrowest whole number of columns of at least 360px each (three columns
+of 360 in a 1080px area, four of 380 in 1520px), and a column is never
+wider than 540 — where the area holds just one, a small centres in it
+rather than stretching. So an ask never exceeds its column count × 540:
+
+- `"small"` — one column, never above 540px: lists, detail forms.
+- `"medium"` (the default) — two columns, never above 1080px.
+- `"large"` — three columns, never above 1620px: wide tables.
+- `"none"` — the whole content area, unbounded: boards, dashboards.
+  Bound it with the shell's own `maxWidth` where that matters.
+
+Every size is capped at the content area, so on a phone they all come to
+the same thing: one screen at a time. And a width depends only on the
+window, never on what else is open, so opening or closing a panel never
+resizes another — the run of columns just recentres in the area.
+
+Ask only for what your content can actually use: a panel that would cap
+its own content narrower than its ask is holding room that would have
+let another column fit beside it.
 
 Set it at the top of your handler and the panel is already that wide when
 you draw (see `Panel.width`); set it later — when your data tells you
 — and the panel reflows without being redrawn, keeping its state, while
 the columns beside it move over.
 
-**Type:** `"half" | "full" | "screen"`
+**Type:** `PanelSize`
 
 ### panel.loading · member
 
@@ -132,10 +132,10 @@ affects the animation; the stack and the URL never wait for it.
 ### panel.pinned · member
 
 Keeps this panel from being closed by navigation happening *elsewhere*.
-Opening a new panel normally closes everything after the panel it came
-from; a pinned panel survives that, staying in the stack — parked past the
-right edge of the viewport — slotted in beneath the new panel, one crumb
-click away. The user toggles it from the crumb's context menu
+A navigation normally closes everything after the panel it came from (or
+returned to); a pinned panel survives that, staying in the stack — slotted
+in beneath the new panel, or parked out of sight when the new panel was
+already beneath it. Either way it is one crumb click away. The user toggles it from the crumb's context menu
 (right-click or long-press), which is also where the pin shows; setting
 it from code does the same thing.
 
@@ -149,12 +149,11 @@ still close the panel.
 
 Set this while the panel holds work that must not be lost — a dirty form,
 an upload in flight. An unsaved panel cannot be closed, by anything:
-navigation that would prune it parks it instead, past the viewport's
-right edge, wearing a ● in its crumb — even the browser's back button
-only parks it. `Panel.close` and the crumb menu's Close refuse,
+navigation that would prune it parks it out of sight instead, wearing a
+● in its crumb — even the browser's back button only parks it. `Panel.close` and the crumb menu's Close refuse,
 Escape on it steps left along the stack rather than closing, and closing
-the browser tab runs into the browser's own are-you-sure (after which the
-shell brings the unsaved panel back on screen).
+the browser tab runs into the browser's own are-you-sure, the unsaved
+panel brought on screen as the question is raised.
 
 Only the app clears it; the user has no toggle. A Save or Discard button
 clears it and then closes:

package/skill/PanelStack.md

@@ -53,10 +53,10 @@ unpinned panels that were after it (pinned ones stay, sliding in beneath
 the new panel).
 
 The same rules as a link click apply: pushing a path that is already open
-goes back to it — a focus move along the stack, closing nothing — rather
-than opening it twice, and a panel holding `Panel.unsaved` work is
-never closed, only parked. That's what a plain link does, and what
-`data-panel=push` says outright.
+returns to it — closing whatever was stacked on top — rather than opening
+it twice, and a panel holding `Panel.unsaved` work is never closed,
+only parked. That's what a plain link does, and what `data-panel=push`
+says outright.
 
 Note that a link builds on the panel it is *drawn in*, which is the
 current panel only while no column beside it has the focus. Code

package/skill/SKILL.md

@@ -159,11 +159,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.
@@ -185,21 +185,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 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 in both directions: 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 has to look right from 360px up to its own ceiling, and nowhere past it. There is nothing below 360 to handle either: a narrower window is shown the 360px layout scaled down to fit (dialogs, menus and toasts scaling along), so 360 really is the 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.
 
@@ -217,11 +220,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).
 
@@ -266,7 +269,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>
 
@@ -298,7 +301,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.
@@ -636,6 +639,16 @@ shell needs to know about the panel it is drawing. It's an Aberdeen proxy, so
 you can set things later, such as a `title` that arrives with your data or
 `loading` going back to `false`, and the shell keeps up.
 
+## PanelSize · type
+
+How wide a panel asks to be — a ceiling the shell never exceeds; see
+`Panel.maxWidth`. `"small"` is the column the content area is divided
+into; `"medium"` and `"large"` are two and three of those, and `"none"` is
+the whole area. Each is capped at the content area, so on a narrow window
+they all come to the same thing.
+
+**Type:** `"small" | "medium" | "large" | "none"`
+
 ## Routes · type
 
 A route table: path templates mapped to panel draw functions. Used as the

package/skill/main.md

@@ -11,7 +11,8 @@ right.
 Instead of a single `content` slot, pass `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; `MainOptions.maxWidth` caps how much room
+they have between them. Each panel *declares* its chrome — its
 `Panel.title` and its `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/src/components/dialog.ts

@@ -55,7 +55,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":