Category: Uncategorized

In previous posts I talked about the issues with the modern Web, how Web 1.1 (Static Web) can solve them, and how easy it is to publish existing websites on this new Web. But will people actually do that?

In this post I will talk about incentives. I believe, in the end of the day, everybody has an incentive to use Web 1.1.

Saving documents is a big deal

Saving doesn’t work well on the modern Web. When you try to save a page, it often appears broken. Even if it isn’t, where do you save it? In the cluttered Downloads folder, where you’ll never find it again? Or in some manually created folder structure that still isn’t much better? The reality is that people don’t save web pages—not because they don’t need to, but because it’s inconvenient.

With Continuous Space Interface (CSI) and new static data formats, saving web pages becomes a seamless experience. You can store pages you like directly on your zoomable desktop or even in a 3D environment, making them easy to find and interact with later.

Imagine browsing the Web and effortlessly collecting your favorite pieces of content, arranging them visually, and accessing them whenever you want. Many people, myself included, would love this ability.

The Role of Continuous Space Interface

Looking at demos of LZ Desktop you may think that this new interface is too exotic and won’t be very popular. I agree that CSI probably won’t become the primary interface for most people. It’s not well-suited for small-screen devices like mobile phones, and many users don’t own desktop computers. But that’s fine. As I mentioned in another post, CSI doesn’t need to be mainstream to have a significant impact on the Web.

Website owners want you to save their content

If you run a business, create content, or influence an audience, you want people to engage with your material. You want them to return to your website repeatedly.

Think about offline businesses. They hand out business cards, flyers, and brochures to stay on customers’ minds. Why? Because having a physical object increases the likelihood that a customer will remember them and return.

Now, imagine if every page on your website could serve the same purpose. People could download an article, place it on their desktop, and revisit it whenever they want. You wouldn’t know how often they engage with your saved content, but when they do, they might click a link and return to your site.

By supporting Web 1.1, website owners can boost engagement and retention. Instead of relying on users to remember and navigate back, they can let users save content in a meaningful way that encourages repeated interaction.

Backend Support Matters More Than Frontend Adoption: The RSS Example

Web technologies gain traction in two ways: frontend popularity and backend support. Frontend popularity is about how many people actively use the technology. Backend support is about how many websites implement it.

Take RSS, for example. It allows users to subscribe to website updates, yet in terms of direct usage, RSS is relatively unpopular. But if you look at website adoption, it’s widespread—almost every blog or news site supports it.

Why? Because RSS was implemented at the platform level long ago. If you run a WordPress site, RSS support is built-in by default. Most site owners don’t bother disabling it, so the technology persists, even if its user base is niche.

This same principle applies to Web 1.1. If backend support becomes widespread—through simple implementations like a WordPress plugin—it doesn’t matter how many users actively seek it out at first. As new data formats gain traction, mainstream browsers like Chrome and Safari will have more reason to support them. For most users, their first encounter with Web 1.1 will be through these browsers rather than dedicated apps. 

One is bigger than zero

In the example of RSS, if even one person wants to subscribe to your website, why not let them? Saying “one is too low a number, so I’ll have zero instead” makes no sense.

The same logic applies to Web 1.1. Implementing support for it is often as easy as installing a WordPress plugin. And there’s no reason not to. If even one person wants to download your content, why deny them that option?

Chicken-and-egg problems

What if Web 1.1, despite all its benefits, never becomes popular? Many good ideas have failed due to chicken-and-egg problems.

You might ask: Why would someone install an app for a new kind of Web that doesn’t really exist yet? Or why would a website owner publish their site on the new Web that seemingly nobody uses?

Come for the tool, stay for the network

There is a concept called “Come for the tool, stay for the network”. Here is a blog post about it. Take Instagram, for example. Initially, it was promoted as a tool for adding filters to photos. People installed it because they wanted the filters, not because their friends were already on the platform.

Likewise, when we are talking about initial stages of Web 1.1 adoption, we shouldn’t worry about how popular this new Web is.

