Explore My Notes

Like many other folk, I've been dipping my toes back into the Fediverse and checking out Mastodon. It isn't my first rodeo in this particular ring, but somehow it does feel a little different this time. Still, having been here before, part of that difference is undoubtedly the increased level of noise and general bluster – attributes I think it is safe to look to Twitter (and that community's culture) to have added.

As a result, I found reading Hugh's post on the influx of new users really interesting. I've seen a lot of pleas to respect existing cultural norms (many of which I quite like), but it's always nice to come across a particularly well-written and thoughtful analysis of the current collision of ideas. In particular, their thoughts on the nature of content consent and sharing are really interesting. I've long thought that Mastodon's stricter rules on things like searchability were a thorn in their side, but this lens provides much greater clarity.

As I've said to many people over the last couple of weeks, Mastodon (and ilk) are not trying to replicate or clone Twitter. They want to be something new. I do think that they copied the core experience a little too much, but I still hope they are able to hold onto that uniqueness and double-down on what are a much better set of foundational principles than much of the social web.

I've also never fully considered the impact of the underlying philosophy of ActivityPub, but I can fully get behind the anarchism versus capitalism concepts that Hugh points out.

(And yes, I'm aware that there is a certain friction in reposting excerpts from an article that explicitly talks about the hostility of finding your voice shared without your consent. I have a lot of personal thoughts on where those lines stand, and the historical benefits inherent in being able to remix and share elements of culture broadly, but I did check, and Hugh's website claims a CC-BY-4 license, so I hope this note is acceptably above board 😊)

On the culture differences between Twitter and Mastodon:

The people re-publishing my Mastodon posts on Twitter didn't think to ask whether I was ok with them doing that. The librarians wondering loudly about how this "new" social media environment could be systematically archived didn't ask anyone whether they want their fediverse posts to be captured and stored by government institutions. The academics excitedly considering how to replicate their Twitter research projects on a new corpus of "Mastodon" posts didn't seem to wonder whether we wanted to be studied by them. The people creating, publishing, and requesting public lists of Mastodon usernames for certain categories of person (journalists, academics in a particular field, climate activists...) didn't appear to have checked whether any of those people felt safe to be on a public list. They didn't appear to have considered that there are names for the sort of person who makes lists of people so others can monitor their communications. They're not nice names.

It's not entirely the Twitter people's fault. They've been taught to behave in certain ways. To chase likes and retweets/boosts. To promote themselves. To perform. All of that sort of thing is anathema to most of the people who were on Mastodon a week ago

On the impact of a cultural shift and the emotional strain that "virality" can cause for those who were not expecting (or wanting) it:

To users of corporate apps like Twitter or Instagram this may sound like boasting. Isn't "going viral" and getting big follower counts what it's all about? But to me it was something else. I struggled to understand what I was feeling, or the word to describe it. I finally realised on Monday that the word I was looking for was "traumatic".

On why features are different between the two platforms:

If the people who built the fediverse generally sought to protect users, corporate platforms like Twitter seek to control their users.

Y'know that thing where Spotify is on shuffle but refuses to play certain songs in your playlist? And you can shuffle the same playlist several times over the course of a week and it'll seem to have "favourites"? Yeah, it isn't just you; this is a real thing and it's stupid. Gabbi has put together a great video essay on why (to the best of their knowledge) this happens and provides some (frankly) common sense suggestions that I deeply hope Spotify hear, take on board, and enact.

tl;dw: Truly random shuffling is annoying, because it creates artist clusters and disjointed play styles, so Spotify binned it. But it seems that they've overengineered it in the other direction (I mean, do you remember when shuffle on Spotify would occasionally catch you off guard with a track combo that just worked but made no sense? That doesn't seem to happen anymore!), and now factor in idiotic metrics like artist popularity and how often you've listened to a track, creating a recursive loop where the algorithm consistently reinforces its own bad guesses. This shouldn't be surprising; they made the same mistake with the weekly "for you" playlists, where these slowly become more and more focused around the kind of music that (you guessed it) they had been recommending for the past couple of months. Still annoying though, and Gabbi's suggestion of keeping most of that stuff but seeding the playlist with a truly random starting point just seems so obvious to me as a fix that it's baffling how a company with the data, money, and talent that Spotify has doesn't just, y'know, do that.

