Banners

Do reach for a Banner when there's an action to attach (Popup = independent feature, Banner = info + action, Toast = info only). If the message is short and action-less, use a Toast instead.

There is no Info/Warning/Error kind — each banner's id is its kind, and it styles its own leading glyph/severity. These tokens are only the shared shell.

Host banners today: TTL — preset applied (6 s), shell integration missing (10 s). No TTL — mouse capture (⋯ rows), auto-attach refused (Remove mapping), attach size sync (Retry), HTML script notice (Allow), HTML remote content (Allow), HTML mirror size / aggregate (Allow · Continue).

The interactive manager (spawn / queue / background-pause / dismiss-pops-next) lives in the kit specimen ui_kits/terminal/overlays/banner.html.

Why 10 s: the body is two sentences plus a docs path (~25 words in en, longer in ja) — about 7–8 s of reading at a normal pace, plus time to notice a card that appears over live output. The 2 s toast default is for one-line confirmations and does not apply. Hover pauses the count, so a user who needs longer already has it. No setting: a per-banner TTL setting would be the only one of its kind; if users ask, a single global banner TTL setting is the place for it.

The glyph shown here is the specimen's; keep whatever the implemented card uses — this request changes only the top-right slot.

The bypass keys (Shift+drag / Shift+Right-click) are the message — keep them in the body. No inline action buttons: the body stays text-only, and the two per-app opt-outs live behind the ⋯ trigger next to the × (see Banner more menu below).

New glyph more (icons/more.svg — three dots, horizontal, same 2px round-cap language as M12 17h.01 style glyphs). A unicode ⋯ was rejected: the system renders every affordance through the Icon component so it inherits currentColor and the 16px sm size.

Don't keep the trigger permanently visible. A persistent banner with a permanently drawn ⋯ reads as a second dismiss control and adds chrome to a notice that is already at the top of live output — hover is where every other banner affordance lives.

Both rows write a permanent, per-program Settings entry (copy: see Row copy below): Don't show again for {app} → mouse_capture_banner_blacklist (capture stays delegated, only the notice is suppressed) · Let Tasty handle clicks in {app} → mouse_capture_blacklist (tasty takes clicks and drags back; the wheel still goes to the program). “Don't show again” also closes the banner it was opened from — suppressing the notice and leaving it on screen would contradict itself. “Let Tasty handle clicks” leaves the banner up (capture is already released; the user dismisses when done reading). Icons: bell for the notice row, mouse for the capture row.

While the menu is open the banner is treated as hover-equivalent — a TTL banner would keep its countdown paused, and the affordance column stays drawn even if the pointer has left the card.

Do keep the program name as the mono part of the row — it is the one thing the user must verify before writing a permanent per-app setting, and mono marks it as a process name rather than prose.

Don't paint the “Let Tasty handle clicks” row in danger tone (last card above, shown for the record). Nothing is destroyed and nothing is lost: the setting is reversible from Settings › Terminal, and it returns the mouse to tasty. Danger in this system means delete — spending it here would make the two rows look like different classes of action when they are the same class at two strengths.

Settings › Terminal › Mouse Capture and the user guide take the same verbs: list 1 Don't show the capture notice for these programs / 캡처 안내를 다시 보지 않을 프로그램 / キャプチャ通知を表示しないプログラム · list 2 Let Tasty handle clicks in these programs / 클릭을 Tasty가 처리할 프로그램 / クリックを Tasty で処理するプログラム, with the existing description (clicks and drags go to selection and the menu; the wheel is still sent).

Do keep the rows the user would see with a known name, disabled, so the menu teaches what exists; the reason line says why it can't run now, without a hover.

Don't hide the ⋯ or the rows when the name is unknown (2026-11-02 option a, withdrawn). Don't carry the reason in a tooltip on a disabled row — pointer-events none on the row blocks it, and a tooltip is invisible to anyone who doesn't hover.

The wheel is always forwarded to the program even for blacklisted apps — only clicks/drags are intercepted. A blacklisted foreground app also suppresses the capture banner on that surface.

Don't inject the notice into the document DOM (⒞): the page could hide or forge it, and its button can't run with scripts off. Don't build three native overlays (⒝) for one notice.

Firing: only when the user views the document (opened it, or selected the surface). Agent/IPC opens, session restore and background loads keep a "has scripts" flag and show the banner the first time the user looks at that surface.

Strings (en): remote.refusal.title “Remote not attached — {target}” · remote.refusal.self “This mapping points at this Tasty, so it was not attached.” · remote.refusal.profile_missing “No SSH profile with this name.” · remote.refusal.unresolved “The endpoint could not be resolved.” · remote.refusal.hint “Change or remove the mapping for this workspace.” · remote.refusal.remove “Remove mapping”. No new tokens.

Strings (en): remote.size_sync.title “Couldn't sync the terminal size with the remote” · remote.size_sync.names “{names}” (line 1) · remote.size_sync.hint “The remote may still be using the old size.” (line 2; replaces remote.size_sync.body) · remote.size_sync.many “{n} surfaces — {names}” · remote.size_sync.retry “Retry” · remote.size_sync.retry_all “Retry all”.

2026-11-01: the remote-content notice joins the same stack between the two — size → remote content → script. See HTML remote content notice.

Strings (en): html.remote.title “Remote content in this document is blocked” · html.remote.body “Stylesheets, images, fonts, frames and scripts from the network don't load, so the page may look incomplete. Allowing applies to this document only.” · html.remote.allow “Allow remote content” · html.remote.reloading “Reloading with remote content allowed” · html.remote.allow_loading “Available when the document finishes loading” (same text as the script key) · html.remote.marker_blocked “Remote content blocked. Click for details.” · html.remote.marker_allowed “Remote content allowed for this document”.

Don't make the blocked marker allow directly. It re-shows the notice, which explains scope before offering Allow — the same rule as the script lock.

Script notice bodyRemote (en, revised): “Buttons and menus that need JavaScript may not respond. Allowing runs the scripts inside this document; scripts from the network also need remote content allowed.”