We only use about 50% of the capabilities of the World Wide Web. Reader's Web is the missing half of the Web that we can build. Here, I'll introduce the concept of the Reader's Web.
First, let's make sure we're on the same page about what the Web actually is. A lot of people confuse the Web with the Internet, so it would probably be helpful to explain how the two differ.
The difference is simple: the Internet is a network of computers. The World Wide Web is a network of documents. Computers are connected by wires; documents are connected by hyperlinks.
So, think of the Web as a collection of documents. Perhaps this isn't the most precise definition of the Web, but it's good enough for our purposes.
There are two possible types of web page. So far, however, we've been using only one of them.
Each web page has an owner, a writer and a reader. Those are not necessarily three separate people. You can think of them as roles. Often, the person who owns a website also writes its content. In that case, they are both the owner and the writer. In other cases—for example, on social media websites—the owner is a social media company, and any user can be both a reader and a writer.
The two kinds of web page differ in who decides what the page looks like—or, in other words, who provides the styles. The content is always provided by the writer. But who provides the styles? There are only two possibilities: either the owner (publisher) or the reader.
So far, we've only had web pages whose owner provides the styles. For that reason, we can call the current Web the Publisher's Web. What I propose is that we should also build the Reader's Web, where the reader decides what a web page looks like.
Before we go any further, I want to stress that everything I'm going to talk about here is already available to us. We don't have to wait for mainstream browsers to start supporting new document types.
There is a very popular type of web page. We can call it a content page. Basically, it's a page containing an article or a blog post.
This is what it typically looks like.
It has a title. Its content consists of a single column of text. It may have a comments section, top and bottom navigation bars, a sidebar with additional links, and so on.
How is such a page constructed? Like all other web pages: all of its content, including the navigation panels, is placed inside the <body> tag of an HTML document. Styles are then applied to it.
The Reader's Web approach is to define a completely new document type. I've already done that, by the way, and the new document type is called HDOC (Hypertext Document). It is an XML-based document. The only part that contains HTML is the <content> tag, which holds the text of the article. Everything else—including the title and the links in the navigation panels—is stored in XML tags.
HDOCs don't contain information about how they should be styled. There may be exceptions for things like aligning an image to the left, center, or right. But the author shouldn't be able to make major layout changes. For example, an HDOC shouldn't be able to have two columns of text instead of one.
The idea is that the client application (the browser) downloads the document and applies its own styles to it. The browser may even offer multiple themes that the user can choose from. In the end, it is the reader who decides what such pages look like. Content pages (HDOCs) from all websites will share the same theme.
It may seem unnecessary. If we already have a universal way of constructing any kind of web page, why would we need a new, specialized way of constructing one specific type of page?
Because it gives us a couple of advantages.
There is a concept in urban planning called a desire path. It is an unofficial path created by people walking where it is most convenient rather than where planners expected them to walk.
Sometimes, instead of trying to force people to use the paths that were designed in advance, planners observe these natural paths and build proper walkways along them.
The Web has existed for more than 35 years. During that time, people have created their own "desire paths" — patterns of how information is published, shared, and consumed. A content page is one of those patterns. It is a document with a title, text, and a predictable structure that appears again and again across millions of websites.
Standardizing this type of document is simply recognizing a pattern that has already emerged and making it a first-class part of the Web.
And the infrastructure for this already exists. Typically, a web page is just a record in a database containing fields such as a title and HTML content. A relatively small change in server code can allow the same content to be delivered in a different document format.
Another way to look at Reader's Web is as a continuation of a trend that has existed throughout the history of the World Wide Web.
In the early days, many websites were highly customized. They had unique layouts, animated images, unusual navigation, and experimental designs. Over time, websites became more polished and professional, while also becoming more standardized and consistent.
Some people may regret that change, but the shift toward standardization happened for a reason. It improved usability. Readers no longer needed to learn a new interface every time they visited a different website.
If you want to experience the early Web again, you can visit sites like Neocities and browse the many vintage-inspired pages created there. They can be fun and nostalgic, but many of the design elements that once felt exciting can now become distractions from the actual content.
And now we have social networks where authors don't control presentation at all, and this model has become completely normal for millions of people.
Reader's Web continues this long-term trend by standardizing the format of a content page and moving presentation choices from individual websites to the reading environment. The author no longer needs to spend time designing every visual aspect of their website. They can focus on creating content, while readers can choose how that content is displayed.
The result is a Web where design becomes a choice made by the reader rather than a requirement imposed by every individual website.
As I said earlier, we don't need browsers to support new document formats directly. I wrote a more technical article explaining how we can introduce new document formats that work even though they are unknown to mainstream browsers.
That said, if Reader's Web ever becomes popular, browsers may start supporting its document formats natively. That would make the system more efficient, but it wouldn't add any functionality that we can't already provide ourselves.
You can read more about the technical details here: How to Build Reader's Web.
→ A 5-minute demo of visible connections:
https://www.youtube.com/watch?v=rNVB3R0yW9E
→ Install the extension:
https://chromewebstore.google.com/detail/visible-connections/hlckcdbgknflkkciojgdbhomdnegimbm
→ Then explore examples here (some of the examples will work without the extension):
https://reinventingtheweb.com/explore-static-web/
→ Install my plugin on your WordPress site:
https://wordpress.org/plugins/static-web-publisher/
If you want to publish visible connections on your website:
→ How to create and publish connections (30 min):
https://www.youtube.com/watch?v=hZuB7WCJPBI
If you want to understand the system in more detail:
→ Full explanation of the project (44 min):
https://www.youtube.com/watch?v=1Lm9WchLcBw
→ Ideas for the future (46 min):
https://www.youtube.com/watch?v=uFtwsFuMNVw