Browser support and fallback modes
Cursors starts with an ordinary HTML document. The reading edition and its links do not depend on JavaScript, WebAssembly, browser storage, WebRTC, or graphics. The interactive cockpit is an enhancement, not the only way into the site.
Reading without JavaScript
Open all guides or the project context. Each guide has its own HTML address, related links, illustrations, and a plain Markdown copy. Browser Find and Print work without application code. JavaScript is necessary for local identities, signing, live inspection, and execution; the reading edition never pretends to perform those operations.
Choose Text view to stay in reading mode even when JavaScript works. If a module is blocked, cannot be parsed, fails to initialize, or takes too long, the original document remains visible. Reload to retry the interactive mode.
What the browser checks
Browser support reports operation probes, not browser-brand guesses. Available APIs can still fail later. A passing probe does not prove a peer is reachable, a service is enabled, a passkey supports PRF, or that data will survive browser eviction.
| Capability | Check and fallback |
|---|---|
| Local storage | A unique, non-sensitive key is written, read, and removed. Failure keeps the reading edition; existing identity records are not deleted or replaced. |
| Cryptography | Secure context, secure random generation, and SHA-256 are checked. Failure keeps the reading edition; there is no insecure signing substitute. Identity algorithms are independently checked when used. |
| WebRTC | A data channel is constructed with no ICE servers and closed. Missing support or transport initialization failure leaves same-tab and HTTPS part retrieval available. This is not a claim of connected peers or successful delivery. |
| BroadcastChannel | Construction and sends are guarded. Failure leaves this-tab state and HTTPS retrieval, without claiming cross-tab delivery. |
| WebAssembly and module Workers | A minimal Wasm module is instantiated and a disposable worker must answer. Missing support disables the SQLite proof runner, not reading or the rest of the cockpit. Worker startup and RPC operations have bounded waits. |
| OPFS | Directory access is checked. The chosen SQLite backend must still actually open its files. Durable databases never silently become empty memory databases. The existing proof lab deliberately uses memory and makes no persistence claim. |
| IndexedDB and Cache Storage | Non-sensitive disposable storage is written and read, then removed. Failure is reported; ordinary HTTPS remains. |
| Service workers | Existing registrations are inspected. No registration or cache result is treated as a guarantee that an uncached page works offline. |
| Canvas | A 2D context is requested. HTML controls and the text inventory remain when graphics fail. |
Small screens and motion
Navigation wraps into six touch-sized tabs. Forms use readable text, long identifiers wrap, and wide tables scroll inside their own containers. Layout includes safe-area padding, a traditional viewport-height fallback, and dynamic viewport sizing where supported. Zoom remains enabled. Reduced-motion preferences disable decorative CSS motion and continuous canvas animation.
Offline and service failures
The browser’s online indicator is only a hint. Network errors are still handled by the actual operation. Already loaded documents remain readable offline, but an uncached page requires connectivity. A failed request is not a receipt and is never labelled as saved or delivered.
The public deployment remains a read-only research preview. Fallbacks do not enable remote mailbox mutations or relax authorization. Unsupported passkeys do not cause automatic plaintext identity storage. The cockpit’s existing explicit passphrase path uses its existing encrypted vault; consult the local identity guide.