The only app that can use Web 1.1 data formats currently is LZ Desktop. As a tool this app is useful even if we never create the new Web. It is just a big desktop, where you can collect all the things that matter to you, like text notes, web links, images. Web pages of the new kind (HDOC), that you can use in this app, come as a bonus. Xanadu-inspired visible connections between texts from different web pages come as another bonus.

Bring Your Own Network (BYON)

If you’re a website owner, you don’t need to wait for Web 1.1 to become mainstream. Assume no one has heard of it. Simply add a download link to your website, allowing visitors to save pages in the new format. Next to it, provide a link explaining how they can install the software to use Web 1.1 (for WordPress all of that is done by installing a plugin). In other words, promote Web 1.1 yourself. I call this approach BYON—Bring Your Own Network. Your network is whoever visits your website. Some of those people will start using Web 1.1 because of you.

Another scenario: Imagine you’re a teacher creating learning materials with features unavailable on the modern Web—such as visible connections between pages. You publish these materials on your website and instruct your students to download LZ Desktop to access them. Once again, Web 1.1 serves as a tool first. Your students are your network that you bring to Web 1.1.

Conclusion

Hopefully, you can now see that there is no insurmountable barrier to the widespread adoption of Web 1.1. There is no unsolvable chicken-and-egg problem—Web 1.1 simply needs to be used as a tool for saving web pages, and adoption will follow naturally.

In the early days of the World Wide Web, Tim Berners-Lee—the man who invented it—maintained a website where he listed newly created websites. Back then, the addition of each new site was an event worth noting.

I plan to do something similar for Web 1.1. Anyone who installs my plugin or provides static content in any other way can send me a link, and I will maintain a directory of such websites. This list will be accessible from the LZ Desktop client app via the ‘Explore Static Web’ button.

As the list grows, I may eventually develop a simple search engine to help users navigate it more easily.

This is yet another reason not to worry about the initial size of the Web 1.1 network. Even though it starts small, it will be highly navigable from the beginning, making it easy for early adopters to explore and contribute. As more websites join, discovery tools will improve, and organic growth will follow naturally.

SDOC is a format for 3D scenes on the web. Just like HDOC and CDOC it is a static format, meaning that it cannot include any scripts.

SDOC is currently not defined, but it will be similar to CDOC in that the main content will probably be located in a section that will use some popular format for 3D scenes, just like CDOC uses a popular 2D vector graphics format (SVG).

SDOC will probably have <head> section, <copy-info> section, and <connections> section just like HDOC, and CDOC.

SDOCs may contain HDOCs, CDOCs and even other SDOCs. All those documents may be included by reference.

What will 3D scenes be used for?

One use case I can think of is having something like a site map. Only instead of links to different pages you could have a 3D scene where you can surround your reader with your content.

In the video example, I move things around. This will be possible with local scenes that user creates. SDOCs downloaded from the web will probably be immutable.

Also, in the demo the 3D scene looks basic. But since the SDOC format will be based on some popular 3D format, you should be able to create scenes of any complexity.

CDOC is a format for 2D collages on the web. Just like HDOC it is a static format, meaning that it cannot include any scripts. CDOC may contain images, texts and anything an SVG file could contain. But also it may contain documents like HDOCs, SDOCs, and possibly even other CDOCs. Those documents are included by reference. Parent CDOC only defines how they look and positioned within its collage and their URLs. Documents are never included inline.

This format is currently implemented only partially. For example, adding other documents inside a CDOC is not yet supported in LZ Desktop.

HEAD

CDOC has head section just like HDOC and HTML. Inside of it it may have a <title> tag. Other things that may go into head section are not yet defined.

<cdoc>
    <head>
        <title>Title of my post</title>
    </head>
</cdoc>

SVG

The content goes into one inline SVG. You can use any elements SVG supports. There may be some restrictions on the use of classes. Scripts are not supported.

