HTML guide when?

[Amelia]

One of the cool things I really like about the website is that Yukinu is actively trying to make it as compatible with obscure technologies as humanly possible. This site taught me about the existence of the <details> tag. Now I write my website page by page, by hand, and my 'once a frames user, always a frames user' philosophy knocks most of my site's sidebar menu off of browsers without <iframes> support, I would still love to learn more on how I could optimize my site further, what HTML tags and CSS attributes to use and what to avoid, and such.

[Leva]

Personally, on my website, I avoid iframe navigation by just having a handful (seven, to be precise) of "hub pages" that have a navigation sidebar: Home, About, Thoughts, Links, Art, Shrines, and Miscellaneous. Those are all hand-written.
Everything beyond that (as in, individual shrines, pages for my writing, blog articles and so on) just link back to the respective hub.

That way, if I want to change the navigation somehow, it's a 10 minute job per hand in seven files, and not a slog across like 45 pages. It is the most "vanilla" way of doing a navbar I have seen.

As for HTML/CSS, I recommend reading through the Ultimate Accessibility Guide to alt text:
https://axesslab.com/alt-texts/

Always close your tags, keep everything (tags, attributes etc.) lowercase except for the DOCTYPE. Avoid iframes, javascript wherever possible, and stuff exclusive to HTML5, or to some browsers (e. g. "marquee"/"blink" tags). Try to test on many screen sizes. Work with relative measurements (for example % values) rather than with absolutes.

You might also want to look into Microformats, which are tiny HTML-only-based conventions to mark-up a lot of data types and structures without any additional overhead:
https://microformats.org/wiki/get-started
For example, writing a recipe, you could mark up ingredients, individual steps, the photo, and so on in a recipe microformat; and as opposed to just putting them in <ul> or <p> tags, a computer can read your recipe suddenly and a sophisticated browser might be able to recommend similar recipes based on the microformat data you added to your website.

It's the difference between "ah, I am a browser and I see a 14px bold centered span with 10px justified text after it. If I have to guess... is this a headline with an article?" and "ah, it is marked up as a <h1 type="article_head"> and an <article> with an <author>" or whatever. Machine readable metadata.

[Yukinu]

One of the cool things I really like about the website is that Yukinu is actively trying to make it as compatible with obscure technologies as humanly possible. This site taught me about the existence of the <details> tag. Now I write my website page by page, by hand, and my 'once a frames user, always a frames user' philosophy knocks most of my site's sidebar menu off of browsers without <iframes> support, I would still love to learn more on how I could optimize my site further, what HTML tags and CSS attributes to use and what to avoid, and such.

Yes, I definitely need to write a comprehensive guide at some point documenting a lot of the tricks I use for backwards compatible site design. For example, here is my snippet for creating backwards compatible videos:

Code: Select all

<video style="max-width: 100%;" width="1920" height="1080" poster="video.png" controls="controls">
  <source src="video.ogv" type="video/ogg" />
  <source src="video.webm" type="video/webm" />
  <source src="video.mp4" type="video/mp4" />
  <object width="1920" height="1080" type="application/x-shockwave-flash" data="video.swf">
    <param name="movie" value="video.swf" />
    <param name="flashvars" value="controlbar=over&amp;image=video.png&amp;file=video.mp4" />
    <a href="video.ogv">
      <img style="max-width: 100%" src="video.png" />
    </a>
  </object>
</video>

The video is wrapped in a <video> tag with <source> tags in 4 different formats. Browsers that support the HTML5 <video> and <source> tags will go through the list and pick whichever video format it has codecs for. If a browser doesn't support HTML5 video but does have flash player, it will fallback to the <object> tag with the video encoded in SWF format. Finally, if the browser doesn't support video at all, it will fallback even further to an <a> tag with a picture of the video thumbnail and a download link to the video file (so even browsers like Netsurf without video, plugins, and scripts can still access the video). Looking backwards, that snippet will work on browsers that are 2 decades old, and as long as browser keep existing will probably work forwards for another 2 decades or more.

Some practical advice:

• I keep my browser viewport in 1024x768 resolution.
  • This was one of the most common screen resolutions in the 2000s, and designing your site around this resolution will ensure that it's viewable properly on older hardware.
  • Targeting this resolution doesn't compromise making your site mobile friendly either. Older browsers don't support media queries, but essentially the entire history of mobile browsers supports them, so you start with a backwards compatible desktop site, and scale it down to backwards and forwards compatible mobile friendly site.
  • For even better backwards compatibility, target 800x600 viewport.
