Swap updated favicons

[tinykite]

What this does

Updates the previous LIL favicons with a group of icons featuring the new LIL branding. This update notably introduces an adaptive svg, that will appear in either a dark or light-mode variant depending on if a user prefers dark or light color schemes. Chromium and Firefox browsers support this — as far as I can tell from user support tables and from my own testing, Safari does not.

However, Safari can fallback to the provided pngs. There is also an ico file provided for Windows.

Notes

Favicon image sizes

In the past, I've relied on a Figma plugin to generate a huge variety of favicon sizes. I didn't realize, until researching what favicon sizes genuinely benefit user experience and branding, that most favicon generators generate a totally unnecessary variety of icons:

The Evil Martians article "How to Favicon in 2024: Six files that fit most needs" condenses down the list to 5 image sizes they argue actually benefits users.

Web manifest icons

I initially followed recommendations in the Evil Martians article for a web manifest for a static website:

 "name": "The Library Innovation Lab at Harvard University",
 icons: [
        { src: "/icon-192.png", sizes: '192x192' },
        { src: "./icon-512.png", sizes: '512x512' },
      ]

But noticed that the manifest failed to pass a Lighthouse test for maskable icons. While it's not intended to be comprehensive for what we'd need to include for a functioning PWA that supports offline mode, it felt like an oversight to include PWA icons but not ones formatted in a way Google recommends.

I resized the logos within their respective viewports to meet the recommendations in the article Adaptive icon support in PWAs with maskable icons . A "maskable icon" essentially is just a logo that can be safely masked — without being clipped or otherwise cropped — within a circular area that has a radius of 40% of the total size of an image.

In the web manifest itself, this intent is indicated in a purpose attribute:

{
    "name": "The Library Innovation Lab at Harvard University",
    "icons": [
        { "src": "{{ site.baseurl }}/assets/images/favicon-192.png", "type": "image/png", "sizes": "192x192", "purpose": "maskable" },
        { "src": "{{ site.baseurl }}/assets/images/favicon-512.png", "type": "image/png", "sizes": "512x512", "purpose": "maskable" },
        { "src": "{{ site.baseurl }}/assets/images/favicon.svg", "sizes": "any" }
    ]
}

Screenshot

I tested that favicons loadly correctly in Safari, Chrome, Arc (Chromium-based), and Firefox. Pictured below are light and dark mode variants in Arc and Firefox, plus a png fallback being displayed by Safari:

How To Test

I've discovered that the least-error prone way to check out a branch locally is to not follow the instructions github provides on each PR. It feels much more consistent to:

• Add a new remote for my fork of the LIL website, named meaningfully (for example, named tinykite)
• Run git pull tinykite to make sure you have the latest remote branches
• Run git checkout update-favicons to checkout this branch

[tinykite]

Note: this image includes 20px of padding between the logo and the edge of the container per Evil Martian recommendations for how Apple displays touch icons. But, if we determine this isn't desirable, easy to change.

[tinykite]

Building a PWA manifest is a big topic, so this isn't intended to be comprehensive for all what we would need to support an offline mode (and specifically to branding, for example, would we want to specify a maskable icon?). This is the minimum that Evil Martians recommends, so it felt like an easy add that we could adopt and update with a more comprehensive information in the future.

Edit: After running a Lighthouse test to validate these icons, I decided we should support maskable icons. More details in the PR description above.

[rebeccacremona]

Same, I'd recommend adding {{ site.baseurl }} to these paths too. If you add

---
---

to the top of the file, Jekyll will make the substitution during build :-)

[tinykite]

Thanks for spotting this. As a quick heads-up, I'm still working on polishing this — it's not yet ready for review

[tinykite]

Also appreciate the heads-up about Jekyll's substitution process!

[rebeccacremona]

Even though we aren't serving at a subpath, for style I'd recommend including {{ site.baseurl }} here, that is, <link rel="manifest" href="{{ site.baseurl }}/manifest.webmanifest">. Right now, that's just set to "", so when Jekyll builds, the full URL becomes "/manifest.webmanifest", just like you have it. But, if we were to have Github pages serve at a subpath like it does by default (e.g. https://harvard-lil.github.io/website-static), we'd set baseurl to /website-static and when Jekyll builds, this URL would become "/website-static/manifest.webmanifest", and everything would continue to work.

[tinykite]

Thanks for spotting this — this was a small oversight I planned to fix before marking this PR as ready for review

[rebeccacremona]

an adaptive svg, that will appear in either a dark or light-mode variant depending on if a user prefers dark or light color schemes

wicked cool

[rebeccacremona]

🎉