-----
code: subweb
home: /subweb/
sourcehut: subweb
title: SubWeb
subtitle: "A Safe, Small, Simple Subset of the Web"
summary: "A safe, small, simple subset of the Web aiming at improving safety, compatibility, and simplicity of web pages."
content-type: project
conver: true
active: true 
changelog: true
stage: prototype
version: 140-3
license: CC-BY-4.0
-----

### Introduction

Today's World Wide Web is huge, and is very different from the original vision of its creators. More often then not, web sites are bloated, exceedingly complex, they rely on scripts to function, and try to extort as much personal information as possible by employing the most desperate privacy-invasive techniques.

A lot of web sites are not even _sites_ anymore, they are _apps_, and the Web itself became a _platform_ rather than a place to publish hypertexts.

While the majority of people are now well-used to spend their time on the Web within walled gardens, they don't notice or care about the bloat, the invasive ads, and the dark patterns that plague a lot of sites, there are still some people that care about the original vision of the Web, about a text-first experience, without ads or unsafe content, and bloat-free. 

This document attempts to fix what's broken with today's Web by advocating for simpler web sites, and simpler specifications. 

This is _SubWeb_, a safer, smaller, and simpler subset of the Web.

### Prior Art

The concept of creating an alternative to the Web or its key building blocks is not new. The following sections list a few similar efforts and why they differ from SubWeb.

#### Gemini

[Gemini](https://geminiprotocol.net) is an alternative internet protocol meant to be used to exchange text written using [GemText](https://lionwiki-t2t.sourceforge.io/gemtext.html), a lightweight markup language similar to markdown but only able to manage text, links, headings, lists, blockquotes, and preformatted text.

While it is definitely simpler than HTML over HTTP, it is probably an overkill (why create a new protocol when HTTP is just fine?) in simplicity (no styles whatsoever, nothing).

#### SmolWeb

The [SmolWeb](https://smolweb.org) initiative is indeed extremely similar to SubWeb. It even comes with its own recommended [HTML subset](https://smolweb.org/specs/index.html), but the result is still too complex, incompatible with older/simpler browsers, and potentially allowing insecure content.

#### GeminiWeb0, HTML0, CSS0, JS0

[GeminiWeb0](https://bkil.gitlab.io/gemiweb0/) is actually the closest effort to SubWeb. For now it is basically just a collection of notes, but it seems promising. 

Still, the inclusion of JavaScript as _partially supported_ is probably unnecessary if the purpose is to focus on hypertexts. Furthermore, it is also an  attack vector that can make browsing potentially unsafe.

### Goals

The three main goals of SubWeb are the following:

- Safety
- Compatibility
- Simplicity

Each of these goals contributes to trim the amount of permitted functionality compared to the standard Web.

#### Safety

SubWeb pages should be safe and not expose users to security risks. The best way to achieve that is to remove as many attack vectors as possible.

This means:

- No JavaScript or scripts of any kind
- No WASM, applets, objects or similar technologies.
- No framesets or iframes
- All assets (styles and images, essentially) must be loaded from the same origin as the SubWeb site.
- HTTPS is recommended, and pages should be served via HTTPS if they contain forms that submit sensitive data, they distribute software or other material that should be downloaded from a safe and known web site.

Also, inline styles (using the style tag or attribute) or images mixed-in with HTML (e.g. using the `data:` pseudo-protocol) are permitted but somewhat discouraged because:

- they increase the damage that can be done by attackers via HTML injections
- they make the source of HTML documents less readable

#### Compatibility

SubWeb pages should be made to last and be compatible with as many web browsers as possible. 

The best browser to target is [Dillo](https://dillo-browser.github.io), as it pretty much implements the smallest set of features that are sufficient to render simple-but-pleasant, text-focused, web pages. [NetSurf](https://www.netsurf-browser.org) is another minimalist and simple browser, but more advanced than Dillo. 

This means:

- No MathML, or similar XML code embedded in HTML
- No SVG, WebP, or similar, only JPG, PNG, or GIF images are permitted, .
- No audio, video, or other multimedia content
- No embedded fonts
- No flexbox, CSS grid, or similar. Floats are permitted and so are tables though, so some sort of very basic layouting is possible.
- No CSS transitions, transformations, shadows or similar 

#### Simplicity

While HTML5 was hailed as a the biggest improvement to the HTML standard, it adds a lot of extra elements that may be  considered superfluous, as they can easily approximated using existing, more common, elements.

This means that the following elements should not be used:

- main
- header
- footer
- nav
- aside
- progress
- figure
- figcaption

In most of these cases, a `div` element with suitable `class` attribute can do the job just fine.

### Extremely-Graceful Degradation

If a functionality is only supported in modern browsers but:

- it does not alter the visual appearance or functionality of the site
- it does not interfere with the rendering in simpler browsers like Dillo or NetSurf

...then it is considered safe to use. 

One of the clearest examples of this _extremely-graceful degradation_ is the viewport meta tag:

```html
<meta name="viewport" content="width=device-width, initial-scale=1.0">
```

Although not processed by Dillo (and pointless, in that context, as it only works on desktop operating systems), it does not alter its rendering of the page but it does make an enormous difference for mobile support.

A not-so-clear-cut case is the `border-radius` CSS property, because it _does_ alter the visual appearance of elements on the page if not supported, and may cause web sites to look very different in such cases.

### Linking to External Content

When linking to external content using the `a` tag, a `rel` attribute should be added to provide a hint about the destination of the link, in terms of the content it serves, for example:

- **subweb**, if the destination site conforms to the SubWeb specifications.
- **smolweb**, if the destination site conforms to the Smolweb specification.
- **fullweb**, in other cases.

Of course this is just a hint and based on the linker's own knowledge about the destination site, and by no means provides any guarantee; however, it can be useful to improve the overall user experience, especially if:

- Different links are styled accordingly
- Browsers themselves start providing default styles or hints

### Specifications

These SubWeb guidelines are formalized into two separate specifications for subsets of HTML and CSS.

#### SubHTML

_Coming soon!_

#### SubCSS

_Coming soon!_

### About

Originally written by Fabio Cevasco on 2026-06-20.

### License

[Creative Commons &mdash; CC BY 4.0](https://creativecommons.org/licenses/by/4.0/)