Hi,

I'm Rodrigo and this is my personal opinion on what I would imagine
the "smolweb" idea would be. I'll try to keep my reasoning objective,
but as a human, is not really posible. Also, I don't like the complexity
of the "modern web" so I really appreciate the idea of making something
simpler.

For reference, this comes from a request Adële posted on Fediverse:

Hi @dillo !
I would be happy to get feedback from a "browser" (and humans behind
it!) about #smolweb guidelines :
https://smolweb.org/guidelines.html

I'll start from the "about" page.

About smolweb

Promoting a simple unbloated web!

Nowadays, hardware resources of our personal devices are essentially
oversized to manage bloated websites. If we incite web designers to
return to a lighter web, small devices such as old PC, old smartphones,
retro-machines and small boards could be usable.

This is the goal of the smolweb concept.

I think that having a precise goal and why choose that goal is the most
important thing this specification should address first. The other
decisions would depend on this one.

What exactly is bloated? Yes, we all know what a bloated website looks
like, and we can say a website A is less bloated that another one B. But
what exactly makes a website bloated? Can we measure it?

If we define it in a precise way we can measure it with an automated
tool. This allows machines to reject bloated websites from a search
engine. It also allows a validator to reject your website, so you know
it has too many things.

From the point of view of Dillo, I could think about two things mainly:
the computing effort that takes to read the HTML and do the layouting by
transforming it into absolutely positioned boxes with text or images
(you can think of transforming it into a PDF, as it requires similar
effort), and how many resources does it need from the web. So, measuring
these two things, CPU operations and network size, you have a starting
point as a measurement that you can use to define what is bloated.

If I were the one to provide a goal it would be something along this
lines: to provide an specification that defines an strict subset of HTML
5 with the objective of reducing the computing and network requirements
to render and interact with those pages and make them available to slow
networks. Making them available to (say) 99% of the population on the
Solar System (that includes the ISS) that have access to Internet on
their available hardware and network connection (these numbers require
research to determine what is a proper cutoff).

As a side effect of limiting the computational complexity, you are
already limiting the complexity of the HTML subset. For example,
rendering elements like floats is extremely complicated to do
properly, even if for a webmaster is only a matter of placing an
additional CSS rule. You see that is not the other way around, it comes
from supporting the initial goal.

Another topic is: what is the purpose of supporting a given set of
machines? Is it because you like to use an old Atari (even if you have
access to much more capable machines) or is it because in your situation
it is very hard to get something better? Are you in the middle of the
ocean with your boat and only have a slow Satellite link or in a small
village with no fiber optic near?, or you simply don't like to wait 0.5
seconds extra when opening a website?

My approach with Dillo is to be able to provide a browser that runs in
all machines available to a large percent of the population including
their slow networks. Mainly because my home town computer is slow and my
network too and I grew used to it.

I'll base my comments on the assumption that this is the end goal.

This site attempts to define what a smolweb is and to give some
guidelines for use. It is
certainly not the only solution to get unbloated websites, but it will
help authors, designers and webmasters who want to build
"smolwebsites". Do not read these recommendations as a bible, this is
only what I think to be a good way to build respectful websites for
authors, readers, internet bandwidth and hardware.

I think you may want to separate the recommendation part from the
mandatory part. An specification can be eventually enforced by a
validator while a lax recommendation cannot.

Let's move on to the "guidelines" page:

Guidelines for a smolweb

The first thing that I'm missing is a semantic version for the document:

https://semver.org/

So you can change it in the future and be able to communicate the
importance of the changes to the users.

For example, increasing the major of the version if you have introduced
changes that cause a given page to require major rewrites to conform to
the new version of the standard. Or only increasing the minor if
retro-compatible new features are added.

What to do and not to do

Write short code

To be smol, obviously, first step is to write small code and avoid
unnecessary things. Are you sure it is useful to redefine HTML
components with a huge CSS framework? What does it bring to your site?
Trying to build a site which is exactly the same on all devices and
screens is vain and expects bloated pages. Forcing a font size is even
a bad idea for visually impaired readers. So, try to write short code.