Documents included by reference will probably be presented by any valid SVG element (for example, an image) wrapped into an anchor tag with a specific class.

<cdoc>
    <svg xmlns="http://www.w3.org/2000/svg" width="400" height="300">
        ... (content goes here)
    </svg>
</cdoc>

PANELS (Not needed)

Panels like in HDOC are probably not needed. However there may be a need for side panel for some interactivity. So, some way to add the URL of side panel webpage may be added in the future. For now panels are not supported in CDOC.

COPY-INFO

This section will be similar to that of HDOC, but the mappings may include URLs not only of media files but of the embedded documents as well.

CONNECTIONS

This is an XML structure that contains information about documents the current document wants to connect to as well as floating links that connect those documents with the current documents.

Connections section will be supported by all three document types: HDOC, CDOC, and SDOC. For that reason its description is on a separate page.

HDOC stands for ‘HTML document’. It is a static format which means you can’t add a script to it. You can use CSS classes from a list of predefined classes, but you can’t define your own CSS classes or use inline CSS.

HEAD

HDOC has head section just like a regular HTML file. Inside of it it may have a <title> tag. Other things that may go into head section are not yet defined.

<hdoc>
    <head>
        <title>Title of my post</title>
    </head>
</hdoc>

HTML

While regular html file contains <body> tag, HDOC has <html> tag that serves the same purpose. Inside it you can enter html usually starting with <h1> header.

<hdoc>
    <html>
        <h1>Title of my post</h1>
        <p>This is a paragraph.</p>
    </html>
</hdoc>

PANELS

Optionally HDOC may have panels section. It is responsible for header and footer which are standardised and will look the same on all websites. You as an author can only specify colors, main logo or website name, and a list of links. It may also contain link to a paired web page (usually used for comments).

Root Element: <panels>

Attributes:

• bgColor (optional): A color string representing the background color of both top and bottom panels.
• textColor (optional): A color string representing the text color in both top and bottom panels.

Child Elements:

1. <top-panel> (optional): Defines the top panel of the page.
2. <side-panel> (optional): Defines the URL of a page that will be shown on the side of the main document.
3. <bottom-panel> (optional): Defines the bottom panel of the page.

---

Child Element: <top-panel>

Defines the top section of the webpage.

Attributes:

• bgColor (optional): A color string for the background color of the top panel.
• textColor (optional): A color string for the text color in the top panel.

Child Elements:

1. <site-name>(optional): Represents the site name.
   • Attributes:
     • href (optional): URL to navigate to when the site name is clicked.
   • Content: The text of the site name.
2. <logo>(optional): Represents a site logo.
   • Attributes:
     • src (required): URL to the logo image.
     • href (optional): URL to navigate to when the logo is clicked.
3. <a>(optional, multiple): Represents a hyperlink in the top panel.
   • Attributes:
     • href (required): URL of the hyperlink.
   • Content: The text of the link.

---

Child Element: <side-panel>

Defines a side panel of the webpage, typically used for comments section.

Attributes:

• side(optional): Specifies which side the panel appears on.
  • Values:
    • "left": The panel is on the left side.
    • "right" (default): The panel is on the right side.

Content:

• The URL of webpage to be displayed in the side panel.

---

Child Element: <bottom-panel>

Defines the bottom section of the webpage.

Attributes:

• bgColor (optional): A color string for the background color of the bottom panel.
• textColor (optional): A color string for the text color in the bottom panel.

Child Elements:

Content: The text of the message.

<section>(optional, multiple): Defines a section within the bottom panel.

Attributes:

title (optional): The title of the section.

Child Elements:

<a>(optional, multiple): Represents a hyperlink in the section.

Attributes:

href (required): URL of the hyperlink.

Content: The text of the link.

<bottom-message>(optional): Defines a message at the bottom of the panel.

Example:

