Merge main (#120 ui/shell-polish) into feat/oujb-web-in-release

#120 restyled the page and rewrote #backend-notice as a <details>; <header>'s
markup is untouched, so #build-version lands where it was written. What the
merge actually has to answer is the CSS, and the stamp gate after it.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FC2jVn8Au7E9JPkw6bwXXH
This commit is contained in:
Edward Langley
2026-09-21 22:56:32 -07:00
13 changed files with 1393 additions and 147 deletions
+37 -20
View File
@@ -59,27 +59,44 @@
and a page that cannot reach its peer cannot be trusted to explain why.
What the peer is actually *doing* — starting, connected, unreachable,
gone — is live, and app.js writes it to #status.
It is a <details>, so the collapsing is the BROWSER's — keyboard
operable, and correct with app.js absent or still loading. The only
thing app.js adds is remembering the answer; the one line every visitor
needs is the <summary>, which never collapses.
-->
<p id="backend-notice">
Everything here runs in this tab: the document lives in a Web Worker
and is saved to this browser's private storage, so edits survive a
reload and never leave the machine. Load a different document with
<code>?doc=name.improv</code>, seeded from
<code>?seed=url</code>. To open a document hosted by a separate
process instead, run
<code>improvise-ws-server model.improv --port 8787</code> and reload
with <code>?ws=host:port</code>. <strong>The scheme defaults to
<code>wss://</code></strong>, because this page is served over https and
an https origin refuses a <code>ws://</code> address as mixed content.
Note that <code>improvise-ws-server</code> speaks plain
<code>ws://</code> only, so reaching it from <em>this</em> page means
terminating TLS in front of it with a reverse proxy or a tunnel — the
README has a worked Caddy example. Served over
<code>http://localhost</code> the same page defaults to
<code>ws://</code> and pairs with it directly, with nothing in between;
that is the case the pairing is really for. Sharing a document is what
the server is for — not running one is what everything above is for.
</p>
<details id="backend-notice">
<summary>
<span class="notice-lede"
>Everything here runs in this tab — the document lives in a Web
Worker and is saved to this browser's private storage, so edits
survive a reload and never leave the machine.</span
>
<span class="notice-toggle" aria-hidden="true"></span>
</summary>
<div class="notice-body">
<p>
Load a different document with <code>?doc=name.improv</code>, seeded
from <code>?seed=url</code>. To open a document hosted by a separate
process instead, run
<code>improvise-ws-server model.improv --port 8787</code> and reload
with <code>?ws=host:port</code>.
</p>
<p>
<strong>The scheme defaults to <code>wss://</code></strong>, because
this page is served over https and an https origin refuses a
<code>ws://</code> address as mixed content. Note that
<code>improvise-ws-server</code> speaks plain <code>ws://</code>
only, so reaching it from <em>this</em> page means terminating TLS in
front of it with a reverse proxy or a tunnel — the README has a
worked Caddy example. Served over <code>http://localhost</code> the
same page defaults to <code>ws://</code> and pairs with it directly,
with nothing in between; that is the case the pairing is really for.
Sharing a document is what the server is for — not running one is
what everything above is for.
</p>
</div>
</details>
<div id="tiles" aria-label="Tiles"></div>