Some very resonant musings from Jeremy on why he blogs:

But I don’t think about other people when I’m adding something to my website. My audience is myself.

I know there’s lots of advice out there about considering your audience when you write, but when it comes to my personal site, I’d find that crippling. It would be one more admonishment from the inner critic whispering “no one’s interested in that”, “you have nothing new to add to this topic”, and “you’re not quailified to write about this.” If I’m writing for myself, then it’s easier to have fewer inhibitions.

If someone else gets some value from a quick blog post that I dash off here, that’s always a pleasant surprise. It’s a bonus. But it’s not my reason for writing. My website is primarily a tool and a library for myself. It just happens to also be public.

A powerful and insightful piece by Michelle on the direct environmental impact the tech sector has, the way in which tech workers can demand further accountability and action, and the reality that green energy/land use aren't the only relevant factors. For the web to be truly "green", in should also help elevate social goals and embrace a holistic approach to climate action.

In the tech sector, when people talk about greening the web, they usually talk about energy. But really we should be talking about power

We need to go beyond tech solutionism and towards intersectional climate justice work. We need to go beyond individual action. We need to shift the power of systemic inequalities, hold major polluters to account, and dismantle the forces—financial, political and cultural—that hold us back from a greener internet and a more sustainable society.

Our work will not be done even if all of the internet runs on green energy—we need the internet to work within planetary boundaries and to uphold the human rights of every person.

On the commitments of firms like Amazon and Google to become more environmentally conscious and reach net-zero (kinda amazing):

And then to meet these targets, Big Tech became the biggest corporate buyers of green energy in the world.

Where has this article been my whole life! Andy's posts are often brilliant, but this an absolute gold mine of information, from ideal character lengths to clever type-setting tricks. And I thought I knew at least a little bit about CSS 😂

On using the :not pseudo-class to pre-emptively use the cascade to stop future conflicts on broad rules e.g. a:not([class]) { ... } :

We qualify elements with the :not pseudo class because if you have a link that’s supposed to look like a button that has a .button class on it, you don’t want global link styling to get in the way of the styling that .button generates, so this approach helps that.

👆 This is one of those absolute AHA! moments. I generally don't find myself clashing with specificity in CSS, but I feel like this pattern might have prevented/fixed the few times it does happen. So long as there isn't a blank class, I guess, but it could be extended to a:not([class]), a[class=""] { ... }.

Andy also recommends setting classless anchor elements to use the currentColor keyword, thereby inheriting the styles of their containing text 🤯 e.g.

a:not([class]) {
  color: currentColor;
}

On providing high contrast text selection:

Lastly, selection styles! I like to add a high contrast selection style, personally. It’s a handy inclusion strategy because folks might find your colours hard to read, so giving them the inverse when they select it’s helpful.

And finally, just a really interesting usage of the em-dash:

globally, too—especially if your blog is just articles, but to keep things future-friendly, we’re

I've never seen an em-dash used like this, as a break and then immediate return to flow. It may be a typo, but it reads perfectly well. After my double-take to see if I'd missed a line, I re-read it and it just worked. If the pattern were more common, I don't think I'd question it. Not sure of the grammatical side of things, but I like it a lot.

There's a lot I like about the IndieWeb community, but one of the best elements is a constant determination to strive to be better. Their recent adoption of an official "Life Happens" policy is a great example. It's a commitment to recognise that, well, life happens and that being part of an online community, or volunteering time/effort, is never a requirement. That slipping out for a bit is not just okay, but encouraged, whatever the reason. And providing a framework for supporting individuals in the community to whom life is happening.

The idea came from Tantek, and he sums it up nicely on his recent blog post:

That yes, if and when “life happens” to you that:

• we want you to take care of what you need to take care of
• you are encouraged to prioritize those things most important to you, and that the community will not judge or shame you in any way
• you should not feel guilty about being absent, or abruptly having to stop participating
• it is ok to ask for help in the community with any of your community projects or areas of participation, no matter what size or importance
• the community will be here for you when you’re able to and want to return

I can see this article becoming an oft-cited "turning point" in frontend development, like Ethan Marcotte's A List Apart post on responsive design. It's certainly a beautifully crafted argument for why your engineering team needs some Design Engineers, yesterday.

Some useful quotes on the why/what of design engineers:

How do we take all of the good ideas that have preceded our involvement in the project, tie them all together elegantly, and deliver them to the user appropriately.

As web developers in a larger build chain, I think our goal is to ‘translate’ the design in the best way possible.

But the primary focus is on doing anything they [design engineers] can to help translate the design for the engineering team.

CSS is the primary language of the design engineer.

I find it fascinating that there are elements to Trys' explanation of a Design Engineer that almost feel more like frontend DevOps (Design Ops? probably taken 😂) or system architecture. I think that's probably a little true; it's certainly an interesting thought to consider.