<panels bgColor="#dd1a1a" textColor="#ffffff">
    <top-panel bgColor="#db5432" textColor="#939393">
        <site-name href="https://google.com">hello   website</site-name>
        <logo src="https://mywebsite.com/wp-content/uploads/2024/12/logo.png" href="https://mywebsite.com"/>
        <a href="https://mywebsite.com/about">About</a>
        <a href="https://mywebsite.com/contacts">Contacts</a>
    </top-panel>
    <side-panel side="left">https://mywebsite.com/post1/comments</side-panel>
    <bottom-panel bgColor="#2d2d2d" textColor="#e8e8e8">
        <section title="About">
            <a href="https://mywebsite.com/me">About me</a>
            <a href="https://mywebsite.com/contacts">Contacts</a>
        </section>
        <bottom-message>All rights reserved 2025</bottom-message>
    </bottom-panel>
</panels>

Some notes on using <panels> section.

All panels – <top-panel>, <side-panel>, <bottom-panel> – are optional.

You should use either <site-name> or <logo> but not both. Default background color for all panels is white, and default text color is black. Attributes bgColor and textColor of <panels> tag define colors for both top and bottom panels. The same attributes of <top-panel> and <bottom-panel> tags will override those set in <panel> element. So if both panels should have the same colors you should define them only globally in <panels> element. If they must be different then define them for each individual panel.

---

COPY-INFO

Optional section that is used only when HDOC is a copy of some other HDOC in which case this section is required.

This section is currently not supported by LZ Desktop, but will be in the future.

Child Elements:

<source>(required, multiple): A URL of the source page. If hdoc represents a copy of a copy of some hdoc, then multiple source tags must be used. In general you should avoid making copies of copies if the original document is available. But if its unavailable and you have to make a copy of a copy, using multiple source tags allows us to save the history of the document.

Attributes:

• copied-at (required): An ISO 8601 timestamp of the moment when the copy was made. For example (UTC), 2025-01-01T12:00:00Z or (with Timezone Offset) 2025-01-01T12:00:00+02:00

<media-mappings>(optional). This element represents a collection of mappings for media files, allowing you to replace old URLs with new ones. Contains one or more <m> elements, each defining a mapping between an old URL and a new URL.

Child Elements:

<m>: Represents a single mapping.

<old>: The original URL of the media file.

<new>: The updated URL of the media file.

<media-mappings> 
<m>    
    <old>https://example.com/images/image1.jpg</old>  
    <new>https://mywebsite.com/images/image1.jpg</new> 
</m> 
<m> 
    <old>https://example.com/images/image2.png</old> 
    <new>https://mywebsite.com/images/image2.png</new> 
</m> 
<m> 
    <old>https://example.com/images/image3.svg</old>  
    <new>https://mywebsite.com/images/image3.svg</new> 
</m> 
</media-mappings>

Since section is currently not supported, the details may change when the support is finally implemented.

CONNECTIONS

This is an XML structure that contains information about documents the current document wants to connect to as well as floating links that connect those documents with the current documents.

Connections section will be supported by all three document types: HDOC, CDOC, and SDOC. For that reason its description is on a separate page.

In another post, I compared every web page to a jail cell with two prisoners: paralyzed and harmless content, and unpredictable and dangerous code.

Because content on the Web is locked inside those jail cells, we can’t do certain things with it: annotate, combine, or create visible connections between pages. Even something as basic as saving a page often doesn’t work properly.

The Solution: New Data Formats

We need a web page format that contains HTML but is inherently incapable of containing scripts. A format like that wouldn’t need a jail cell. We’d be free to do all those things—annotations, content combinations, connections—that are currently impossible.

I proposed such a format, along with two other formats. I call the new format for text-based web pages HDOC.

But a new data format alone isn’t enough. If all we do is introduce it, we’re just creating a separate, smaller Web next to the existing one. Imagine the massive, entrenched Web—let’s call it Web 2. And next to it, a tiny Web 1.

If Web 1 is small and separate, how popular will it become? Will mainstream browsers ever support it? Some people—educators, for example—might use it for specific projects, like interactive parallel histories with visible connections. They’d publish materials on their websites, and students could access them using specialized software.