Writing a short page will cause less network cost, but it may still
cause a lot of computation.

You may want to set a limit both in computation and network budget.

For example, rendering your guidelines page on Dillo with CSS enabled
requires on my machine 231 Minstr (million instructions as in 231·106),
which is around 73 ms of CPU time (this will vary wildly among CPUs, but
is easier to understand for humans). This includes the TLS negotiation
and decryption.

However, if I disable loading CSS styles the number of instructions goes
down to half, only 110 Minstr (42 ms). Now, if I just open another tab
with your page again, Dillo will use if from the cache and it won't
perform the TLS work again, so that goes down to 50 Minstr (13 ms) which
is around the time the screen needs to refresh at 60 Hz.

Those numbers are with the Dillo version I use for debugging, which is
built with -O0, which doesn't optimize the code. If I use the default of
-O2, it goes down to 21 Minstr (9.8 ms).

Now, if I open the guidelines page on Firefox, I get 697 Minstr (456 ms
of CPU). As a comparison, loading the nytimes.com requires 4927 Minstr
(2 s of CPU), which is almost 45 times more computing power.

Assuming a very bold approximation of one instruction per cycle and
using a Pentium 1 at 60 MHz, opening the guidelines page on Dillo
without CSS or TLS and -O3, would "only" take 350 ms. But the beginning
of the page can probably be rendered much faster than that.

$ perf stat -p $(pgrep dillo)

$ perf stat -p $(pgrep dillo)
^C
 Performance counter stats for process id '484622':
 42,36 msec task-clock:u # 0,010 CPUs utilized
 0 context-switches:u # 0,000 /sec
 0 cpu-migrations:u # 0,000 /sec
 258 page-faults:u # 6,090 K/sec
 65.211.319 cycles:u # 1,539 GHz
 110.945.310 instructions:u # 1,70 insn per cycle
 18.451.235 branches:u # 435,552 M/sec
 262.435 branch-misses:u # 1,42% of all branches
 4,273009673 seconds time elapsed

The best smolweb is a site readable without any CSS and JavaScript code.

I don't think this should be considered only best practice, I think it
should be enforced that a website MUST be readable without CSS and JS.

Specifically, if you generate content with JS, your website is not
readable without JS.

The recommendations about these points are :

• do not use style attribute to include CSS code in your HTML pages,
  use a <style> block in the <head> section, or, better, link your
  stylesheet with a <link> tag in your head section. If a browser does
  not need CSS (think about
  Braille display, or console mode browser), it does not need to load it

I agree, but this also makes your website have to perform 2 requests to
load the website with CSS (at least initially). This is a limitation of
the HTML design.

• do not use JavaScript! many old browsers can't execute script.
  Moreover, this code is often the cause of the swelling of sites

Use the right tags, the right way

HTML has a large set of tags and the basic error is to use them to
format graphically your pages instead of keeping their semantic aspect.
Some HTML tags or attributes even have a role for accessibility.
Instead of using a simple DIV with a specific class and its style
definition, it's a better idea to use the semantic tag corresponding to
its content. Recent browser and specific displays are able to take
advantage of it. <header>, <footer>, <main>, <nav>,
<section>, <article>, <aside>, <details>, <summary>,
<figure>, <figcaption> and <data> are good tags to identify the
different parts of your page.
Even if some are recent and unknown by old browsers, they are
recommended for clean smolweb pages. They are described in the HTML
subset page.

I agree, even if Dillo doesn't support all of those yet.

Include the necessary declaration in your header code

The first thing read by a browser is the first line on your HTML page,
so it must help to browser to determine clearly want it will find. The
<!DOCTYPE> line has this role. If you want to use tags proposed in
the HTML subset page, it is necessary
to use the html 5 doctype : <!DOCTYPE html>

This shouldn't be optional, your website MUST define the HTML5 doctype
line: <!DOCTYPE html>.

