From Newsgroup: comp.misc

On forking the Web by Rodrigo Arias Mallo, 2026-05-06 =====================================================

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" [1] 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 [2] 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 [3].

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.

Links
-----

[1] "Web specification"
<https://html.spec.whatwg.org/multipage/>

[2] Geo link
<https://en.wikipedia.org/wiki/Geo_URI_scheme>

[3] Tiled web map standards <https://en.wikipedia.org/wiki/Tiled_web_map#Standards>

From: <https://dillo-browser.org/lab/web-fork/>
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On Tue, 15 Sep 2026 02:58:52 -0000 (UTC), Ben Collver wrote:

The current "Web specification" [1] 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.

Web 2.0 shouldn't have existed.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

Ben Collver wrote:

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.

Good luck ...

--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On Tue, 15 Sep 2026 11:31:19 +0700, JJ wrote:

Web 2.0 shouldn't have existed.

ItrCOs great. It allows me to develop apps on a Linux system, with all
the powerful tools available, and deploy them cross-platform with
minimal worries. Basically all those non-Linux systems out there are
doing nothing more than running web browsers -- the 21st-century
equivalent of a dumb terminal.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

Ben Collver <bencollver@tilde.pink> wrote:

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

I near to only write for DIN-A4/US-Letter paper width and want to see my
layout decisions being respected. The layout is part of my text as
product. Often I even need to include source code. Reflowing that is
more than just a simple nightmare.

Simple fix: Add a flag to toggle reflow being allowed or not to the
markup definition. Users may wish to override this and IMO they should
be allowed to force reflow, but that way they kind of have been warned
that the result may converge to being unreadable.
--
The Cure
Pornography
<https://www.youtube.com/watch?v=gZNZ-5EVyOs>
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

Ben Collver <bencollver@tilde.pink> wrote or quoted:

The current "Web specification" [1] 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.

. . .

[1] "Web specification"
<https://html.spec.whatwg.org/multipage/>

One can still refer to the WHATWG publication by its date.
One also still can use any older HTML version, such as HTML 4.01.

The W3C sometimes publishes snapshots of the WHATWG specification,
which used to be versioned, but now only seem to have dates.

See: /standards/history/html and /TR under www.w3.org.


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On 2026-09-15, yeti <yeti@tilde.institute> wrote:

Ben Collver <bencollver@tilde.pink> wrote:

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

I near to only write for DIN-A4/US-Letter paper width and want to see my layout decisions being respected. The layout is part of my text as
product. Often I even need to include source code. Reflowing that is
more than just a simple nightmare.

Simple fix: Add a flag to toggle reflow being allowed or not to the
markup definition. Users may wish to override this and IMO they should
be allowed to force reflow, but that way they kind of have been warned
that the result may converge to being unreadable.

I use a reflowing approach similar to markdown and the `par` command. Indentation indicates preformatted text. Otherwise it can be reflowed. Markdown ends paragraphs with \n. I hard-wrap paragraphs, separated by
\n\n. `par` understands this.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

Ben Collver <bencollver@tilde.pink> wrote or quoted:

I use a reflowing approach similar to markdown and the `par` command. >Indentation indicates preformatted text. Otherwise it can be reflowed. >Markdown ends paragraphs with \n. I hard-wrap paragraphs, separated by
\n\n. `par` understands this.

Ah, I never even knew "par" exists - or have forgotten it.

I'm in the process of writing my own markup language,
where I also use "\n\n" as the paragraph separator.

Example Input

Looks like the major plain text specs, say Markdown and
ReStructured Text, all swear by the asterisk "*" for italics.
That is an abomination! For the language I am cooking up
I stick with "/" for italics - naturally.

Actually, this post was already formatted by my own markup
system, which did the paragraph wrapping and English hyphenation
for plain text.

Example Output (formatted plain text)

Looks like the major plain text specs, say Markdown and ReStructured
Text, all swear by the asterisk "*" for italics. That is an abomina-
tion! For the language I am cooking up I stick with "/" for italics
- naturally.
Actually, this post was already formatted by my own markup system,
which did the paragraph wrapping and English hyphenation for plain
text.

Example Output (excerpt of the HTML generated)

<p class="cc-ugy">Looks like the major plain text specs, say Markdown and
ReStructured Text, all swear by the asterisk &quot;*&quot; for italics.
That is an abomination! For the language I am cooking up
I stick with &quot;/&quot; for italics - naturally.</p>
<p class="cc-ugy">Actually, this post was already formatted by my own markup
system, which did the paragraph wrapping and English hyphenation
for plain text.</p>

However, this is a large and complex unfinished project. I am just
starting to use it to write my own texts and still detect many bugs.

The long-term goal is to publish its Python code, but it will still
take years until the minimum quality requirements for this are met.

Example input from the par man page:

We the people of the United States,
in order to form a more perfect union,
establish justice,
insure domestic tranquility,
provide for the common defense,
promote the general welfare,
and secure the blessing of liberty
to ourselves and our posterity,
do ordain and establish the Constitution
of the United States of America.

The output formatted by par from the par man page for "par 39":