That’s fine. But it still leaves most content locked inside existing websites. Can we also free that content, instead of just creating new content in the new format?

Getting content out of the jail

Here’s the key insight: The jail of Web 2 is your browser. It starts empty. You request a web page, and your browser downloads it and locks it up.

But the content itself doesn’t live in that jail. It lives on a server.

Most web pages today are dynamic, meaning they don’t exist as standalone files. They’re generated on demand, pulling content from a database. That content is stored separately from the code, and separately from unnecessary elements like headers, footers, and menus.

So, getting content into HDOC format is easy: we just need a piece of code on the server that creates an additional endpoint for each page. It takes the same content from the database the original page would use, wraps it in an HDOC template, and sends it to the client.

Adapting servers for Web 1.1

How do we get this code on all servers? It’s a gradual process. Only website owners can do it. 

For WordPress sites, I developed a plugin. Install it, configure it, and every page on your site will have a static version. Original page will have a download link.

For other content management systems, similar plugins need to be developed.

For custom-built sites, the owner would have to implement a custom solution—but it’s not hard. Just extract the data from the database and wrap it in the HDOC template.

If a website consists of standalone HTML files, the only way to adapt it for Web 1.1 is to generate a static HDOC version of each file. Fortunately, such websites usually have only a few pages, so this process is often straightforward.

What About Web Apps?

Some websites act more like apps—think social networks. They don’t just serve up pre-built pages; they send you code that builds the page in real-time inside your browser.

That doesn’t work in Web 1.1, where code is not allowed on the client. So, these sites would need to modify their infrastructure, adding server-side code and possibly extra servers to generate static versions of their pages.

For social networks, the extra server load will be relatively small. Think about how many tweets you scroll past before finding one worth saving—that difference can be orders of magnitude.

Supporting the Static Web (Web 1.1) will come at virtually no cost for large websites and, for many small sites, it will be completely free.

Incentives

Will people actually start adding the necessary code to their websites? I believe everyone has a reason to do so. It might be difficult to explain at first, but once momentum builds, Web 1.1 adoption could grow exponentially—effectively duplicating the entire Web. I delve deeper into incentives in another post.

Conclusion

If enough websites adopt HDOCs, it won’t just be a small parallel web. It will start unlocking the content that’s currently trapped in Web 2. And once that happens, new ways of using the Web—annotations, recombination, richer interconnections—will become possible all over the Web.

For a long time, there have been only two main ways to interact with a computer screen: command-line interface (CLI) and window-based graphical user interface (GUI). I came up with the third one. I call it continuous space Interface (CSI).

What is wrong with window-based interface?

Have you ever noticed how awkward it is to navigate your computer? First of all, you don’t have enough space. The size of your screen determines how much working space you have.

Everything is crammed into sliding windows that constantly overlap. If you want to view one thing, you have to push something else out of the way. Or you stack windows on top of each other, creating a mess.

Because there is always not enough space, everything is dense. Whenever you need to make a choice, you always have to choose out of 100 items.

• Need to open an app? Here is a list of your 100 apps.
• Need to use a bookmark? Here are 100 bookmarks to choose from.
• Need to find a note? There are countless notes, so you have to use search.

Windows are constantly shifting relative to each other, making it hard to orient yourself. Every time you need to switch contexts, you have to pause and think, How do I get there?

The only thing that remains somewhat stable is the folder hierarchy—which is a nightmare of its own. Humans didn’t evolve to navigate tree structures. It’s an unnatural, abstract way to organize information.

Also, why do we still have to name every file we save? In the real world, you don’t label every piece of paper you set on your desk.

Imposed hierarchies

Apps impose hierarchies that you may not want to use. For example, you may have a certain project in mind. There are things on your computer that belong to that project, like bookmarks, notes, files, etc. But where are they? They are all over the place.

• Bookmarks live in your browser, buried among bookmarks from unrelated projects.
• Notes are trapped in your Notes app.
• Files are hidden somewhere in a folder maze.

