Zero Browser — Roadmap & Risk Register

Version: 0.3 Last updated: 2026-09-18

Where it stands. Phases 0 and 1 are done except for the multi-process shell, and most of Phase 2 landed with them: flexbox, grid, floats, overflow clipping, opacity/z-index, the 2D transform functions with transform-origin, filter/backdrop-filter, text-shadow, @keyframes, @supports, CSS counters and generated content, the full HTML character reference table, sibling and structural selectors, CSS comments, WebP, an SVG rasterizer (gradients, patterns, clip paths, <use>, <text>), and promises/await/JSON in the script engine. On the product side: split view, spaces (separate profiles), sync as a sealed file, an HTTP cache that survives a restart, an English/Hindi interface with IME input, and encryption at rest on all three platforms.

What is genuinely not built, and why it is not a matter of polish:

• Multi-process + sandbox (R5). Partly built. Startup mitigations apply to every process, and page content renders in a separate, privilege-dropped renderer with no network of its own — interactive tabs included: every tab gets one, and the shell keeps a spare already warmed so opening a tab does not wait for a process. Site isolation (renderer per site, not per tab) and a filesystem jail (restricted token / AppContainer) are what is left.
• GPU compositing. Measured, on a real page at 1280x900: 25 ms to render the page, 1.5 ms to composite the frame. Presenting that same CPU-rastered frame through the GPU competes for the 1.5 ms and cannot touch the 25 ms — so the dependency is not worth its weight until rasterization itself moves, which is the engine work, not a presenting change. (The compositing pass got 2.6x faster for free once it stopped doing per-pixel coordinate arithmetic at zoom 1.)
• zero-js bytecode VM and JIT. Still a tree-walking interpreter — but 4–18x faster than it was, because measuring found the cost was never the AST walk (see crates/zero-engine/examples/jsbench.rs). A VM buys resolved variable slots next; worth doing when a real page's scripts are what is slow.
• The compat bridge. Embedding another engine remains unbuilt, and is being questioned rather than scheduled: Ctrl+Shift+O hands the page to the browser the system already has, which keeps the promise nobody is stuck — without a second engine to ship, sandbox and keep current. If that proves insufficient in use, the bridge is the answer; until then it is 200 MB of speculation.
• CSS transitions and animations. Both animated: anim.rs keeps the previous value per element, the document carries a clock, and @keyframes runs off the same clock with the standard easing functions. The chrome does not use transitions — it is rebuilt from scratch each frame, so there is no previous value to interpolate from — but a page's own do, and a spinner spins. Animation: Off holds each animation at its fill state rather than freezing it mid-cycle.

What is next is tracked as milestones, not phases: the phases below are the strategy, and the milestones are the ordered work. They were set by opening real sites and writing down what broke, so they lead with the things that make Zero unusable rather than the things that are furthest from spec. See https://github.com/vedantnimbarte/zero/milestones.

This roadmap is deliberately honest about the biggest fact of the project: a from-scratch browser engine is a multi-year effort. The plan front-loads shippable value (shell + AI + a real, if limited, engine) and grows web compatibility in phases, with a compat bridge so early users are never stuck.

Durations are relative effort bands, not calendar promises — they depend on team size (a from-scratch engine with a small team runs long; contributors accelerate it).

