(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 <p> 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 ---