Forking the Web

This document contains a set of informal notes on how to build an alternative specification to the Web, in such a way that hopefully prevents many of its drawbacks while still preserves many of the good points. This document is not an specification, and is therefore subject to change over time. The Web is composed of several components, each may need to be reviewed. For know let's focus on the HTML specification (18.3 Mi B of uncompressed size as of 2026-05-06) and leave the rest for later. Goals Before building an specification, we should first have a clear list of goals that will drive the decisions on what should be part of the specification and what not. Simplicity The whole specification must be simple and short, so that we can guarantee a diversity of browsers and other clients that can be created with low effort. Keeping things simple over time (decades) is very hard, if not impossible. One potential rule is to constraint the specification in length (bytes). We already use this technique in Dillo to restrict the release to fit in a single floppy disk, so we could use the same approach. Using the limit as 1.44 MiB of a compressed tar.gz with the complete specification.

The current "Web specification" is a page that changes roughly weekly. This makes it imposible to program a client that conforms to the specification without constant changes. Instead, the specification should have a very precise semantic version like 1.2.3, so that we know that a page that conforms with the version 1.2.3 can be correctly render by a browser that supports 1.2.3, 1.2.0 or 1.3.0, but not one that supports only 1.1.0 or 2.0.0.

Having a semantic versions allows authors to focus on the standard instead of on the current state of implementation of a given web browser. For example, you could target the version 1.2.0 knowing that, say, 90% of the browsers support this standard. A published version of the standard NEVER, EVER, EVER, EVER changes. Typos are corrected by bumping the patch version number. Retro-compatible new features are introduced by bumping the minor version. And breaking new changes require a major bump. This implies that you can buy a printed copy of the 1.2.0 standard, and use that in a desert island to program a perfectly compliant browser that will remain forever able to correctly parse 1.2.X documents.