Phase 0 — Foundation & spike (proof it's real)

Goal: stand up the workspace, process model, and a "hello web" render.

• Cargo workspace + crate skeletons (§9 of Architecture).
• Multi-process shell: browser process + one sandboxed renderer + IPC.
• wgpu window + minimal UI chrome; render a solid color, then a rectangle, then text.
• zero-html tokenizer + DOM for a trivial page; zero-css for a handful of properties; zero-layout block layout; zero-paint + zero-compositor render a static HTML page.
• Networking: fetch a URL over HTTPS (rustls) and display its (very simple) HTML.
• Exit criteria: a sandboxed renderer displays a hand-picked static HTML page, on all 3 OSes.

Deliverable: internal demo. Proves the pipeline end-to-end.

Phase 1 — Usable minimal browser (private alpha)

Goal: a real, if limited, browser you can daily-drive for simple sites + our own surfaces.

Engine

• HTML parsing to WHATWG conformance (the hard malformed-input cases).
• CSS: full box model, inline/block, colors, backgrounds, basic positioning.
• Text: Latin + Indic shaping (rustybuzz), font fallback, line breaking.
• Images: PNG/JPEG (partial).
• zero-js interpreter — ES subset; DOM bindings for basic interactivity.
• Compat bridge available (opt-in) for sites outside the subset.

Shell / product

• Vertical tabs (reorder, pin, close/undo, groups-lite), collapsible sidebar.
• Command/address bar (navigate, search, history/bookmark suggestions).
• New-tab page (per reference image 2), light + dark themes.
• Downloads, history, bookmarks (basic); session restore; settings (privacy-first).
• Privacy: tracker/ad blocking in network service, HTTPS-first, local encrypted storage.

AI (v1 core)

• AI service process; command-bar AI intents.
• "Chat with this page" (summarize/ask) via sanitized page context.
• On-device model option + consented cloud; privacy indicator.

Localization

• English + Hindi UI; Indic IME in inputs; ₹/date/number formatting.

Exit criteria: contributors can use Zero for a defined set of everyday simple sites + all Zero surfaces; the rest fall back to the bridge with clear labeling.

Milestone: Private Alpha.

Phase 2 — Real-world capable (public beta)

Goal: most mainstream sites are pleasant on the Zero engine.

Engine

• CSS flexbox; transforms/transitions (partial); more paint fidelity (shadows, gradients, radii).
• Images: WebP + basic SVG.
• zero-js bytecode VM + inline caches (real-world speed); more Web APIs (fetch, events, timers, storage, localStorage/IndexedDB-lite).
• Perf baseline established; memory harness; background-tab sleeping.

Product

• Split view (2 panes) with draggable divider + context menu (reference image 1).
• Spaces & profiles (separate storage jars, per-space accent).
• Encrypted sync (optional, E2E, self-hostable).
• Agentic AI actions with confirmation gate; cross-tab context (Should).
• More Indian languages (target: +4).

Exit criteria: a broad site corpus renders correctly on the Zero engine; bridge usage drops sharply; perf budgets met on reference hardware.

Milestone: Public Beta.

Phase 3 — Compatibility & hardening (1.0)

Goal: the browser is trustworthy and compatible enough for a general launch.

Engine

• CSS grid; fuller animations; <video>/<audio> (partial).
• Site isolation for cross-site iframes; renderer-per-site.
• zero-js baseline JIT (hardened); GC to generational if profiling demands.
• WPT subset pass-rate target; Test262 subset target.

Product & trust

• Security audit + fuzzing hardening; bug-bounty program.
• Signed auto-update with rollback protection.
• Accessibility audit (WCAG AA) pass.
• Data-passport, transparency report, India-hosted services live.
• Extensions: limited, safe extension API (content blocking, themes) — not full Chrome parity.

Exit criteria: stable, secure, compatible with the large majority of real sites; crash-free ≥ 99.5%; bridge is opt-in/legacy only.

Milestone: 1.0 Public Launch — "India's first from-scratch browser."

Phase 4+ — Scale & differentiate (post-1.0)

• Optimizing JIT; HTTP/3/QUIC; more media/codecs; PWA support.
• Deeper India integrations (UPI awareness, DigiLocker, gov services).
• Mobile (Android first) — a large, separate track.
• Broader extension ecosystem; developer tools.
• Retire the compat bridge for general web use.

Cross-cutting workstreams (run throughout)

• Testing/CI: conformance corpus, screenshot diffs, fuzzing, perf CI, 3-OS matrix.
• Security: sandbox parity per OS, unsafe audits, threat-model reviews.
• Community: public roadmap, RFCs, contributor guide, good-first-issues, Discord/Matrix.
• Design: hi-fi prototype → design system in zero-ui → per-screen implementation.
• Localization: grow language coverage each phase.

Risk register

What "shippable at each phase" means (anti-vaporware guardrail)

Each phase ends with a thing a real person can install and use, not a bigger TODO:

• P0: internal demo (renders a static page).
• P1: private alpha (daily-drive simple sites + Zero surfaces; bridge for the rest).
• P2: public beta (most mainstream sites on our engine).
• P3: 1.0 (general web, secure, audited).

If a phase can't hit its exit criteria, we cut scope, not honesty.