Explore My Notes

Actual CSS breakpoints you need to know | Thomas M. Semmler

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!

📆 03 Nov 2022  | 🔗

  • HTML & CSS
  • media query
  • CSS
  • breakpoint
  • a11y
  • fluid design
  • inclusive design
  • keyboard navigation
  • dark mode 

aria-label is a code smell | Eric Bailey

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

Holograms, light-leaks, & CSS-only shaders | Robb Owen

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>

📆 02 Nov 2022  | 🔗

  • HTML & CSS
  • hologram
  • CSS
  • animation
  • mixed-blend mode
  • layer
  • specular map
  • background
  • fixed 

Imperfectly indieweb | Ross A. Baker

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.

Tailwind and the Femininity of CSS | Elaina Natario

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.

The self-fulfilling prophecy of React | Josh Collinsworth

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.

Visit for a surprise | Eric Bailey

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.

📆 08 Sep 2022  | 🔗

  • Inclusion
  • a11y
  • WCAG
  • 2.4.4
  • surprise link
  • easter egg
  • Rick Roll
  • inclusion
  • humour 

South African snakes | African Snake Bite Institute

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.

Are you serious? | Cortex

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?

Enabling keyboard navigation in macOS | a11y Project

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.

Are you sure that's a number input? | Kilian Valkhof

I often find myself a little unsure of when to use a number input, but Kilian has put together a detailed (yet brief) overview of exactly when it is (and isn't) appropriate. The tl;dr is beautifully summed up as:

If you're dealing with an identifier that just happens to use digits, or a number that represents something completely different once you increment or decrement it by one then you want a regular old text input, not a number input.

That means things like credit cards, passport or ID numbers, or 2FA codes are better to be used with text inputs. Still want the nice numeric keyword on operating systems that support it? Use inputmode=numeric instead.

Of course, there are still times that number inputs are valid. As Kilian mentions, one key use case is for improved validation and refinement of options within numeric ranges and with specific steps:

Secondly they let you use built-in validation logic like input.checkValidity(), and that will make sure that the value is indeed numerical, within the given bounds, and matching to any step you specified.

📆 28 Jun 2022  | 🔗

  • HTML & CSS
  • form
  • input
  • number
  • inputmode
  • 2FA
  • semantics
  • semantic HTML 

How I doubled my lighthouse score in one night | Ben Myers

A very interesting rundown of some common performance checks and techniques that Ben went through to boost their lighthouse score from <50 to >95! I was particularly interested that font subsetting didn't have a huge impact on the score, despite reducing the download size by 44%, but that's still a significant saving and well worth it in my book. Equally, the impact of the native YouTube embed was slightly terrifying, and I'll definitely consider lite-youtube-embed for any future projects that need similar integration:

This move away from YouTube's proprietary embeds ended up being a huge lift for my performance, bringing my homepage's Lighthouse performance score from a poor 48 up to a respectable 81 out of 100. I'd heard just how devastating third-party scripts and trackers can be for a site's performance, and this change really hammered that home for me.

📆 27 Jun 2022  | 🔗

  • Frontend
  • YouTube
  • embed
  • web performance
  • font subsets
  • GitHub
  • Lighthouse 

Made By Me, But Made Possible By:

CMS:

Build: Gatsby

Deployment: GitHub

Hosting: Netlify

Connect With Me:

Twitter Twitter

Instagram Instragram

500px 500px

GitHub GitHub

Keep Up To Date:

All Posts RSS feed.

Articles RSS feed.

Journal RSS feed.

Notes RSS feed.