A wonderfully illustrated and deeply informative article on responsive images on the web. 👏 Also, Eric's worries about "none of this being implemented in any browser yet" are no longer relevant – hooray for living in the future!

The gist is that media queries are terrible for picking images to display. Part of the reason is that image width on the page is only determined after CSS, so you have to do a fair bit of calculating to pseudo-predict what you need in time for a media query to work. And even if you work out all those lengthy calculations, the resultant <picture> element won't be flexible or easily extensible. Any minor change = total recalculation. Headache!

The solution is to combine srcset with sizes. The root of the problem above is that the developer and the browser implicitly know exactly the opposite bits of the equation to one another. The browser knows the viewport width; the developer doesn't. The developer knows the available image widths, the browser doesn't. Media queries seek to solve this by feeding the browser rules to apply to viewport widths, which is messy. Instead, srcset supplies the browser with the stuff the developer knows and lets it to do the rest. Eric sums this up really neatly with this table (lifted verbatim):

Here's the final example code (which I believe is still pretty accurate):

<img src="small.jpg"
     srcset="large.jpg 1024w,
             medium.jpg 640w,
             small.jpg 320w"
     sizes="(min-width: 36em) 33.3vw,
            100vw"
     alt="A rad wolf" 
/>

Also:

And again let me emphasize that while you can attach 1x/2x resolution descriptors to sources in srcset instead of w descriptors, 1x/2x & w do not mix. Don’t use both in the same srcset. Really.

To explain that sizes syntax:

sizes="[media query] [length], [media query] [length] <em>... etc</em>"

So yes, still technically using media queries, however now to tell the browser about the breakpoints it should expect rather than trying to work around them once they've happened. And yes, you can use calc and any unit combinations in there too.

A great overview of techniques to help improve text legibility, working with the browser rather than against it to be as inclusive as possible:

• Use rem and em units for margins and white-space around text so that it "preserves the vertical rhythm" if a user changes text size;
• The new (and not yet fully supported) font-size-adjust property is excellent for both preserving optical design and preventing webfont loading "flashes" by ensuring fallback fonts use the same optical height (this calculator can be used to quickly determine the ideal ratio for a system font):

@supports (font-size-adjust: 1;) {
    article {
        font-size-adjust: 0.5;
    }
}

• Set an optimal line-height by using x-height (height of the x character); the browser default standard is 1.2 but that's optimised for Times New Roman (TIL 🤯). Instead a combination of calc and the ex unit can be beneficial:

p {
    line-height: calc(1ex / 0.32);
}

In the right reading contexts, this rule sets an optimal line height for both serif and sans-serif fonts, even when typographical tools are not available or when a user has set a font that overwrites the one chosen by the designer.

• The calc value can then be combined with a scale to determine type hierarchy e.g. h1 could be calc(1ex / 0.42) and so on;
• Allowing users to dynamically control properties like letter-spacing, word-spacing, font-size etc. with sliders or other input options can be beneficial, particularly for people with difficulties reading text (dyslexia, vision impairment etc.);
• Optimal reading flow is achieved by ensuring travel for the eye between the end and start of lines isn't too extreme. Roughly 60-70 characters tends to be the sweet spot, so setting a width using the ch unit is ideal:

p {
    width: 60ch;
    max-width: 100%;
}

I think it's cool to see GitHub embracing calls to move away from "master branch" terminology and doing so in a way which provides further flexibility and power to its users. That's a win-win no matter how you feel about the surrounding debate. As of October 1st, all new depositories will default to use main unless otherwise specified, but you can define your own default however you please. For me, that means I've switched to use trunk moving forward by changing the settings in my repo settings page. There are options for enterprise and organisation owners too 👍

I didn't know that the <a> element had a download attribute, nor that it could rename the file on download for you e.g:

<a href="/files/ugly-file-name.xyz" download="nice-file-name.xyz">download</a>

On top of which, I didn't know that redirects using Netlify's _redirects file (which I do know about 😀) would allow for same-domain downloads (which the download attribute requires):