• I don't use any new CSS features unless they have a clear fallback. For example, the background gradient on the site uses linear-gradient(), but I fall back to a gradient background image if the browser (like Netsurf) doesn't support that CSS feature. Background images have been a standard CSS feature for decades.
• I don't use any new CSS layouts. You can actually get flexible pages without flexbox or flexgrid by using the older CSS float layout and HTML tables.
• I keep copies of old browsers around. In particular, I tend to test on:
  • Palemoon (Goanna engine).
  • Opera 12 (before the shift to chromium).
  • IE8 (IE6 would be slightly better to test on, but I don't have a copy that works with WINE).
  • Netsurf (independent browser and engine that is available on many platforms, doesn't have any JavaScript).
• When I write JavaScript code, I generally write in ES3/ES5.
  • The JS engines are typically optimized for ES3/ES5, and a lot of ES6+ features are actually slower than similar ES3/ES5 ones (for example, document.querySelector('#foo') is massively slower than document.getElementById('foo'), and yet both do effectively the same thing).
  • The best way to learn ES3/ES5 is to pick up an old JavaScript book from the 2000s. JavaScript was actually quite cozy at this time, given how small the language was back then.
• When in doubt, check https://caniuse.com to see how long an HTML, CSS, or JS feature has been supported.

There is a term for this particular philosophy of of web development, Progressive Enhancement. In this philosophy, the developer starts the project by trying to add as many of their required features as possible using only the most basic and minimal of resources and tools, and then once all of the options have been exhausted, the dev then finally adds enhancements on top. The video snippet from above is an example. Going backwards, it starts with a link to a video, then adds a video for flash player, then older HTML5 codecs, and finally newer codecs. The basic <a> tag is enough to transport the video through the web, but the HTML5 video is an enhancement on top of it.

This site taught me about the existence of the <details> tag.

<details> is a great way to add dropdown menus without the need for JavaScript. If you look at the CSS I'm using on the site, I hide the <details> tag by default using CSS (via display: none since that CSS attribute is supported by very old browsers), and then use a @media query to unhide it once the page gets smalle[/b]r (and hide the default navigation). Old browsers that don't support <details> will never actually see it, and thus it won't cause any issues on those browsers (browsers generally treat unsupported tags as <div>s, so if I did it the other way around the navigation on older browsers would be affected).

[Guest]

Thank you guys. My site is pretty bare-bones as is so I met most of your advice's criteria already. After a deeper look into HTML4 and CSS2.1 specifications I also found out that <iframes> are in fact supported, but they didn't render in browsers like Netsurf because I used % for width and height as well as position:fixed which are not supported. Nonetheless I added a menu into the footer of my index pages. I've also replaced all the variables in my CSS with just plain old numbers and a comment after them for easier 'search and replace' shenanigans.

[Yukinu]

I've also replaced all the variables in my CSS with just plain old numbers and a comment after them for easier 'search and replace' shenanigans.

One backwards compatible solution to CSS variables is to use SCSS/SASS or another CSS preprocessor. For example, this CSS code.

Code: Select all

/* base.scss */
:root {
  --red-color: #ee0000;
  --green-color: #00ee00;
  --blue-color: #0000ee;
}

body {
    color: var(--red-color);
    background-color: var(--blue-color);
}

p {
    color: var(--green-color);
    background-color: var(--blue-color);
}

Can be converted to an SCSS equivalent:

Code: Select all

/* base.scss */
$red-color: #ee0000;
$green-color: #00ee00;
$blue-color: #0000ee;

body {
    color: $red-color;
    background-color: $blue-color;
}

p {
    color: $green-color;
    background-color: $blue-color;
}

And then compiled with the sassc compiler:

Code: Select all

sassc base.scss > base.css

To produce the following CSS code without the need for CSS variables:

Code: Select all

/* base.scss */
body {
  color: #ee0000;
  background-color: #0000ee; }

p {
  color: #00ee00;
  background-color: #0000ee; }

From the site designer's perspective, the functionality is effectively the same (variables in CSS), but the end result in the latter case is backwards compatible, while in the former case it requires newer CSS features.

Work with relative measurements (for example % values) rather than with absolutes.

I'm a bit iffy on relative measures.

• vh, vw, and calc can be useful but are not backwards compatible.
• I wouldn't necessarily rule out using em, rem units, since you can generally use px as a fallback (see the below example), but I've found that much of the benefits of relative units can be achieved by using <meta name="viewport" content="width=device-width, initial-scale=1.0"> and px units with @media queries while retaining backwards compatibility.
• % is generally backwards compatible and is useful for page layout.

Code: Select all

/* first font-size will be chosen for browsers without em support */
p {
  font-size: 12px;
  font-size: 1em;
}