People joke about Safari being the new IE6 a lot, but I've never seen as succinct and well-reasoned a take on just how true this is becoming than what Tim has written. Their argument breaks down into multiple sections, but clearly demonstrates that Safari (and the WebKit team) are fundamentally failing the web, through a combination of (what appears to be) stubbornness, protecting existing business interests, and poor development practices (to be clear, Tim only mentions number three on that list, but the others seem fairly likely).

For example, I knew (and have personally been frustrated by) the fact that Safari seems to always be the last to ship new web features, but seeing a full list of fairly basic functionality that is still missing was still informative (especially with some of it having shipped a decade ago in Chromium or Firefox). Ditto seeing a detailed list of web APIs and elements that have shipped in WebKit, but did so years after widespread adoption elsewhere.

One aspect of Tim's article I found interesting was how WebKit's monopoly on iOS was framed as a good thing, effectively forcing devs to actually care about the browser engine. I'm all for diversity in browsers (and browser engines), but I think this is a stretch: Apple are just abusing their competitive edge here and I thoroughly hope that the EU (and many other courts) slap them firmly back into place soon. Still, they have a point that when this does happen, WebKit's own behaviour may end up being its downfall:

There is no point in winning on principles if there are no users left.

On why Safari should be leading innovation, not playing catch up (and how their ridiculous release cycle is hurting their competitiveness):

A far better way to improve APIs would be to ship such features early in Safari, behind flags & origin trials, and gather feedback from as wide an audience of developers and browser implementors as possible before they become stable, so that feedback can help every browser include better APIs.

On why a 6 month minimum release cycle hurts the web and forces people off Safari:

This makes the whole problem so much worse, because even if bugs were quickly recognized and fixed, they're going to be around for at least 6 months, and likely well beyond too

On the localStorage bug that I hadn't realised was still an issue 🤦‍♂️:

As an example: the localStorage bug above seriously breaks a core web API, and was very quickly fixed (within 24 hours! Superb) but today nearly 3 months later that working fix still hasn't been released to users

On why taking a hardline stance against the new web APIs that Chrome is shipping will ultimately leave Safari (and Firefox, they're just as at fault here) in the dust:

That's not to say that every website will use these shiny new APIs - they're mostly isolated to web application use cases. In some ways that's worse though: your average user isn't going to install a new browser to read a news article, but they might if it offers them reliable notifications from their chat app (background push), makes it easier to work with a webapp they use at work every day (native filesystem), or if it's required to set up a new bluetooth gadget (web bluetooth). Once they switch for one thing, it significantly increases the change they switch for everything.

The percentage of users who'll never use Chrome out of principle is vanishingly small compared to the group of users who will switch to the best tool for the job.

On why WebKit, Mozilla, and others should be actively working with the Chromium team to ensure these new Web APIs aren't just what Google wants, but will actually consider aspects like privacy and mobile performance, instead of just refusing to join the discussion (and thereby letting Google win):

Safari and others can't simply ignore serious proposals for popular features that Chrome wants to implement. They need to engage and offer alternatives, or the problem will only get worse.

"Dark pattern" is one of those phrases that could be problematic,  or could just be evocative (there are some obvious race-related issues with equating dark/darker with bad/worse, but there's also a legitimate cultural attachment to light/dark as in day/night). As Jeremy puts it:

The phrase “dark pattern” is …problematic. We really don’t need to be associating darkness with negativity any more than we already do in our language and culture.

But, it's also one of those terms which don't make a huge amount of sense if you step back and look at it with fresh eyes. For both reasons, I like Jeremy's suggestion of moving towards "deceptive pattern", which is more on-the-nose as to what it's trying to convey, and avoids any lingering sense of problematic language. Good, I think I'll adopt it 👍

(I wish there was some way to pseudonym tags in Craft...)

I have mixed feelings about the inclusion of Safari's new editable browser chrome, but love it or hate it, more and more iOS and OSX users will end up seeing it. Andy hasn't touched on any of the controversies around the tag, but their article does a solid job of outlining what's changed, why, and how to make the most of it.

For example, I hadn't realised that theme-color was already used by PWAs installed from Chrome; nor did I know that Safari had enabled media queries on the tag, meaning that you can do things like this (code is Andy's example):

<!-- Dark mode theme: blue -->
<meta name="theme-color" media="(prefers-color-scheme: dark)" content="#0e4359">

<!-- Light mode theme or no preference: red -->
<meta name="theme-color" content="#a62339"> 

Also, good to have confirmed that this will be a user preference:

Safari users can turn off coloured toolbars with “Preferences > Advanced > Never Use Background color in toolbar” but I suspect most people will leave the default turned on.

A fully repairable laptop design, as thin as a standard ultrabook and with high-end Intel parts, up to 64GB RAM, and up to 1TB of hard drive space. I/O is hot-swappable, so you can configure the four ports to what you most need and modify in the future if those needs change (or on the fly, if they change a lot).

Right now, the downsides I see are a non-touch monitor (though colour reproduction looks great) and the fact it's only available in the US and Canada as pre-orders. Hopefully they thrive, though, because the machine looks great, the ethos is extremely welcome, and the innovation in aspects like the I/O modules and the BIOS battery switch (so cool!) means this feels like a genuine competitor out the gates, rather than an enthusiast/hacker hope'n'see.

A community-led, open-source project attempting to define problematic language (in English) and suggest better replacement terms. Unfortunately, not all listed phrases or words have detailed breakdowns, but those that have do a great job of outlining the historical or cultural contexts that gave rise to the language in the first place, and why the modern usage is less than ideal (or not; some terms are deliberately listed for being positive), including sources or further reading.

Terms are also marked up with at-a-glance categorisation, such as cultural appropriation, racist language, or slur. Even if I don't 100% agree with some of the arguments presented (it skews American and therefore can lose or ignore some localised context), it's a brilliant resource for fact-checking, finding more inclusive language options, or just increasing awareness of the nuances involved.

"Official" documentation on how to pair React and TypeScript. Very useful in conjunction with the GitHub guide.

I find navigating the type options in React (and decoding what they actually do/mean) really difficult. It's layers of abstractions on top of layers of more abstractions 😄 Luckily, this guide provides a lot of useful context and some well-reasoned defaults (though I don't agree with them all).

An interesting overview of the history of note-taking, specifically as it relates to the concept of a commonplace book and the myriad related forms, including the most recent idea of a digital garden.

It also serves as a reminder of all the things I want to achieve in this space, but have yet to find the time...

On the general lack of understanding behind note-taking:

People are “taught” (maybe told is the better verb) to take notes in school, but they’re never told why, what to do with them, or how to leverage them for maximum efficiency.

On the historical impact and use of commonplace books (I really like this sentiment):

... [commonplace books are] somewhat like a portable Google search engine for their day, but honed to [the author's] particular interests.

On florilegia, a term I've not come across before:

Florilegia are a subcategory of commonplace book starting around 900 CE but flourishing in the 12th and 13th centuries and primarily kept by theologians and preachers.

On wikis, and the discovery that I share my birthday with both the ending of the Third Age of Middle-Earth and their creation – sweet 😄:

Inspired, in part, by Apple’s HyperCard, Ward Cunningham created the first public wiki on his website on March 25, 1995

(Mildly related, but this does strike me as a good idea for a microsite, perhaps bday.theadhocracy.co.uk 😁)

On the (less than ideal) history of the term "second brain" (and why other terms should probably be preferred):

Second brain is a marketing term which stands in for the idea of the original commonplace book.

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.