Each time you need something, you’re forced to either sift through 100 options or rely on search.

How did we get here?

A lot of these design choices were made when computers were primitive by today’s standards.

• Hierarchical directories? Invented before computers even had screens.
• Window-based GUI? Developed in the ’70s, when it made sense given the limitations of the time.

Back then, these ideas were practical. Today, they’re just outdated traditions.

We now have computers powerful enough to render entire 3D worlds in real-time—yet we’re still clinging to outdated design principles like folder hierarchies. Instead of designing interfaces that work for us, we keep making things convenient for the computer.

The solution. Continuous space interface

You know what’s easy to navigate? The real world.

In the real world, you don’t shuffle through sliding windows—you place things in space. Related objects are positioned closer together. You don’t need search bars or hierarchical menus to find your stuff. You just know where things are because of spatial memory.

So why don’t computers work the same way?

They can. We already build immersive digital spaces in video games. Imagine an operating system designed like that. Instead of staring at a cluttered desktop, you’d enter a spatial environment—a 2D or 3D space where your data isn’t locked inside folders but arranged visually, like objects in a room.

No more sliding windows—just move through your workspace instead of rearranging it.

No more file names—just like objects in real life don’t need labels, your digital documents can be identified by their location in space.

No more rigid hierarchies—just arrange things in a way that makes sense to you.

You may think that such navigation will be too slow. But in reality it will be like playing a video game on a God mode. There will be all sorts of navigational tricks and shortcuts that will make you navigation super fast while keeping it continuous. You want to avoid ‘teleportations’ or instant changes in your environment that disorient you.

No imposed hierarchies

In a spatial interface, you control the organization.

Say you’re working on a project. Instead of digging through separate apps, you could have everything—notes, bookmarks, images—right there in one space.

Imagine a simple rectangle representing your project. Inside, you place everything related to it. No more choosing between 100 options or relying on search. Instead, your choices are always visually and spatially obvious.

You can organize your projects the same way, by placing related projects closer together.

This may remind you of folder hierarchies. But this is a hierarchy that you create. Not something inconvenient that is imposed upon you.

Here is an example of a 3D interface:

How to implement Continuous Space Interface

We don’t need to build an entirely new operating system from scratch. Instead, we can start with an app. While a dedicated OS might be useful in the future, the best way forward is to test the concept in a more controlled way first.

We can also define a limited scope to begin with. The app could handle essential elements like:

• Text documents
• Images
• Links
• File shortcuts
• Lines and arrows for organization

More features can be added later. Do we need spreadsheets? Maybe—but it’s not necessary to include everything from the start.

LZ Desktop

I’ve already built an early version of this concept. I call it LZ Desktop (Large Zoomable Desktop). It’s far from finished, but I released it anyway—because it’s the first step toward building a new kind of web.

As I continue to improve the app, others can start creating content in new formats that currently only this app understands.

You can download the app here.

How I came up with this idea

I wouldn’t have realized there was something fundamentally wrong with computers if not for Ted Nelson. He started designing interfaces for computer screens before computers even had screens, imagining a world where computers would connect and interlink information seamlessly.

The way I understand his vision, connectivity was meant to be the core feature of computers. You should be able to link and combine pieces of content from different places—whether on your local system or across the network. Instead of isolated files and rigid structures, everything would flow together.

But his ideas didn’t prevail. Instead, computers and the web became highly containerized. Everything is locked inside a box—a file is a container, a web page is a container, an app is a container. The seamless connectivity Nelson envisioned was thrown away, all in the name of security and scalability.

I believe connectivity is too important to sacrifice. There are other ways to ensure security without isolating everything into silos. As for scalability, you don’t need to scale everything. The most common actions people take on computers—writing, linking, saving information—could be standardized, eliminating unnecessary variations in how different apps handle the same tasks. There’s no need for every application to reinvent how text is processed or how links are created.

