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.

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.

Strict grammar

The specification must contain a non-ambiguous formal grammar that can be parsed easily. A page can then be tested against the standard and reject or accept as compliant. Pages that don't conform with the specification won't be rendered. It is explicitly forbidden for clients to accept any page that doesn't conform with the specification. This prevents the standardized diabolic rules that one must implement in order to correct a broken page, and forces the specification to correct its own mistakes in a later version.

Having a strict grammar will likely cause humans to migrate to a language that is easy to write and is more forgiving (for example Markdown), and this is the intended effect. The objective is that parsers can be simplified and the cost of creating tools that can manipulate the content is lowered.

In particular, changes in the patch version number only change wording, the grammar is kept the same.

Reusing HTML if possible

It would be nice to be able to build a subset of HTML so that it would work with minimal effort in already existing software. However, this may not be possible given the complexity of parsing HTML. Similarly, creating a formal grammar of an XML document is non-trivial. So it would need to be reviewed if HTML/XML is a suitable format for simple parsing.

Resistance to standard capture

One of the problems with the Web is that as soon as a monopolistic entity can build a mechanism to extract revenue from it, there will be an incentive to capture the standard and change it to for their own benefit. In the particular case of the Web, this has resulted in a standard that grows out of control in complexity so it increases the barrier of entry for new browsers and reduces the competition.

I have some rough ideas on how to try to prevent this situation, but this would need to be studied more carefully from the point of view of game theory.

Text first

The objective of the specification is to cover enough details to transfer information among humans, in very much the same way a printed book or article would do. Written text should be the preferred medium as it is the most versatile way to encode information as it can be translated, read aloud by a computer or stored in a compact amount of storage.

Text should be able to wrap the screen size, so that the same document can be read both in small and large screens.

No scripting

Adding scripting capabilities was a mistake, so we can avoid it now. This doesn't restrict users to have interactive programs. An example is an interactive map that is currently loaded in the browser using JavaScript so show a location of a place of interest. Instead, you can provide a Geo link to open the location in any client that supports the protocol. Similarly, any client can use the tiles of your server, provided that there is an open specification.

The advantage of using a native program to load a standardized file or URL is that it can be optimized to the device in use and prevent the "one size fits all" approach of many interactive Web pages.

Non-goals

The objective is not to create a feature-by-feature clone of the Web, but to create an specification that allows humans to exchange knowledge, notes, and other forms of information without the imposed requirement of having to run a full blown VM to read it.