GoKawiilOn forking the Web
Introduction
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 MiB 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.
Semantic versioning
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.
... continue reading