Forking the Web: A Minimalist Specification for Sustainable Browsing

Author: Rodrigo Arias Mallo
Date: 2026‑05‑06

---

Thesis

The current Web stack has grown into a monolithic, constantly‑changing set of specifications that reward large corporations and penalize lightweight clients. A deliberate “fork”—a new, intentionally tiny specification focused on human‑readable text, strict grammar, and immutable versioning—could preserve the Web’s core purpose (information exchange) while eliminating the technical debt that now hampers innovation.

---

Core Arguments

1. Simplicity as a design constraint

A specification that fits within a 1.44 MiB compressed tar.gz forces developers to ask, “Is this feature essential?” The author cites the Dillo browser’s floppy‑disk constraint as a precedent. By bounding size, the spec remains auditable, teachable, and implementable on micro‑controllers, reducing the barrier to entry for new browsers and encouraging diversity.

2. Semantic versioning for stability

Unlike the living‑document model of the WHAT‑WG, the proposed spec would be immutable once published. A version number such as 1.2.3 would guarantee that any document claiming conformity to 1.2.x renders identically on any client supporting at least 1.2.0. Patch bumps would only correct typographical errors; minor bumps would add backward‑compatible features; major bumps would introduce breaking changes. This mirrors the stability model of libraries like Rust’s Cargo, allowing developers to target a known baseline without chasing weekly spec revisions.

3. Strict, non‑ambiguous grammar

The spec must include a formal grammar (e.g., an LALR(1) or PEG definition) that parsers can validate deterministically. Non‑conforming documents would be rejected outright, eliminating the “error‑recovery” heuristics that dominate modern HTML parsers. This approach pushes authors toward a more disciplined authoring language—potentially a lightweight markup such as CommonMark—and simplifies toolchains for validation, transformation, and indexing.

4. Text‑first, scripting‑free model

The proposal treats plain text as the primary vehicle for information, arguing that text can be wrapped, translated, and spoken with minimal overhead. Interactive features would be expressed through standardized protocols (e.g., geo: URIs for maps) rather than embedded JavaScript. This removes the need for a ubiquitous VM, reduces attack surface, and enables truly low‑power clients.

5. Guarding against capture

By fixing the spec’s size, versioning, and grammar, the design aims to make it harder for a dominant player to co‑opt the standard for revenue extraction. The author suggests a game‑theoretic analysis of incentive structures but leaves the details for future work.

---

Implications

1. Ecosystem diversification – Small devices, embedded systems, and hobbyist browsers could implement the spec without needing a full HTML5 engine, reviving the spirit of early browsers like Dillo.
2. Reduced maintenance costs – Publishers would no longer chase spec churn; a document written for version 1.2.0 would remain renderable indefinitely, simplifying archival and digital preservation.
3. Security benefits – Eliminating client‑side scripting removes a major attack vector, potentially decreasing the prevalence of XSS and supply‑chain exploits.
4. Content authoring shift – Writers would gravitate toward authoring tools that emit the strict markup, perhaps extending existing Markdown parsers with the new grammar.
5. Interoperability challenges – Existing web content would need translation layers or adapters, akin to HTML5 Boilerplate, to interoperate with the new format.

---

Counter‑Perspectives

• Expressiveness loss – Critics may argue that removing scripting eliminates legitimate interactive experiences (e.g., data visualizations). Proponents counter that such interactions can be off‑loaded to native applications via standard URLs, but this may fragment the user experience.
• Migration cost – Converting the vast corpus of HTML to a new format would be non‑trivial. Automated converters could help, yet edge‑case handling may be costly.
• Community adoption – Without backing from major browsers or standards bodies, the fork may remain a niche experiment. The success of WebAssembly shows that community momentum can shift standards, but it required broad industry support.
• Grammar rigidity – Strict parsing may reject malformed yet widely‑used patterns (e.g., missing end tags). While this encourages better authoring, it could break legacy content that cannot be easily fixed.

---

Conclusion

Rodrigo Arias Mallo’s “fork the Web” manifesto offers a thought‑provoking blueprint for a lean, version‑stable, and grammar‑strict specification that could democratize client development and protect the medium from monopolistic capture. Whether the broader ecosystem will rally around such a minimalist vision remains uncertain, but the proposal underscores a vital question: What would the Web look like if we prioritized simplicity and permanence over perpetual feature expansion?