The second line is the html tag with the lang code attribute
corresponding to the language of the page content (see the ISO 639-1
codes) : <html lang="en">

Indicating which encoding (or character set) is used in your page
permit to avoid bad display of accent. UTF-8 does everything you want
(and more), it’s a widely accepted standard and basically supported
everywhere: use UTF-8! This declaration is a meta tag in the head
section:
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" >

This should also be a MUST.

And, to be compatible with all size of screen, defining the viewport to
the width of the screen device is very simple. Just add another meta in
the head section:
<meta name="viewport" content="width=device-width, initial-scale=1.0" >

This is fine provided your page is readable without CSS.

To respect the user choice between light and dark mode, if you don't
specify background and foreground colors in your stylesheet, you can add
this simple meta in the head:
<meta name="color-scheme" content="light dark" />

Slashes at the end are not recommended in HTML5.

The head section can also contain links to external resources such as CSS
stylecheets
<link href="/style.css" rel="stylesheet" type="text/css" >

The type attribute is not needed for HTML 5:

https://html.spec.whatwg.org/multipage/links.html#link-type-stylesheet

It's always a good idea to provide a favicon, because browsers are
looking for /favicon.ico even if this file does not exist, and they do
it for every page. Providing one allows them to cache it a the first
request. It could be proposed within different formats...
<link rel="icon" href="/favicon.ico" type="image/x-icon" >
<link rel="icon" href="/favicon.png" type="image/png" >

Do not use media content if not necessary

If you embed images in your pages, try to make them small. Some tools
permits to get good result with dithering
method. Don't forget to write an
alternative description in the alt attribute of the img tag.

I don't think this an adequate solution. It forces people with good
bandwidth to see use quality images.

I think a better solution is to allow several choices and let the client
pick one (or none) to render. Maybe offering low and high quality is
enough.

You can use the srcset attribute in the img tag or the source
element in the new picture. This also allows using different image
formats if needed.

Additionally, you can assume that people concerned with network usage
will disable loading any image. So you should allow it to be readable
based on the alt text alone (if possible).

Does your pages really need a logo? Sometimes, a simple text or word is
enough.

I think this restriction is not necessary if we already limit the
network bandwidth.

Limit the use of audio and video to the strict minimum. The best way to
include a multimedia content is to link to it with a simple <a> tag.
It will propose to the user to save it to his/her disk or to open the
right application to play it. It is useful to indicate the size of the
file near the link.

I wouldn't oppose to embed audio or video using the <audio> or
<video> tags with multiple sources. Those already allow the content to
be downloaded.

Additionally, they should allow users to stream a segment only of the
file and then decide to download it entirely. This requires the server
to support a byte range.

In the worst case scenario (like in Dillo) they will only be rendered as
links.

For sure, it shouldn't auto load or play anything.

Do not embed font

Loading a font from your web server or from a specific CDN will bloat
your site. Try to stick to common fonts available on almost all
computers with a fallback to a default serif, sans-serif or
monospace. These three fonts use fonts that the user has defined as
its preferred ones in its browser settings.

You will find a good resource on the great
Modern Font Stacks compilation.

I don't think you should assume any font installed on the system apart
from serif, sans-serif or monospace. That means that you won't be able
to control the exact size or style of the text. So you shouldn't rely on
that anyway (this comes from the same rule of not relying on CSS styles).

Additionally, implementing the whole Unicode set is very hard. You may
want to also impose some restrictions on which glyphs you should expect.

Ensure readibility

Good practice, for accessibility, is to respect the font size defined by
the user.

html { font-size: 100%; }

And to adapt your style relatively to the root (html element) size
using rem units.

h1 { font-size: 2rem; }
h2 { font-size: 1.6rem; }
h3 { font-size: 1.2rem; }
small { font-size: 0.8rem; }

I agree on the relative sizes, but consider that the page may not load
any style, so it should be perfectly readable without those font size
specifications.

Use emoticons, not emojis

Recent unicode characters, such as emojis, are not recognized by old
browsers. Remember the good old time of emoticons, made with ASCII
characters :-) if you need to specify a mood or to precise irony or
humour, they still are a good alternative.

