Stashing for personal reference, as my original BBC source appears to have vanished. A 2014 news story from Paihia, New Zealand, about a female bottlenose dolphin that adopted a stray common dolphin calf (given the nickname Pee-Wee). It made international news as an incredibly rare documented instance of cross-species adoption, but it hit my radar because we were there when the discovery was made (or, technically, just after). We were just days into our time in New Zealand and went out on a boat trip to see the famous Hole in the Rock with Fullers GreatSights, which included some dolphin spotting. The first pod we found were a group of half a dozen bottlenoses with a calf, which was cool, but our guide kept scanning back and forth over the calf until she confirmed that it was Pee-Wee. The same company had been the ones who had realised what had happened a couple of days earlier and it was on our trip that they felt the adoption was confirmed, with the calf still with her adopted mother after a few days. Pretty cool stuff and, yes, I do have a photo of Pee-Wee – or at least its dorsal fin!

The National Institute of Water and Atmospheric Research (NIWA) in New Zealand has a whole host of exceptional identification guides for the creatures that live in, on, and around their national coastlines. I've been going back over photos I took when we were living the Kiwi life in 2014 and have they've helped with a number of identifications, as well as just generally being an interesting resource to read through.

I can relate to Lea's frustrations (or, more specifically, those of her friend who doesn't often stray into JavaScript territory.

I still remember the first time I tried to use ReactJS. The hours spent battling a completely foreign command line, inconsistencies in results when using npm versus Yarn, the utterly unhelpful packages. Above all else, the fact that I was doing so on a Windows machine and kept running into a debugging wall where other devs would just write this off as the underlying reason, shrug, and walk away. It turned out that I was installing my yarn packages into the wrong folder, having accidentally set it up during initial install incorrectly (so no, nothing to do with Windows). Although I wouldn't even work that out for a few months, when I found the other folder whilst looking for something else. At the time, we literally wiped everything dev-related from my machine and started from a blank slate 🤦‍♂️

John gives up. Concludes never to touch Node, npm, or ES6 modules with a barge pole.

I had a similar thought...

A pretty exhaustive overview of the HTML and CSS options that we now have for responsive image layouts. Here are some key takeaways:

• Prioritise srcset for the best performance gains, <picture> for the greatest level of editorial control (think different images for dark mode, or completely different layouts on smaller/larger screens);
• Setting the lowest resolution image within a srcset to the src value is normally best;
• The RespImageLint tool is very useful for determining srcset sizes attributes;
• There's also the LazySizes library for lazy-loading images;
  
• Despite clever tooling, sizes remain tricky to get right and often benefit from templating abstractions (as does the whole responsive image malarkey in total);
• If you need to be able to zoom in on an image and serve a higher resolution image as it happens, srcset lets you achieve that by specifying widths wider than the viewport i.e. 300vw;
• Art direction using the <picture> element can be used to serve static images instead of GIFs for users who prefer reduced motion (there are any interesting niche use cases with links out to full resources);
• The <picture> element also provides a chance to use more performant image formats such as WebP, whilst providing a graceful fallback for older browsers;
  
• You can combine <picture> and srcset if needed, which may net some further performance savings;
• Netlify (and a bunch of other CDN services) offer automatic image resizing based on URL parameters;
• Don't forget the value of using object-fit and object-position to handle the bits in-between breakpoints as well;
• There's also a huge list of further reading and sources at the end of the article.
  

A bespoke stylesheet that automatically styles semantic HTML to look like Latex.

In some ways this outcome is the opposite of what you were intending. You wanted a Card UI where everything was simple and uniform, but what you end up with is a CSS gallery website filled with baby websites.

A great breakdown from Dave as to why the typical card UI pattern has some inherent issues. Some elements – like making cards all the same height and dealing with responsively collapsing card lists – are now irrelevant thanks to flexbox and CSS grid, but others are inherent to the format. Issues with block links are one potential headache, but you also present information in a slightly bizarre reading format and create a default UI hierarchy that demands a lot of borders. I feel like that last point subtly hits an issue I have with this site's design on the head. Interesting.

An interesting look at a "block links" at "card links": when you want large sections of HTML to be one big clickable link. It's a very common pattern and something I've done a lot, but it's also deeply problematic. It creates a double-standard UX where it is now a pattern that I expect and therefore get annoyed at when it doesn't work: see a blog post, for example, as a card and I expect to be able to click anywhere to read the article. But at the same time, when I'm scrolling down a page on my phone it's incredibly frustrating when a seemingly blank area suddenly redirects me to a new page.

It's also a terrible pattern from an accessibility perspective, because the normal implementation – wrapping the whole section in an <a> tag – screws up navigation by screen readers. It can also impact keyboard users too.

