I had thought my existing bookmark for butterfly identification covered moths well enough, but apparently it only includes the larger families. For smaller species (such as the ever-present grass moths), UK Moths appears to have a pretty excellent level of information 👏

Max has put together one of the best examples of how container queries will fundamentally change the way front-end development works. Better still, they provide extremely clear explanations of container queries, web components, and how they combine to unlock true intrinsic design.

Container Queries are one of the last few missing puzzle pieces in component-driven design. They enable us to give components intrinsic styles, meaning they can adapt themselves to whatever surroundings they are placed in.

I also really love the way they think about separating CSS in layout versus content; that feels like something worth co-opting now:

It’s generally a good idea in CSS to separate “layout” from “content” components and let each handle their own specific areas of responsibility. I like to think of Japanese bento boxes as a metaphor for this: a container divided into specific sections that can be filled with anything.

On how this enables reusable page-level templates, such as grid layouts:

[These] parts of the layout are only concerned with the alignment and dimensions of boxes. They have no effect whatsoever on their children other than giving them a certain amount of space to fill.

I am not a fan of alphabetical CSS, but Eric does a really solid job of arguing why, right now, it may be the best option. The short version is that CSS remains so woefully underutilised and misunderstood across the industry that anything other than alphabetical – a system that requires no domain-specific knowledge – is bound to fail. It's a depressing but well-reasoned argument.

Alphabetical is easy enough to pick up and have an organization repeat as a convention without having to invest too much time on upskilling an entire team on CSS theory.

On why pushing more "correct" solutions can be damaging to the client/team you're trying to help:

I think this is an important thing a lot of people get wrong. You want to set up something sustainable, but also not pour your own energy into making the right thing in the wrong way just to satisfy your own personal desires.

I just really love this definition of CSS:

The reality is that [CSS] is the programming language used to give ideas shape.

The Avian Vector Encyclopedia (or AVE) is a beautiful and fascinating project at the juncture of graphic design, art, and natural history. Scott is attempting to illustrate every species of living bird in a specific "flat", vector-based style. The results are beautiful and fascinating in equal measure.

Apparently, the type design world has recently thrown out its formal classification system and has yet to decide on a replacement. ILT (as ever) does a great job of summarising the current situation, the historical context, and the possible paths forward.

In particular, I found the highlighting of colonial creep within type classification fascinating, in terms of how fonts are often regarded as Latin or simply non-Latin, which is, well, yeesh 😬:

Imagine referring to billions of people as non-White or non-Caucasian while claiming impartiality. And although Latin is globally the majority script, let’s not forget how it got there.

Eric has written an often brilliantly funny canned history of the way CSS worked (or, more specifically, didn't) in the early days of the Web. It's worth a read just to see how good we have it today, a sentiment they sum up in such excellent fashion that I had to save it:

I know it’s still fashionable to complain about how CSS is all janky and weird and unapproachable, but child, the wrinkles of today are a sunny park stroll compared to the jagged icebound cliff we faced at the dawn of CSS.

There's a lot of interesting thoughts packed into this overview of UX Fest 2021, but the bits that really hit home were Jeremy's musings on A/B testing and dark patterns, particularly how one can feed into the other.

Using A/B tests alone is like using a loaded weapon without supervision. They only tell you what people do. And again, the solution is to make sure you’re also doing qualitative research—that’s how you find out why people are doing what they do.

Now, I suspect that if you were to A/B test a deceptive dark pattern, the test would validate its use (at least in the short term).

An interesting diagram of beer tasting notes. As someone who has been tracking beer flavours for a few years, I'd like to compare my own word grid at some point; plus, this gives me some ideas for that eventual microsite 😅

The original version was apparently from the book Craft Beer World by Mark Dredge.

100 separate typographic designs, all using free Google fonts, with some absolutely stunning results. What Do-Hee has put together is one of the best showcases for Google's font library, as well as an excellent source of inspiration. Top stuff 👏

Building a tooltip? A carousel? A password input? I can strongly recommend checking if the Component Gallery has a page on whatever UI pattern you're working on.

Each entry collates examples from design systems and pattern libraries all over the web, so you can quickly compare how everyone from Google and Salesforce to Brighton & Hove City Council have solved your problem.

It's been invaluable for the design system project I've been working on, as much for uncovering best practices as simply dissecting the sometimes opaque terminology that has evolved around certain UI patterns.

A great resource for finding accessible patterns for common UI requirements, as well as including stacks of accessibility best practices 🔥♿

A great rundown of how to build a site using Preact and Eleventy that gives you the best of SPA-lite hydration and the speed/resilience of SSGs, all with the power of progressive enhancement.

Markus uses some very clever techniques, including "lazy" hydration (only run hydration when components are within/just outside the viewport) and a
component explicitly designed to bring hydration to 11ty/Preact in the first place.

Also, this perfectly sums up why I prefer working with tools like NextJS or Gatsby (or 11ty):

Component-based workflows make frontend development fun again, and it is a lot easier to do with modern frontend frameworks than with using templating languages like Nunjucks or Handlebars.