Disclaimer: I really hate that we ended up with Emojis in Unicode.

Another problem with Emojis is that they are not rendered the same, and
depending on the specific image that the user sees, emotions may not be
transmitted the same (this happens to me across platforms).

This is easy to solve, just put an image with alt text if you need
something more complex than a emoticon. This also helps to people that
cannot read very well the emotions based on a picture, as it is
available in the alt text.

It also allows people to share any picture, not just the ones
preselected by your font (or some corporation) for your current device.

Use table for tabular data only

At the beginning of the web, before 2000, tables were used to format a
webpage graphically. This is a real bad solution. Use tables, only if
necessary, and to format data (think about spreadsheets).

Agree.

Check your code

It is easy to write bad code. W3C provides a tool to
check that your page is conforming to
standard.

Use the Nu validator to ensure that you are checking it against the
HTML 5:

https://validator.w3.org/nu/

It would cause other doctype versions show as errors.

Try your site on different kind of browser such as recent browsers
(Firefox, Chromium), console mode browsers (Lynx, W3M), old widely
ported simple browsers (Netsurf, Dillo, Mosaic) and on small screen
devices (smartphones and tablets). If you haven't these specific
browsers, try your site without its stylesheet: it would be less
beautiful (maybe) but it should remain usable.

You should also check your site by emulating large network latency and
low speed, and ensure that you can begin reading the page early. And
also that you can finish rendering your page under a computational
budget. The specific limits require more research based on your goals.

Supply an RSS feed

Smolweb surfers like to have the possibility to follow you without a
specific social network. RSS feeds are always used by many internauts.
They permit to be aware of new publication on your site. If your posts
are short, please, put full content of your last articles in your RSS
xml file.

This should be specified with the link tag for autodiscovery:

<link rel="alternate" type="application/rss+xml" href="https://mysmolwebsite.tld/rss.xml" title="My smolwebsite!" >

I don't think we should allow entries to be cut. Or at least, we should
have a way to allow users to specify they want the whole entry. This
allows people to download the feeds at night and then go out to a place
with no internet and continue reading the posts there (this happens to
me in some places in the metro).

As most bloat pages don't offer that feature, I need to use a crawler
that goes to the site, applies a ridiculous amount of computational
power to render it as plain HTML and expose it as the feed content.

Enable https protocol

https (http over TLS on port 443) is standard since Letsencrypt
proposes free certificates. It would be a good idea to supply simple
http (on port 80) if you want your site is usable by very old browsers
or on systems with old CA chains. However, your site could become a point
of failure for a man-in-the-middle attack.

Agree.

So, ensure to enable https and a redirection from http connexions to
https.

I think the user should have the last word on which protocol it should
be used. If I know what I'm doing, I should be able to request a page
via simple HTTP.

For sure, by default it should redirect all users to the HTTPS for
security reasons, but for some scenarios on networks with a lot of
latency where the TLS cost is too high that may cause the user not to be
able to even load the content.

I would need to research this a bit more in case the valid scenarios are
not even not worth the risks.

Code sample

Here is a sample of a standard HTML page using these recommendations :

<!DOCTYPE html>
<html lang="en">
	<head>
		<meta http-equiv="Content-Type" content="text/html; charset=utf-8" >
		<meta name="viewport" content="width=device-width, initial-scale=1.0" >
		<meta name="description" content="My smolwebsite about all my hobbies..." >
		<meta name="color-scheme" content="light dark" />
		<link href="/style.css" rel="stylesheet" type="text/css" >
		<link rel="icon" href="/favicon.ico" type="image/x-icon" >
		<link rel="icon" href="/favicon.png" type="image/png" >
		<link rel="icon" href="/favicon.gif" type="image/gif" >
		<link rel="alternate" type="application/rss+xml"
			href="https://mysmolwebsite.tld/rss.xml" title="My smolwebsite!" >
		<title>The title of my page</title>
	</head>
	<body>
		<header>
		<strong>My smolwebsite</strong>
		<nav><ul>
			<li><a href="index.html">About</a></li>
			<li><a href="posts/index.html">Posts</a></li>
			<li><a href="contact.html">Contact</a></li>
		</ul></nav> 
		</header>
		<main>
			<article>
			<h1>My first post</h1>
			<p>Happy to have a smolwebsite!</p>
			</article>
			<aside>
				Other related posts:
				<ul>
					<li><a href="other-post.html">other post</a></li>
				</ul>
			</aside>
		</main>
		<footer>
			Published by <strong>me</strong> under Creative Commons BY SA
		</footer>
	</body>