We the people of the United
States, in order to form a
more perfect union, establish
justice, insure domestic
tranquility, provide for the
common defense, promote the
general welfare, and secure
the blessing of liberty to
ourselves and our posterity,
do ordain and establish the
Constitution of the United
States of America.

Corresponding formatted output by my system:

We the people of the United
States, in order to form a
more perfect union, estab-
lish justice, insure domestic
tranquility, provide for the
common defense, promote the
general welfare, and secure
the blessing of liberty to
ourselves and our posterity,
do ordain and establish the
Constitution of the United
States of America.

My system can do hyphenation for German and English, and
the language to be used (German or English) was actually
specified in the input document, but I had omitted this
specification for simplification above. (I'm using wrapping
algorithms and hyphenation patterns from the world of TeX.)


--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

Ben Collver <bencollver@tilde.pink> wrote:

On forking the Web by Rodrigo Arias Mallo, 2026-05-06

[...]

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.

I've always thought that the original sin of the http specification was
stating that clients should ignore unknown tags.

If I were to fork the Web, the 1st thing would be replacing that rule
with: "clients *must* refuse to render any page containing non-standard
tags".
--
Dario Niedermann -:- PGP key available at the best keyservers
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On Thu, 24 Sep 2026 03:47:44 +0200, Dario Niedermann wrote:

I've always thought that the original sin of the http specification
was stating that clients should ignore unknown tags.

If I were to fork the Web, the 1st thing would be replacing that
rule with: "clients *must* refuse to render any page containing
non-standard tags".

PostelrCOs Principle: rCLBe conservative in what you output, and liberal
in what you acceptrCY.
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

Lawrence DrCOOliveiro <ldo@nz.invalid> writes:

Dario Niedermann wrote:

I've always thought that the original sin of the http specification
was stating that clients should ignore unknown tags.

If I were to fork the Web, the 1st thing would be replacing that
rule with: "clients *must* refuse to render any page containing
non-standard tags".

PostelrCOs Principle: rCLBe conservative in what you output, and liberal
in what you acceptrCY.

Not sustainable as a general principle when there is any chance of
adversarial input. Nevertheless, itrCOs appropriate in this case, and a
browser that refused to render a page with a single unknown tag would
quickly be dumped by users in favor of a more forgiving one.
--
https://www.greenend.org.uk/rjk/
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

On 2026-09-24, Dario Niedermann wrote:

Ben Collver <bencollver@tilde.pink> wrote:

On forking the Web by Rodrigo Arias Mallo, 2026-05-06

[...]

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.

I've always thought that the original sin of the http specification was stating that clients should ignore unknown tags.

What does HTTP have to do with the SGML descendant where tags are?

If I were to fork the Web, the 1st thing would be replacing that rule
with: "clients *must* refuse to render any page containing non-standard tags".

I think you're missing the major point around which the web has been
designed: graceful degradation, and compatibility. It is *intended* that
HTML works that way, it is intended that it does not look the same
everywhere, the point of it is to be accessible from a quite diverse
universe of user-agents and platforms and machines.

Also, you're missing something else in this sentence: you're wording it
like a tag is either non-standard or known to the browser. You're
ignoring the possibility a tag is standard, but from a newer version of
the standard, or from a different standard than the ones the user-agent supports.
--
Nuno Silva
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

Nuno Silva <nunojsilva@invalid.invalid> wrote:

I think you're missing the major point around which the web has been designed: graceful degradation, and compatibility. It is *intended* that
HTML works that way, it is intended that it does not look the same everywhere, the point of it is to be accessible from a quite diverse
universe of user-agents and platforms and machines.

I'm not missing it, I'm saying that - while certainly allowing for wider accessibility - that philosphy also turned the web into a mess. Graceful degradation has nothing to do with it: you could get that even with
clients that refuse to render non standard-compliant pages, since
supporting a tag doesn't imply rendering it in a certain way.

you're wording it like a tag is either non-standard or known to the
browser.

Well... yeah? A browser that is compliant with a standard must know all
the tags that are part of the standard. A different version of a
standard is a different standard...

You might want to try and understand other people's point before
resorting to "you're missing" and "you're ignoring".
--
Dario Niedermann -:- PGP key available at the best keyservers
--- Synchronet 3.22a-Linux NewsLink 1.2

From Newsgroup: comp.misc

Nuno Silva <nunojsilva@invalid.invalid> wrote:

I think you're missing the major point around which the web has been >designed: graceful degradation, and compatibility. It is *intended* that
HTML works that way, it is intended that it does not look the same >everywhere, the point of it is to be accessible from a quite diverse
universe of user-agents and platforms and machines.

Unfortunately most people missed that. The whole notion that html provides
the data and the markup and the client browser provides the formatting
has disappeared on the web today. Today the whole point is to do whatever
it takes (standard or not) to force the browser to display everything exactly the way the designer wants. This has, if you ask me, destroyed much of the benefit.

Also, you're missing something else in this sentence: you're wording it
like a tag is either non-standard or known to the browser. You're
ignoring the possibility a tag is standard, but from a newer version of
the standard, or from a different standard than the ones the user-agent >supports.

Designers no longer care about standards, they care about gaming the browser. --scott
--
"C'est un Nagra. C'est suisse, et tres, tres precis."
--- Synchronet 3.22a-Linux NewsLink 1.2