(2024-01-01) In 2024, HTML2 still is (almost) everything you really need
------------------------------------------------------------------------
Hi there. It's a miracle for me to be able to survive this far through all
this. But here I am, not willing to reflect on the past shitty year, knowing
that this one might probably get even shittier. In my next post, I'm going
to tell you something about my company gave me as a Christmas present, but
now I'm going to concentrate on something really basic: the Web.
Again, it might seem strange to write about the Web on Gopher, but first,
I'll probably create a Web mirror of this phlog at some point (to replace
the aging chronovir.us which expires soon and I'm not sure if I'll prolong
the domain), second, let's face it, despite how good Gopher is, it will
never get the majority of the audience you're trying to reach out to. This
might be a good thing (as a filter from the lame crowd), but this also means
that there are some tech-savvy people who might be interested in your ideas
and projects but just don't know about Gopher or are too lazy to take an
additional step to read your material. Heck, even on Gopherspace, I
constantly stumble upon links to GitHub that can't even load properly
without JS anymore...
Anyway, what I'm trying to say is that Web presence is inevitable nowadays.
However, it is fully on us to make this presence non-bloated. Of course, we
cannot fully get to the Gopher's level of purity but we still can make our
pages the oldschool way, with minimum amount of styling and no unnecessary
luggage. The secret is that we must employ... a lot of practices that are
considered "bad" by modern web design conventions.
What do I mean by this? First and foremost, I mean this HTML boilerplate you
should use for every page:
Yes, now I hope you see all the "bad" practices. For instance, if you look up
the tag and the attributes, you'll see that they are not
recommended and discouraged to use all over the MDN and other resources. In
fact, however, this is the most efficient and universal way to style your
text. Just like with CSS, you can supply a comma-separated font list in the
"face" attribute of the tag with the most generic one taking the
least priority by putting it at the end of the list, so here's your font
adaptation. And using doesn't contradict the HTML2
spec either. Ancient browsers that don't know what a viewport is will just
ignore this tag, but the newer ones will do their job by reflowing your text
according to the screen specs.
To be on the safe side, you can also add some inline styling to the
tag style attribute, e.g. for duplicating the font family or setting the
line height for the browsers that understand it. But the amount of CSS
should be kept at an absolute minimum and your pages must be at least
readable and functional with no CSS applied at all.
I recommend testing your pages on three or four browsers: Dillo, NetSurf, any
Firefox derivative and (optionally) any WebKit derivative. Yes, in this
particular order. Dillo hasn't been updated since 2015 but still is the
default browser in some minimalist distros and has the lowest RAM footprint
out of all GUI-based browsers, not counting Links2 in the GUI mode. If you
make your page look fine in Dillo, I guess it will look fine elsewhere. The
only quirk about Dillo you can disregard is that it tends to make all
non-standard fonts bolder than they are.
As for mobile device testing, try to use the smallest and the oldest ones. If
you have a KaiOS phone, that's nice, but ideally, your pages should be
functional even on 2.3-inch MAUI phones and 6-inch browser-enabled
e-readers. And for these purposes, I would only limit the set of tags to the
following ones: html, head, meta, title, link, base, body, br, div, p, h1,
h2, h3, h4, h5, h6, big, small, center, b, i, u, a, img, input (only these
types: text, password, button, submit, reset, image, checkbox, radio,
hidden), select (+multiple), option, textarea, form, ul, ol, li, table, tr,
th, td, hr. Of course, other formatting tags allowed in HTML2 can be used
too, but the results might vary from browser to browser. Use of tables
should be really limited if you aim for mobile support.
Speaking of which, there is another controversial topic: HTTPS. Old devices
usually don't like it: either CAs or algorithms are unsupported, or, if
we're talking _really_ old devices, they lack the processing power to deal
with SSL/TLS. So, here's my take on this problem:
1. Whenever possible, serve both plain HTTP and HTTPS content. Do not enforce
HTTPS redirection if the user explicitly visits HTTP URLs.
2. When serving HTTPS, enable TLS v1.2 and the following cipher suites on the
server side (IANA convention): TLS_RSA_WITH_AES_128_CBC_SHA,
TLS_RSA_WITH_AES_256_CBC_SHA, TLS_DHE_RSA_WITH_AES_256_CBC_SHA. This will
ensure maximum compatibility with old systems that are not possible to
upgrade to TLS v1.3.
For OpenSSL, these identifiers translate as:
TLS_RSA_WITH_AES_128_CBC_SHA = AES128-SHA
TLS_RSA_WITH_AES_256_CBC_SHA = AES256-SHA
TLS_DHE_RSA_WITH_AES_256_CBC_SHA = DHE-RSA-AES256-SHA
Usually, enabling just the first or the second suite is sufficient. Same goes
for gzipping the content: the server must only compress your pages when
requested by the browser to do so.
If you, just like me, hide HTTP services behind Traefik and like them
containerized, if you only need static HTML content to be served and can't
stand bloatware like Nginx, you can use a wonderful spa-to-http container to
do the job by putting something like this into the existing compose.yaml
file with your Traefik-based TLS resolver (in this example, it's called
"myresolver"):
spa-to-http:
image: devforth/spa-to-http:latest
container_name: spa-to-http
restart: unless-stopped
environment:
GZIP: true
BROTLI: true
SPA_MODE: false
labels:
- "traefik.http.routers.websrv.rule=Host(`[your_domain]`)"
- "traefik.http.routers.websrv.tls=true"
- "traefik.http.routers.websrv.tls.certresolver=myresolver"
expose:
- 8080
volumes:
- "[your_website_root_dir]:/code"
Note that the spa-to-http container doesn't seem to support live reloading as
of now but you can restart it every time you've deployed your website. It
doesn't take long.
Another important topic is navigation within the page. Some young folks think
it is impossible without JavaScript. In fact, it has been there from the
very beginning of HTML, and it's called named anchors. Yes, the name
attibute initally only made sense in the tag and served exactly this
purpose: to mark various parts of the page () that can
be later referenced to with such links. Now, you
don't even have to use named anchors explicitly (unless you find a browser
where you have to): modern browsers also allow you to reference any existing
element that has an id attribute (instead of the name attribute) in an
tag in the very same way.
When thinking about readability, we can also take some care of the people who
just download the raw HTML source code and view it "as is". Unless in
preformatted text block elements like or , all consecutive
whitespace characters in raw text nodes are collapsed into one whitespace
(0x20). So you still can write your paragraphs (in tags, for instance)
in a 78-column formatted fashion and the browser will have no problem
rendering them as they should: as long as it's not a preformatted text
element, it doesn't care, but now the people who view the raw HTML can read
this text more easily too. Same about tag indentation: you can only leave it
where it helps _humans_ recognize important parts, and all inevitable junk
that doesn't carry any meaning for the reader can be collapsed into a single
line.
Do not overuse text coloration. And don't ever use it for stressing anything
meaningful, only for some decoration that can be treated as fully optional.
Remember there still are greyscale e-ink devices, B/W LCD devices, console
terminals and so on. Same thing can be said about images: insert them
sparingly. Not to mention they also increase network traffic consumption.
Last but not least, forget about "pixel perfection". Unless absolutely
necessary, don't use image maps and other things that depend on pixel
positioning. Don't expect every browser to have the same margins, the same
fonts, the same rendering and flow. Trust the browser defaults to perform
the most basic formatting tasks for you. Concentrate on the contents, not
presentation. After all, this is what made the old Web so valuable that we
miss it now.
Happy new year!
--- Luxferre ---