</html>

Closing remarks

I'll leave my analysis here for now, as studying all the elements of the
subset and their implication would require a lot of effort. But I think
most that work can be done automatically.

So instead, I'll focus on some points I consider important to take into
account.

You should provide a way to validate the specification that can be
automated in a program. At least those aspects that can be checked
without a human.

You may want sites to report that they conform with the smolweb spec in
a way that can also be parsed by humans and machines. This can include a
value of estimated cost of CPU and network that is required to load it
(which should be computed when running the validator).

There are a some "small web" iniciatives, but I would like them to
converge on a single, unified, standardized specification that is easy
to understand. It is fine if you don't agree fully on all topics, but at
least to have one specification that is common to all of them that
serves as the basis for the "small web".

You may want to talk with the W3C in case they are interested in
supporting something like that, but you may want to start by choosing
how many words the spec may have at maximum, not to end up with with a
gigantic spec.

Lastly, I don't like the "smol" or "small" or "indie" part on the name
that much. The goal is not for it to be small or just follow a set of
not mainstream rules. The goal is to let every person be able to access
the web. As a consequence that causes the specification to be small and
simple. Maybe something like the Universal Web would be more in line
with the main goal.

Rodrigo.

Do not use media content if not necessary

If you embed images in your pages, try to make them small. Some tools
permits to get good result with dithering
method. Don't forget to write an
alternative description in the alt attribute of the img tag.

I don't think this an adequate solution. It forces people with good
bandwidth to see use quality images.

I think a better solution is to allow several choices and let the client
pick one (or none) to render. Maybe offering low and high quality is
enough.

You can use the srcset attribute in the img tag or the source
element in the new picture. This also allows using different image
formats if needed.

I'd avoid this if not necessary. This allows fingerprinting users based on device/browser settings without any scripts. I try to stick to one binary signal impacting fetched resources, and went with dark/light theme preferences.

Check your code

It is easy to write bad code. W3C provides a tool to
check that your page is conforming to
standard.

Use the Nu validator to ensure that you are checking it against the
HTML 5:

https://validator.w3.org/nu/

It would cause other doctype versions show as errors.

I don't recommend taking validator errors at face-value. Really common features that aid progressive enhancement, like the supports() CSS selector, aren't implemented.

Try your site on different kind of browser such as recent browsers
(Firefox, Chromium), console mode browsers (Lynx, W3M), old widely
ported simple browsers (Netsurf, Dillo, Mosaic) and on small screen
devices (smartphones and tablets). If you haven't these specific
browsers, try your site without its stylesheet: it would be less
beautiful (maybe) but it should remain usable.

You should also check your site by emulating large network latency and
low speed, and ensure that you can begin reading the page early. And
also that you can finish rendering your page under a computational
budget. The specific limits require more research based on your goals.

Regarding computational budget: this should also take into account the computational complexity of an accessibility tree. Many performance tricks fall flat here.

Supply an RSS feed

Smolweb surfers like to have the possibility to follow you without a
specific social network. RSS feeds are always used by many internauts.
They permit to be aware of new publication on your site. If your posts
are short, please, put full content of your last articles in your RSS
xml file.

This should be specified with the link tag for autodiscovery:

<link rel="alternate" type="application/rss+xml" href="https://mysmolwebsite.tld/rss.xml" title="My smolwebsite!" >

