A really succinct quote from Seth on glass-is-unoptimised thinking (as opposed to cyber-optimism or cyber-pessimism, which I agree are both untenable outlooks):

Technological change doesn’t always make things better. It often comes with significant side effects and costs. And yet, thanks [to] the vigilance and hard work of some folks, technology also has a long track record of making us safer, healthier and even happier.

The cyber-realist sees both and is focused on being careful about systemic change and lock-in, especially for cultural and organizational changes that are hard to walk away from.

I know very little about Edward Tufte, but they clearly have quite the following in the design/typography space. Tufte CSS is a project aiming to emulate various tenets that Tufte used to design their books and articles, but with a focus on how they might work on the web. The result is a very pleasing library of CSS classes and defaults that looks pretty decent, in a slightly old-fashioned, Victorian way (which I'm obviously all for).

On a more personal level, I find the use of "sidenotes" (their term), figures, epitaphs, and simple layout rules most interesting; there are definitely a few ideas here that I find inspirational.

[PS thanks to Jeremy on the IndieWeb chat for linking me to this project, and Edward Tufte in general, following a discussion on whitespace and typography.]

On sidenotes, which (on smaller screens) collapse and become togglable text that expands between paragraphs; neat UI/UX:

Sidenotes are like footnotes, except they don’t force the reader to jump their eye to the bottom of the page, but instead display off to the side in the margin.

Sidenotes are a great example of the web not being like print. On sufficiently large viewports, Tufte CSS uses the margin for sidenotes, margin notes, and small figures. On smaller viewports, elements that would go in the margin are hidden until the user toggles them into view.

On the project (I just liked the sentiment 😂):

Tufte CSS is merely a sketch of one way to implement this particular set of ideas.

If you're new to (or unsure of) CSS transforms at all, I can't think of a better explanatory introduction than this.

Plus, once again, Josh has managed to teach me some new tips and tricks about a topic I thought I had pretty well covered. In this case, the revelation of the (much cleaner, imo) turn unit for rotational amount:

The turn unit represents how many turns the element should make. 1 turn is equal to 360 degrees.

It's obscure, but well-supported; the turn unit goes all the way back to IE 9!

Cathy has produced an exceptional overview of modern responsive/intrinsic design best practices. From fluid units, to content-led design, to subgrid, pretty much every current or on-the-horizon feature of CSS/HTML is covered.

That includes some very interesting thoughts on the potential limitations of container queries, which was nice to see. Plus, what is hands-down the best explanation of how the new min(), max(), and clamp() functions actually work (maybe this time it'll stick 😄).

On the fact that design has fundamentally changed (oh how this resonates right now):

What I learned the hard way was that you can’t just add responsiveness at the end of a project. To create fluid layouts, you need to plan throughout the design phase.

On the benefits of subgrid in CSS (their example showing cross-component adaptation is simple yet very clear):

CSS Grid allows us to separate layout and content, thereby enabling flexible designs. Meanwhile, Subgrid allows us to create designs that can adapt in order to suit morphing content.

On the core of responsive/intrinsic/inclusive design today:

Good design for the unexpected should allow for change, provide choice, and give control to those we serve: our users themselves.

CEDARS+ is a new font categorisation system by the folks over at ilovetypography. Rather than trying to define fonts by fairly abstract categories like neogothic or Didone, ILT have come up with a system that breaks a font down into specific traits:

• Contrast
• Energy
• Details
• Axis
• Rhythm
• Structure
• + (basically anything else; allowing them to more easily extend relevant filters based on alphabet or character sets, thereby supporting a wider range of languages and writing systems)

It's a neat idea explained more fully in the introductory blog post, but I honestly didn't think a huge amount about it until I saw it in action on their font search engine. Being able to filter fonts by the physical characteristics, such as slant or line thickness, just feels a whole lot more intuitive to me, particularly as someone who couldn't name more than a half dozen "traditional" font categories. Hopefully, more places adopt the system in the future.

Jeremy covers the recent Chrome alert() controversy very clearly, but I'm a particular fan of their points about the underlying assumptions that have made these kinds of breaking changes something that can be considered.

The concept that the web is the purview of "web developers"; that programmers alone build websites – it's a dangerous, naive, and deeply problematic sentiment. As Jeremy puts it:

You can choose to make [the web] really complicated. Convince yourself that “the modern web” is inherently complex and convoluted. But then look at what makes it complex and convoluted: toolchains, build tools, pipelines, frameworks, libraries, and abstractions. Please try to remember that none of those things are required to make a website.

This is for everyone. Not just for everyone to consume, but for everyone to make.

On the removal of anything from web technologies:

I know that removing dangerous old features is inevitable, but it should also be exceptional. It should not be taken lightly, and it should certainly not be expected to be an everyday part of web development.

As someone who has been involved in a greenfield design system build for the last six months, I empathise a lot with Amy's well-worded explanation of why content design should never be overlooked.

I'd even go a stretch further, and just say that design systems can only thrive when all front-end disciplines are brought together early, and actively lean on each others speciality knowledge. Design systems can be used to scale best practices, or bad practices, equally, so best to catch things early and bake good ideas in at a foundational level.

On why content matters, and how design systems can scale little issues rapidly into big problems:

Leaving content out of the equation damages the user experience, and when we do this at the level of design systems, we’re allowing that experience to scale.

On the long term repercussions of not involving specialists early in ideation:

It means content designers have to spend time identifying and correcting widespread issues they probably would have caught at the root, had they been involved in the design of the system component or pattern.

On why consistency in language across a site is a core requirement:

Perhaps I’m biased, but I’d wager that using different words to describe the same actions, processes and information is the most damaging and confusing kind of inconsistency of all.

Some interesting facts taken from an article by Louise Crane in Ferment 68:

• Pub and inn names/signs became a thing in Britain in the 12^th Century, after a Royal decree from King Richard II that all such places would have a locally distinctive name and bear a painted sign clearly communicating that name for those who could not read. This was partly because a lot of Crown-employed Ale Tasters (a job that would check beer was up to standard, measures were fair etc.) were illiterate.
• As a result, lots of pubs became "The White Hart", which was the official symbol of Richard II (hence the common crown around the deer's neck).
• Similarly, the White Lion is the symbol of Edward IV; the White Boar is Richard III; and the common Red Lion is James I of unification fame. There are so many Red Lions because James I actually forced all "important buildings" to display his heraldic animal, and pubs were often the most important place in a community, so many just changed their names for simplicity.
• The shortest pub name in the UK is the Q Inn, in Stalybridge, Manchester.
• Pubs named along the lines of The Swan with Two Necks or The Two Necked Swan these days often have signs with, well, multi-headed Galliformes, but the name actually makes more sense. During the reign of Elizabeth I, the queen would occasionally gift swans to lucky patrons. These royal birds would have their webbed feet "notched" with two small incisions, or "nicks", to show their heritage. Over time, "two nicks" became "two necks", and the pub name was born. Definitely not common, but if seen it means that royalty once stopped there (or favoured the pub in some way).
  

An interesting look at using consistent line-heights to force a vertical rhythm to a page. Specifically, it looks at setting a base line-height (in this case 18px) and ensuring all text uses it. That means smaller fonts have larger gaps between lines, larger fonts have smaller. I'm not 100% sure I like the outcome on the example page given, but there's definitely some interesting use-cases and applications.

just as regular use of time provides rhythm in music, so regular use of space provides rhythm in typography, and without rhythm the listener, or the reader, becomes disorientated and lost.

I have long struggled with taking compliments in certain situations. Basically, the better I know someone, the more I consider them a friend, the harder it is to get a compliment from them. That's weird, but I've always felt it was at least a little universal. The latest Oatmeal comic confirms my suspicions, and neatly explains/encapsulates most of the emotions and oddities that come with being complimented far better than I'd have ever been able to describe them 👏

Some interesting points:

• If compliments hit a "self-esteem nerve" (i.e. something you have deeply held, likely negative personal beliefs over, like weight or clothing or comedic ability) then your brain can struggle to accept them, for all the same reasons that providing facts to conspiracy theorists only entrenches their belief structure. Instead, it may just create a "useful" lie that allows both realities to coexist; "useful" because often it assumes the compliment is false and intended for some manipulative purpose. Sigh...
• Public compliments that are referencing recent events are largely okay, but the longer the lag time between event and compliment, the more it is unexpected, and the greater the cognitive load it can produce.
• Importantly, that transfers to the workplace, so whilst the whole "criticise privately, praise publicly" thing is useful, if the praise gap is too long it can leave the recipient burdened rather than benefitted. Worth considering 🤔

Monks Wood Wilderness was a regularly ploughed field 60 years ago. Then (for whatever reason) it wound up without clear ownership and became an environmental study well ahead of its time: a rewilding project decades before the term was first coined.

This isn't all that surprising; plenty of places have looked into how areas respond to varying levels of intervention, both human and faunal, plus it provided a good excuse for the local council to simply ignore any questions around land management. Still, it's an interesting and useful study that proves how fast rewilding can occur.

The field in question benefitted from being adjacent to existing mature woodland, but even so, it's now a fully functional late-stage oak wood, with populations of rare species including marsh tits and purple hairstreak butterfly. There are over 400 trees per hectare, many of which are oak, and strong populations of deer, songbirds, bats, and insects. All in just 60 years. Imagine what would happen if the government started rewilding thousands of similar pockets of land?

The original council note that kickstarted efforts:

It might be interesting to watch what happens to this area if man does not interfere. Will it become a wood again, how long will it take, which species will be in it?

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.