So, overall, a common pattern that is now practically an expected user interaction but which has deep flaws and should likely be stamped out. That paradox is an issue. Vikas has done a good job of outlining the current solutions to that problem alongside their respective pros/cons and comes to an interesting conclusion. He argues for semantically marked up HTML segments (good ✔) with linked headlines and "read more" text (though with better copy than "read more"; also good ✔) which is then progressively enhanced with JavaScript to listen to click events within the parent element (interesting). That allows the whole section to be clickable for JS users, whilst providing semantically relevant links as a fallback, and can be further improved using the window.getSelection() method so that users can still select or highlight text without inadvertently "clicking" the card itself (excellent ✔✔). Clever little trick 👍

const card = document.querySelector(".card")
const mainLink = document.querySelector('.main-link')


card.addEventListener("click", handleClick)


function handleClick(event) {
  const isTextSelected = window.getSelection().toString();
  if (!isTextSelected) {
    mainLink.click();
  }
}

I often end up feeling a little overwhelmed by the whole IndieWeb movement, but I found Chris has done a great job of breaking down a) what they're trying to achieve and b) why it can be useful at a personal level. There are times when I feel like I need to spend hours carefully reading over documentation and considering various implementation requirements to be a part of the IndieWeb. Chris reminds me that it's okay to pick and choose the pieces that make the most sense for me:

Everyone’s desires and needs will be different. Work on what you find most interesting and useful first...

Whilst sorting out some old hard drives I discovered some videos from the cancelled 2013 Harfest festival (only link I could find now). I was one of only about a dozen people who didn't live locally and had already travelled down by the time it was cancelled, so we had a small acoustic set with the one band in a similar situation that evening at the farm it was meant to take place at. Anyway, I was trying to work out who that band was and stumbled onto this playlist. Unfortunately, it looks like most of the bands in the lineup are lost to time, but maybe this might stick around. There's something in this about the impermanence of the web...

An overview of JS promises for all skill levels. Starts with an excellent analogy of thread-blocking as sneezing:

You don't want to write code that's sneezy.

You can effectively think of promises as stripped-down event listeners. They wait for a specific thing to happen, then they trigger a response, whilst recording either a success or failure state. That makes them particularly useful for asynchronous functionality:

This is extremely useful for async success/failure, because you're less interested in the exact time something became available, and more interested in reacting to the outcome.

As a result, promises can have four states: fulfilled (yay!), rejected (failure...), pending (waiting around for the trigger), or settled (no longer pending). There's also thenable but... what?!

Because of these states, you can use promises to build sequential logic chains using then() and catch(). Jake's got a whole bunch of great code examples which are worth checking over for exact syntax and useful shortcuts. Because promises are effectively set once, they also allow you to reuse initial results. For example, if you fetch an array of URLs from an API using a promise, you can then keep referring back to the output of that promise to loop through the array and fetch data from each URL, without consistently re-fetching the original info.

Also useful to know:

Promise rejections skip forward to the next then() with a rejection callback (or catch(), since it's equivalent).

One of the hardest concepts when working with async logic is that content order is always unknown. For example, if you're fetching a list of URLs and then want to loop through that list to return article information, you can't just use a for loop. Loops aren't "async-aware", so they would output the content in whatever arbitrary order the promise had resolved in. Your code wouldn't always return the same result when given the same input – not ideal! Again, Jake has a useful example of how to convert that type of logic into a promise chain.

Better yet, promises give us the ability to make use of multi-thread data fetching within the browser:

Promise.all takes an array of promises and creates a promise that fulfills when all of them successfully complete.

That can actually reduce your code length and significantly increase load times. Neat.

Jake also takes a look at how generators in JS can help write async code in a way that reads like synchronous code. Also neat.

Josh keeps publishing articles that are both interesting to read and specifically useful to problems that I'm currently working on, but this time his article became the inspiration to solve a problem I've been ignoring for ages. As a result, my site should now have a sitemap (hooray!) thanks to this excellent tutorial on gatsby-plugin-sitemap. It was incredibly easy to follow, so I figured I'd log it here in case I ever need to come back to it 👏👏

I also fully endorse this sentiment:

I really don't want to have to care about SEO. It's all very nebulous, and it attracts so many snake-oil salespeople. SEO websites are the worst. And yet, if you want people to see the stuff that you build, SEO remains super important.

I don't think I mind that much about the discovery side of SEO, but when getting a boost is this simple why not go for it? I may not be chasing views, but I also don't want to hinder them.

More for personal use than as a note. Our Canon Pixma printer (model number: MG5750) is pretty excellent, but over time the likelihood of it actually printing when asked has decreased. The number one culprit is an inability to pull in paper, no matter what we do. Today that reached a head when printing some pictures and left us functionally without a printer, so I did some Googling and found this troubleshooting guide by Canon. On the one hand, it's pretty hidden; on the other, it's great that it exists at all.

Turns out there's a maintenance mode which "cleans" the feed rollers. No idea what it actually does, but my guess is some form of percussive maintenance, hence the warnings not to do it too often. Whatever it did worked though, and our paper is now gliding through smooth as a hot knife through butter 👍