I previously removed this from <head> because the first piece of
metadata should be setting the charset to utf-8. This commit adds it
back, but to the bottom of <head>.
- Add a cache-busting fingerprint to all the icons in the webmanifest
- Add a <meta> and open graph tag for a description.
- Include a 512px icon in the manifest
State that both dark and light color schemes are supported in the
document <head> to inform browsers before CSS is loaded and parsed.
Also added a bunch of comments.
- Changed: Make all color codes 3-char. Shave off a few bytes.
- Removed: all responsive layout besides the navigation links.
Everything else should work well at all window sizes without making
allowances for special cases.
- Removed: redundant CSS rules
- Added: centered images. Left-aligned images in a center-aligned column
of text break flow.
- Added: dark mode link colors for visited/active. Active link colors
give better a11y.
- Fix: don't show unnecessary scrollbar for <pre> blocks
Also put more comments in the source to explain why each rule is
important.
All this shrunk the CSS from 1065 bytes to 882 bytes (17% reduction)
- Text width was too wide on wide screens; reduce it.
- Make the nav-links' responsive layout for narrow viewports trigger at
a narrower window size. It used to trigger at 600px, but I made it
trigger at 32rem instead since the nav links aren't too wide. This
also handles cases where users' default sans-serif fonts are very
wide: rem measures by character width instead of pixels.
- Make the narrow-optimized multiline-navlinks the default, and make
widescreens a special case detected with a CSS media query.
Previously, widescreens were the default; however, this meant that
browsers that didn't support media queries (like dillo and netsurf)
couldn't switch to the multi-line navigation at narrow widths. This is
a good example of progressive enhancement; modern browsers will get
the same behavior as before, but the lowest common denominator will
see a better experience.
- Don't further reduce the max-width for narrow screens; narrow screens
are already narrow. We now have one less CSS rule.
- Use the recommended resolution for the open graph image
- Since the mask-icon is onl served as a cache-busted asset and never
served as a plain link from the site root, move it to assets/
- Cache-bust the webmanifest and put it in assets/
Reduce Cumulative Layout Shift (CLS) by declaring original image
dimensions in HTML before re-scaling with CSS. This tells browsers the
image's aspect ratio before the image and the stylesheet load, allowing
browsers to block out space accordingly to avoid making elements "jump"
during loading.
More info: https://web.dev/optimize-cls/
- Add open graph metadata for other apps to display link previews
- Add more rel="me" metadata for the Indieweb. Getting on the Indieweb
will take some time, but this is a good first step.
I just found out that lots of Android devices will letterbox icons; the
latest version of Lighthouse will preview an icon in the safe clipping
range, and that range was way too small for my existing icons. I made a
new version that was mask-safe with the white foreground shrunk down a
bit so it would fit. See [0].
[0]: https://web.dev/maskable-icon-audit/
For consistency, I renamed the Apple mask icon as well.
Why are there so many extensions to the HTML standard for icons? This is
getting ridiculous.
It's time for a rant about icon standards. Let's recap! what icons do I
have so far?
- A 192px apple-touch-icon. Apple icons are supposed to be 180px, but
192px gets re-sized down just fine. This used to be apple-specific but
then Android and others started using it. I picked 192px instead of the
standard 180px because we need...(next bullet)
- A 192px icon for Android devices. Rather than having a separate icon
for this, I just re-used the existing Apple icon in case the user's
browser wants both so it can just cache and re-use it.
- The original 32px favicon.png. I picked PNG instead of ICO because an
ICO containing the optimized PNG was a whopping 2kb while the png was
176 bytes. It looks fine when scaled down to 16px with a variety of
automatic downscaling algos, so there was no need to include an extra
16px version.
- A mask-icon. I was hesitant to implement this since it seemed very
vendor-specific (desktop Safari only), but it somehow became an
accepted registered extension to the spec [1] so I figured that it was
only a matter of time before a bunch of other things started using it.
- A webmanifest file to describe even more icons. It re-defines the
aforementioned 192px icons. I chose to re-use the icon for the same
reason as before. It also describes the next two bullets:
- favicon.svg: used in the manifest in case the device wants something
bigger than 192px.
- A maskable icon (svg), completely unrelated to the aforementioned
mask-icon, with the focus of the image shrunk down to handle cropping
e.g. on some Android devices.
[1]: https://html.spec.whatwg.org/multipage/semantics.html#attr-link-sizes
What I SHOULD have, in an imaginary world where web standards make sense:
- A 32x32 raster icon. Probably PNG, but lossless-webp migth work
too.
- A 16x16 raster icon, only if the 32x32 version doesn't downscale
well.
- An svg icon for any other resolution.
What I don't, and probably never will have:
- A msapplication icon for IE 10 on Windows 8.0, for adding sites to the
Windows 8 Start Screen.
- A browserconfig.xml in my site's root directory for adding sites to
the Windows 8.1+ Start Screen/Menu with custom icons.
Since MS dumped IE and switched to Edge, documentation for the above was
never updated. I don't run proprietary operating systems, so I can't
test adding a website to the tiled Start Menu or Windows Task Bar.
Now that MS re-wrote Edge as a Chromium-based browser, I really have no
idea how it handles icons; I'd imagine it just does what Chrome does,
but it probably does some odd witchcraft to support adding sites to
Start or the taskbar. Docs don't seem to exist. Until they update the
docs, I'll assume that adding MS icons would mean supporting a
non-standard IE-specific feature.
Due to its simplicity, my site should render fine in browsers going as
far back as IE5; it even works in KHTML. But there are some lines I
won't cross: it'll probably *render* on IE5 but it won't *load* since
https://seirdy.one is TLS 1.2/1.3 only. And it won't support special
proprietary non-standard extensions.
WTF we're almost at 80 lines. I should've just written a blog post.