An excellent overview of why the typical "listicle" style tweet purporting to show you the "only breakpoints you'll ever need! 😎👇🧵" is not just silly, but actively missing the point of responsive design, fluid layouts, and the modern web. Thomas has written a really nice explanation as to why breakpoints occur, the history behind them, and (importantly) how we're only just beginning to fully understand the real breakpoints: motion preferences, colour schemes, input variation etc.

In other words, media queries may be useful for art direction and formatting, but if you actually want to understand the true CSS breakpoints, you need to look at very different parts of the spec.

On the misuse of the term "CSS breakpoint" (as opposed to media query or just breakpoint):

There are no "CSS Breakpoints", because not only is it not CSS that is breaking, but they are also not exclusive to CSS.

On Twitter grifters:

Unfollow people that give you listicles of arbitrary pixel values to satisfy your desire to have it easy. The web is easy. But it is also very complex. You better get into it!

A very interesting breakdown of why accessibility auditors often see ARIA labels as red flags, deftly explained (as ever) by Eric. (I also must admit that the interactive-only aspect of ARIA labels had gone over my head 😬)

When I encounter too much, or mis-applied aria-label it makes me take notice. This code smell puts me on alert to investigate things more thoroughly, as it most likely indicates accessibility issues.

On the big misconception about ARIA labels:

First off, aria-label is intended to only be used on interactive elements, and not non-interactive ones.

On the best path forward:

If it is important enough to need words, it is important enough to use text content.

