- Introduction
- Prior Art
- Goals
- Extremely-Graceful Degradation
- Linking to External Content
- Specifications
- About
- License
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 is an alternative internet protocol meant to be used to exchange text written using GemText, 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 initiative is indeed extremely similar to SubWeb. It even comes with its own recommended HTML subset, but the result is still too complex, incompatible with older/simpler browsers, and potentially allowing insecure content.
GeminiWeb0/HTML0/CSS0/JS0
GeminiWeb0 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, as it pretty much implements the smallest set of features that are sufficient to render simple-but-pleasant, text-focused, web pages. NetSurf 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:
<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.