Instead of forcing users to navigate a maze of folders and incompatible tools, we could create an environment where these fundamental actions work seamlessly across the system. For more specialized cases, containers can still be used, but they shouldn’t be the default for everything. 

Post scriptum

At first glance, this post might seem off-topic for this website, which is focused on transforming the Web rather than computer interfaces in general. But the Continuous Space Interface is deeply connected to that transformation. It doesn’t need to become mainstream to have an impact—its mere existence can set off a chain reaction that pushes the Web toward new formats and interactions. But that’s a topic for another post, and this one is long enough already.

The World Wide Web started as a web of documents. That was back in the early ’90s. Web pages were static HTML documents—simple, read-only pages that just presented information. There was no interactivity. Then, in 1995, JavaScript was added to browsers, changing everything.

When you add a script to a web page, the page has to become a container. You don’t want the code on a page to access your file system, for example. You don’t want it making unauthorized requests to other servers. So, browsers imposed all sorts of restrictions to keep code in check. But in doing so, they also locked up content.

The Web as a Jail

Imagine each page in your browser as a jail cell. Inside every cell, there are two prisoners: content and code. Content is like a disabled person—paralyzed. It consists of text and images, which just sit there passively. It’s harmless.

Code, on the other hand, is unpredictable. You don’t know who wrote it. You downloaded it from some website, and now you have to run it on your computer. So, it’s placed in a container—a controlled environment. Each web page is its own separate container.

Why Is This a Problem?

Each page, being locked in its own container, becomes its own isolated universe, completely disconnected from everything else. The entire Web is now just a collection of parallel worlds with no bridges between them.

Because of this, certain features become impossible. For example, you can’t have visible connections between pages. You can’t combine multiple documents from different websites onto a single page.

You also run into all sorts of problems with saving and caching documents. Try saving a web page, and very often, the saved version appears broken. Pages today are too dependent on live server connections. If a server goes down, the content disappears.

The Web started as a web of documents, but it was transformed into a web of containers running apps inside them. These apps often don’t function without an internet connection. They construct pages on the fly, eating up your computer’s RAM and slowing everything down. Worse, many of them track your activity and collect data on you.

The Solution: Bring Back the Static Web

The Web should primarily be a web of documents, with containers used sparingly. Right now, it’s the opposite—it’s a web of containers. Even if a page has no code, it doesn’t matter. It’s still in a container. Browsers treat all pages the same.

To rebuild the Static Web, I propose three new data formats:

• HDOC: A static equivalent of an HTML document. It contains standard HTML tags but is designed for longevity and easy archiving.
• CDOC: A collage format that can contain images, text, lines, and other documents (including HDOCs). It’s based on SVG and is partially defined at this time.
• SDOC: A 3D scene format that can include various document types. This is still in the conceptual phase but will be based on an existing 3D graphics format.

All three formats are purely static and contain no executable code. This means they don’t need to be locked inside a container. You can save them on your computer, and they will always appear the same. They have no dependencies. They are as robust and enduring as Sumerian clay tablets.

By adopting these formats, we can move back to a Web that is durable, reliable, and truly interconnected—just as it was meant to be.

Inspiration for the new Web

The Web I propose—Web 1.1, or the Static Web—is heavily inspired by Ted Nelson’s Xanadu project. Ted Nelson, one of computing’s pioneers, coined the word “hypertext.” Today, we associate hypertext with HTML, but what he envisioned in the 1960s was much more ambitious.

Modern Web links (which Nelson calls “jump-links”) are just one small part of what Xanadu aimed for. Xanadu had visible connections between documents, transclusions (where a document could include parts of another document), built-in versioning, and more.

I’ll dive deeper into Xanadu in another post.

Will Web 1.1 succeed?

You may be skeptical. After all, anyone can invent a new data format. The real question is whether it will gain adoption.

The reason I’m optimistic about Web 1.1 is that I believe I’ve identified strong incentives for website owners to start using these new formats.

I will talk about that in another post.