/download/*  https://clearleft-audio.s3.amazonaws.com/podcast/:splat  200

Basically, this whole article is a TIL.

SVG OMG is a brilliant (and free) web tool for sanitising, standardising, and minifying SVG assets. It's brilliant and has saved me a few times already.

There are two browser engines in the world. Dave considers what might be lost if that were to become one. He argues that browser diversity forces the standards process to be slow – and therefore deliberate and considered – and non-corporate. A single browser means whoever controls it has an outsized influence on how the web works.

There’s a lot of value in slow thinking. You use the non-lizard side of your brain. You make more deliberate decisions. You prioritize design over instant gratification. You can “check” your gut instincts and validate your hypothesis before incurring mountains of technical debt.

To make good platform features requires consensus, not competition, and the web’s potential is born out of cooperation, not a single corporation.

If the Web is governed by a single corporation, it will start looking like that corporation’s vision of the Web, ultimately limiting its own potential. Trading short term gain on new shiny features for long term

If we do see a major reduction in browser diversity, I think we lose the intentional slowness and the cooperation mechanisms we have in place. Who knows what will happen, but my hope is that just like iron can sharpen iron, maybe chromium can sharpen chromium.

Another great overview of how to use the `react-hooks` extension for the Testing Library suite, with some more complex examples than many other tutorials.

I've been doing a fair amount of testing React hooks recently. Part of that has been learning the `react-hooks` extension for the Testing Library suite, which took a while to wrap my head around. Kent's post helped straighten out a few misconceptions.

An excellent website for identifying species of butterfly and moth found in the UK, with great photos of all species 🦋

A combination of build commands and Netlify tools equals a very creative native commenting system for Jamstack sites (hosted on Netlify, of course). Definitely need to drill a bit deeper into how this works, but looks excellent.

So that previously mentioned discussion around the problems of having a "single identity online" led me to this brilliant dissection of the impact social media had on social identity. From the initial barrier-breaking (aka "context collapse") that occurred when you suddenly had your colleagues, friends, family, school mates etc. all on one platform, all able to see you interacting with each other in real-time (and could go back and browse those interactions in the future 😬), to the subsequent rebellion back to ephemeral platforms like Snapchat and private conversations over WhatsApp etc.

On a social network, the theory went, all those different contexts collapsed into a single context. Whenever you posted a message or a photograph or a video, it could be seen by your friends, your parents, your coworkers, your bosses, and your teachers, not to mention the amorphous mass known as the general public.

The problem is not a lack of context. It is context collapse: an infinite number of contexts collapsing upon one another into that single moment of recording.

Young people led the way, moving much of their online conversation from the public platform of Facebook, where parents and teachers lurked, to the more intimate platform of Snapchat, where they could restrict their audience and where messages disappeared quickly.

Nicholas than moves on to pondering about whether the next stage will be content collapse, a state where the internet (and particularly social media) begins obfuscating the contexts and structures of content (even further), with negative impacts. Most obviously, that content delivered as a stream loses weighting and suddenly breaking international news is just as important as some stranger's opinion on onion slicing.

Content collapse, as I define it, is the tendency of social media to blur traditional distinctions among once distinct types of information — distinctions of form, register, sense, and importance.

It wasn’t just that the headlines, free-floating, decontextualized motes of journalism ginned up to trigger reflexive mouse clicks, had displaced the stories. It was that the whole organizing structure of the newspaper, its epistemological architecture, had been junked. The news section (with its local, national, and international
subsections), the sports section, the arts section, the living section, the opinion pages: they’d all been fed through a shredder, then thrown into a wind tunnel. What appeared on the screen was a jumble, high mixed with low, silly with smart, tragic with trivial. The cacophony of the RSS feed, it’s now clear, heralded a sea change in the distribution and consumption of information. The new order would be disorder.

Many of the qualities of social media that make people uneasy stem from content collapse. First, by leveling everything, social media also trivializes everything — freed of barriers, information, like water, pools at the lowest possible level

Finally, content collapse consolidates power over information, and conversation, into the hands of the small number of companies that own the platforms and write the algorithms. The much maligned gatekeepers of the past could exert editorial control only over a particular type of content that flowed through a particular medium — a magazine, a radio station, a TV network. Our new gatekeepers control information of all kinds. When content collapses, there’s only one gate.

Well damn... 😶

Ana has put together a brilliant overview of the why, what, and how of the IndieWeb. I imagine I'll return many times to look up simplified explanations, but a couple of quotes particularly jumped out:

I’ve lost count of how many “Hello worlds” I’ve created and binned in my lifetime when I had a real “product” to build: me.

[My personal website] is where I can experiment, write, build, try, and learn without censorship or limitations.

Although another line sparked a little discussion on the IndieWeb chat about the viability of a singular identity:

I didn’t realize until this point how much it made sense to have a “one true version” of yourself online

I love the concept, but I (like many others) struggle with this in practice. For example, I want a professional portfolio/CV... I probably don't want that to be under the umbrella of "theAdhocracy", but I also don't want to change my online self. It's an interesting tightrope to walk.