I don't think we should allow entries to be cut. Or at least, we should
have a way to allow users to specify they want the whole entry. This
allows people to download the feeds at night and then go out to a place
with no internet and continue reading the posts there (this happens to
me in some places in the metro).

As most bloat pages don't offer that feature, I need to use a crawler
that goes to the site, applies a ridiculous amount of computational
power to render it as plain HTML and expose it as the feed content.

We should also have an upper limit before going for paginated Atom feeds; perhaps a 500kb full-text compressed Atom feed needs pagination.

Enable https protocol

https (http over TLS on port 443) is standard since Letsencrypt
proposes free certificates. It would be a good idea to supply simple
http (on port 80) if you want your site is usable by very old browsers
or on systems with old CA chains. However, your site could become a point
of failure for a man-in-the-middle attack.

Agree.

So, ensure to enable https and a redirection from http connexions to
https.

I think the user should have the last word on which protocol it should
be used. If I know what I'm doing, I should be able to request a page
via simple HTTP.

For sure, by default it should redirect all users to the HTTPS for
security reasons, but for some scenarios on networks with a lot of
latency where the TLS cost is too high that may cause the user not to be
able to even load the content.

I would need to research this a bit more in case the valid scenarios are
not even not worth the risks.

I don't think it's possible to do this without also opening a vector for users who don't wish to have traffic intercepted and pages altered. We have TLSv1.3 implementations that run on vintage computers now. Keeping page weight low and supporting connection re-use should be how we reduce latency, not allowing traffic interception.

You can use the srcset attribute in the img tag or the source
element in the new picture. This also allows using different image
formats if needed.

I'd avoid this if not necessary. This allows fingerprinting users based on device/browser settings without any scripts. I try to stick to one binary signal impacting fetched resources, and went with dark/light theme preferences.

I agree that adding an option to load high or low resolution images adds (at least) one bit of information to discriminate the user. But having a user on a very slow connection or fast also provides more information, specially if the bad actor can intercept the whole traffic and perform a deep analysis (i.e. CloudFlare).

I don't think HTTP or HTTPS is designed to protect users against fingerprinting from actors with enough resources. I don't consider myself knowledgeable enough to claim that I can provide any guarantee against fingerprinting either, that doesn't fall under the security theater term.

Use the Nu validator to ensure that you are checking it against the
HTML 5:

https://validator.w3.org/nu/

It would cause other doctype versions show as errors.

I don't recommend taking validator errors at face-value. Really common features that aid progressive enhancement, like the supports() CSS selector, aren't implemented.

I agree. My point was to ensure the proper HTML5 doctype is set, which will enable deprecation errors.

For sure, by default it should redirect all users to the HTTPS for
security reasons, but for some scenarios on networks with a lot of
latency where the TLS cost is too high that may cause the user not to be
able to even load the content.

I would need to research this a bit more in case the valid scenarios are
not even not worth the risks.

I don't think it's possible to do this without also opening a vector for users who don't wish to have traffic intercepted and pages altered. We have TLSv1.3 implementations that run on vintage computers now. Keeping page weight low and supporting connection re-use should be how we reduce latency, not allowing traffic interception.

It may be okay if we assume clients reading a "smolweb" site are actually not that resource constrained. A TLS implementation may not fit on a microcontroller, but I would say is a reasonable tradeoff to at least expect TLSv1.3.

Still, that won't protect users from having traffic intercepted if you use CloudFlare or a similar service. It probably would be benefitial to have a threat model defined first.

A (very long) post of mine with many relevant parts:

Best practices for inclusive textual websites.

@Seirdy

A (very long) post of mine with many relevant parts

Yes very good post!
I think I will pick many ideas for smolweb.org

thanks

I would radically reduce the size of the feed file, otherwise you keep downloading almost the same content every time a single article is published. (See twtxt). I would call larger than 16kB already a smell. Older articles should be accessible through a permalink-based link structure (via tags and dates). You may offer a separate feed for each category, though (i.e., non-overlapping top level tags). Paging a feed file is also a smell.