On ARIA and styles (I'm still not sure I 100% understand this; is the implication that ARIA is somehow a stylesheet?):

aria-label content will not show up if styles fail to load

Robb has come out with some very cool ideas over the years, but wow, seeing CSS-only specular highlighting and holograms is such a neat trick 🤯 I immediately want to co-opt some of this for the logo on this site, though their write-up comes with a fairly clear caveat of "here be dragons" (see below). Still, I love that background-attachment: fixed is a major player here; that's a property which always felt powerful, but I rarely use. Robb shows how incredibly useful it may become!

(Also, definitely go read the original article on this, because the examples Robb has put together are infinitely more useful than the text, and they've included a really great breakdown of how all of the mixed-blend modes in CSS actually work 👍)

On the very clever use of a fixed background attachment:

Fortunately, there's a vintage CSS Level 1 property that can help with that; setting .specular to background-attachment: fixed means that, as the page scrolls, the gradient remains locked to the browser's viewport. This not only brings some much needed motion to our shader, but also means that we can very roughly simulate the changing view-angle without reaching for JavaScript.

On how specular mapping works:

Blending the gradient directly to the base layer will mean that the lighting will be totally uniform across the image. Aside from chromed surfaces, that doesn't happen too often in nature. To really sell the effect we want to have control over the areas of the image where light can fall and where it can't. To simulate this, we can use a predominately dark image to mask out our gradient. This technique of using a dark image to mask off areas of a lighter one is often known as a specular map.

Until now the examples have all used a greyscale specular map, but a full colour specular map can introduce new effects.

On why this is a great proof of concept, but probably shouldn't be used:

At the time of writing, blend modes in browsers are still pretty resource heavy. For more complex effects, with several layers of compositing, you will see a real performance hit. Add any CSS animations or transitions to the mix and it will really tank - particularly in Safari. [...] As great as these effects can look though, I think that for now this is very much a case of: just because you can, doesn't mean you should.

The final code used (sanitised for my own use):

<div class="shader">
  <img src="image.jpg" alt="...">
  <div class="shader__layer specular">
    <div class="shader__layer mask"></div>
  </div>
</div>

<style>
  .shader {
position: relative;
     overflow: hidden;
     backface-visibility: hidden; /* to force GPU performance */
  }

  .shader__layer {
     background: black;
     position: absolute;
     left: 0;
     top: 0;
     width: 100%;
     height: 100%;
     background-size: 100%;
     background-position: center;
  }

  .specular {
     mix-blend-mode: color-dodge;
     background-attachment: fixed;
     background-image: linear-gradient(180deg, black 20%, #3c5e6d 35%, #f4310e, #f58308 80%, black);
  }

  .mask {
     mix-blend-mode: multiply;
     background-image: url(/image.jpg);
  }
</style>

It feels like the broader web is currently rediscovering the impermanence of the siloed web (Facebook, Twitter, Tumblr, et al.). Ross's article does the best job of articulating how a lot of people are thinking (and touching on some key stumbling blocks in the process). Plus, I just really love the way this paragraph is phrased (emphasis mine):

A few months later, I joined Twitter. I tweeted about 9,500 times, and you can read them all there today. Will we be able to read them in 25 years? Doubtful. I downloaded my archive before I left, and I might rerecord the greatest hits, but the original masters belong to the label.

It will (hopefully) come as no surprise that I found myself nodding vigorously throughout this excellent article by Elaina, which shines a light on some of the reasons that CSS tooling can leave a bitter taste.

I've come to accept that frameworks and tools like Tailwind do have genuine use cases and advantages, which I often find myself discussing (and even defending) in online discourse. But I frequently find myself encountering rhetoric that broadly states that "X tool is better than CSS" and I can't disagree with that more. As Elaina says, not every web developer needs to understand the nuances of CSS (as not every web developer needs to understand the nuances of GraphQL, or React, or ARIA). There are a lot of skills nested within "web developer". But web development teams seem to be okay deprioritising (or actively ignoring) a need for some expertise in CSS, where other technologies are prioritised, and I've always felt these issues all stem from the same root cause: CSS just isn't seen as a valuable skill, and that's just silly (and, yes, likely more than a little sexist).

Best of all, Elaina's summed this all up in much clearer language than I could have ever managed! (see above 😂)

On the result of non-CSS developers needing to understand CSS and becoming frustrated with it, rather than taking the time to learn it:

Those “fixes” manifested as CSS-in-JS, Material, Bootstrap, and Tailwind, to name a few. [...] These frameworks aren’t inherently bad. They lower the barrier to actually put working CSS on a website. They’re especially handy when it comes to rapid prototyping; spinning up basic UI has never been easier. The API-like patterns are familiar to many developers.

On the danger of relying on CSS shortcuts, like frameworks:

The important bit is that they hinder deep learning of CSS.

On how CSS being seen as somehow "inferior" results in more space for traditionally marginalised groups:

There are surely plenty of people of marginalized gender experience in all programming spaces, but they don’t have as much opportunity to surface new ideas. CSS is only allowed some slight breathing room simply because other programmers don’t even consider it to be part of web development.

On the core premise:

So when it comes down to the root of the problem, perhaps it isn’t CSS itself but our unwillingness to examine our sexist ideas of what is worthy in web development.

I've been saying for years that React feels like jQuery did circa 2010: it's used everywhere, its devotees are numerous, but the leading edge left it in the dust a while ago. I do think that Hooks have helped keep it fresh for a bit longer – or at least, stopped it from going stale sooner – but as native browser APIs continuously pick away at the edges of its functionality, and as the world wakes up to the need for performance and UX over DX and nice repository management, React feels clunkier and clunkier. (And this is coming from someone writing on a React site, working in a React job, and actively still happy using React.)

Anyway, what I've been hinting at, Josh has actually put into some darn good words. In particular the methodical tackling of the biggest "reasons for React" is well balanced and summed up. They also have an eerie habit of perfectly picking their pull quotes to align with my own bookmarking habits, so there's that, too 😂

On the central thesis:

React does what it does well, but it doesn’t do anything better than other frameworks.

On why "most popular" does not equal best:

But it’s not fair to say that React really demonstrates better ability here. It’s just been given more opportunities.

On the potential issues of picking dev velocity over long-term stability (*cough* Tailwind *cough*):

Choosing React just for the sake of getting new devs up and running faster is short-term gain for long-term loss. (Tech debt, in other words.)

On the performance issue, one of the core reasons businesses should be looking elsewhere for greenfield work:

If your company lives and dies by mobile usage, for example—especially in places with comparatively low-powered devices or networks—you might (literally) not be able to afford React’s performance tradeoffs.

How should a Rick Roll link (obviously hidden from sighted users) be marked up for assistive technology? That's the question Eric is answering, and the result can be summed up as: preserve the whimsy! It's great seeing an approach to WCAG interpretation that both considers the full intent of that spec and attempts to preserve experience as much as possible. That's always felt like the right method to me, so nice to see that validated 😁

The interesting part here is whether you should announce the fact that you're linking to autoplaying media (if, in fact, that is the case). I fully understand the argument, but can see justification that this also slightly contradicts the core message. I guess the best solution in this instance is to have a link that seems to be going to one video (and therefore can be visually and audibly tagged as linking to media) but which lands on a Rick Roll, though that might still take some of the fun away (though, as I say, I do understand that "fun" will not be had by people whose day is actively made worse/unbearable by sudden noise or movement, so yeah... pranks are a little hard for inclusion 😬).

(Also, the provided example of a "surprise" link is exceptional, but I leave it up to you to discover it by yourself.)

On the actual wording of WCAG 2.4.4 specifying that links provide an equal experience:

I love this. This is all about maintaining an equivalent experience by not over-describing something for only a certain subset of people. Here, the goal is to preserve the author’s intentional act of creating a sense of curiosity, regardless of the way someone interacts with technology.

2.4.4 is as much about preserving the intent behind why the link was important enough to be added as it is that the link’s accessible name makes sense. If the author intended to be purposely ambiguous, we need to honor that and not ruin the joke.

On Eric's suggested solution:

“Visit for a surprise” preserves the author’s intent. It’s a little mystery object you can poke if you’re feeling adventurous. If you’re not, you can carry on with whatever you were visiting the site for.

A surprisingly detailed identification guide to the snakes of South (and Southern) Africa, including diagnostics, multiple photos, species ranges, and (usefully) relative danger to humans.

An interesting discussion from the peeps on Cortex on the mindset it takes to achieve big goals (around the 50-minute mark). Lots of people talk about "writing their novel" or "fixing x political issue", but are they actually serious about it? How are they spending their time? Are they working on the things that provide the biggest impact for the least input; the kind of stuff that might actually move the dial? Or are they working on the frivolous, busy work around the edge. Are they writing short stories and trying to get them published? Or are they attending a bunch of creative writing seminars or English lit classes?

Are you serious? Like, really serious? Or are you just doing things that make it look like you're serious? That feel like progress. (In other words, are you procrastinating with secondary objectives). Feels like a useful mindset to just check that the thing you're working on aims you at your goals or whether it just distracts from the hard work.

Are these people actually serious about trying to achieve objective X?... This group looks like they were trying to achieve objective X... but are the steps they're taking the steps you would do if you were serious and making a world where X was possible?

I was not expecting to find browsing the web with a keyboard so damn tricky on macOS, but here we are 😂 The tl;dr of the situation is:

• Enable "Use keyboard navigation to move focus between controls" in System Preferences --> Keyboard --> Shortcuts;
• In Safari, turn on "Press tab to highlight each item on a webpage" in Preferences --> Advanced;
• In Chrome, turn on "Pressing Tab on a webpage highlights links..." in Settings --> Appearance;
• In Firefox, open a new tab and enter about:config into the URL bar; create a new "integer" value; give it the name accessibility.tabfocus; and set the value to 7 (who knows what black magic that actually does, but it works 😅)

It's best to enable everything and then restart each program. I didn't need to restart the Mac itself, but it's always worth a try too, I guess.