A design engineer must balance the user experience with the developer experience, both empowering the team to write great code in whatever way is right to them, whilst ensuring that doesn’t detrimentally harm the user experience.

On "back-of-the-front" developers:

I’m generalising, but developers in these fields tend to be ‘systems thinkers’ and approach things with a programming > design mindset—that’s just how their brains tend to work in my experience. Their skills are in writing elegant, robust and scalable code to ensure our products don’t fall over when things go awry. Their skills are in breaking down the whole product into sensible chunks, storing data efficiently, and making it easy to query. Their skills are in preventing data being leaked, stopping users from storing corrupt data, and ceasing hackers in their stride.

Their skills (again, generalising), are not in realising the nuance of a design. And that’s great!

And finally:

...but as we know from the design & engineering ‘owl grievances’...

This is just a wonderful sentence that I'm incredibly glad exists 👏🦉

Interesting thoughts on the term "Design Engineer", alongside some excellent historical context around Clearleft and carving out a niche doing "front-of-the-frontend" work.

In my experience, the term “full stack developer” is often self-applied by back-of-the-front-end developers who perhaps underestimate the complexity of front-of-the-front development.

That’s why I was so excited by the term “design engineer,” which I think I first heard from Natalya Shelburne. There’s even a book about it and the job description sounds very much like the front-of-the-front-end work but with a heavy emphasis on the collaboration and translation between design and implementation.

Personally, I’m not a fan of using the term “engineer” to refer to anyone who isn’t actually a qualified engineer...

A sobering look into the history of the UX industry. I think the outlined three "phases of UX" seem pretty on point from my own experience: from idealistic, trusted advisor; to oft-ignored and frequently devalued; to the antithesis of what it set out to be. To mimic the article, it's not that good UX teams and practitioners no longer exist (they definitely do), but that big companies are now more likely to listen to how user psychology can drive short-term profits over long-term satisfaction.

Suddenly the "get rich quick" mentality that had caused the 2008 crash was being adopted by senior leadership at Big Tech firms. Now it was data and algorithms, not UX, that mattered most.

"We're lying to our users," one anguished UX designer told me, explaining that leadership regularly ordered the UX team to create designs that were intentionally misleading. Apparently it helped boost profits.

Increasingly, I think UX doesn't live up to its original meaning of "user experience." Instead, much of the discpline today, as it's practiced in Big Tech firms, is better described by a new name: UX is now "user exploitation."

The mention of how Amazon has become a company famed for its dedication to user experience into one which uses six pages of dark patterns in order to cancel a subscription is, frankly, disheartening.

We're headed into a dangerous time, when our society is run on digital platforms, and UX isn't leading the way to ensure that those tools are usable.

A simple and informative example of how the new CSS clamp property can be used to create fluid layouts (in this case, specifically a fluid type system).

The key is in three CSS variables:

1. --fluid-type-min for the lower bound;
2. --fluid-type-target as the "ideal, fluid setting", using calc() to sidestep accessibility issues when zooming;
3. --fluid-type-max for the upper bound.

With that applied, you can target specific HTML elements and provide meaningful values using the rem unit, e.g:

For the <h1>, we increase the --fluid-type-target to a larger, 5vw. By increasing the viewport unit, we speed up the rate of growth, which will help to maintain its extra large size. To reduce the rate of growth and have less difference between your minimum and maximum sizes: reduce the size of --fluid-type-target.

Here's a snippet of Andy's code:

h1,
h2,
h3,
p {
  font-size: clamp(
    var(--fluid-type-min, 1rem),
    calc(1rem + var(--fluid-type-target, 3vw)),
    var(--fluid-type-max, 1.3rem)
  );
}

For all three custom properties, we are setting the default value as the second parameter.

It’s really important to test that your text gets large enough when you zoom in and small enough when you zoom out—it should be very obviously larger or smaller.

A font designed to make text as legible as possible. Particularly impressive attention to making sure letterforms are still distinctive even when extremely blurred. Best of all: it's completely free to use.

I feel like Max is about two years ahead of me on everything 😁 Here I am thinking about getting Twitter syndication working on Netlify, and he wrote a perfect tutorial back in 2019. Definitely need to give this a spin! The basic concept is to provide a JSON feed of new "tweets" (or thoughts, or notes, or whatever you want to call them) and then use a Netlify "Function" to parse that feed, connect to the Twitter API, and fire off your tweets on build. Very cool!

To trigger our custom function everytime a new version of the site was successfully deployed, we just need to name it deploy-succeeded.js. Netlify will then automatically fire it after each new build, while also making sure it’s not executable from the outside.

British Bugs does what it says on the tin, providing a treasure trove of photos and information about all manner of bugs found in the UK.

The Bird Guides forum was an invaluable resource whilst we were failing to see the bearded vulture that made the UK it's home last summer, and I've continued to check in from time-to-time since. In particular, their live sightings map is a brilliant tool for checking whether any rarities have been spotted nearby, or just discovering wild areas with good bird populations.