Explore My Notes

An interesting look at whether the current mobile-first paradigm is problematic. Ultimately, the title feels a little like click-bait; to me the solution proposed remains mobile-first, but suggests some modern enhancements and some additional (and unrelated) changes to current common practices, such as splitting CSS bundles.

On using media-query ranges to "donut scope" styles for better maintainability:

To this end, closed media query ranges are our best friend. If we need to make a change to any given view, we make it in the CSS media query range that applies to the specific breakpoint.

.my-block { 
    padding: 20px; 
    @media (min-width: 768px) and (max-width: 1023.98px) { 
        padding: 40px; 
    } 
}

With HTTP/2 and HTTP/3 now on the scene, the number of requests is no longer the big deal it used to be. This allows us to separate the CSS into multiple files by media query. The clear benefit of this is the browser can now request the CSS it currently needs with a higher priority than the CSS it doesn’t.

with the CSS separated into different files linked and marked up with the relevant media attribute, the browser can prioritize the files it currently needs.

<link href="default.css" rel="stylesheet">
<link href="mobile.css" media="screen and (max-width: 767.98px)" rel="stylesheet">
<link href="tablet.css" media="screen and (min-width: 768px) and (max-width: 1083.98px)" rel="stylesheet">

Good design involves a lot of decision making, and decisions result in trade-offs. Understanding how to go about considering design decisions is critical to good user experiences and ensuring other metrics – such as performance – are not adversely effected to make something "shiny".

On how good designs (and designers) should understand that every decision has impact, and be able to justify that impact:

Now when I point at an interface element, I still expect the designer to be able to justify its inclusion, but I’d also like to know the trade-offs that were made.

On how to think about the impact of a design:

But the downsides tend to be specific to the medium that the design is delivered in.

In print, you can use all the typefaces you want. But if this were for the web, then the calculation would be different. Every extra typeface comes with a performance penalty.

A decision that might be justified in one medium might not work in another medium.

From this perspective, every design decision is like a balance sheet. A good web designer understands the benefits and the costs behind each decision they make.

On the impact of not considering the long term cost of a tech stack:

But often a decision that delivers short-term gain may well end up delivering long-term pain.

A fascinating and academic deep-dive into how studies of extant organisms and trends in living animal groups could be used to infer colouration and patterning in extinct creatures (specifically here looking at theropods).

On the colour and patterning of extant top-level predators:

Across vertebrate groups, and across habitat types, our biggest modern predators are pretty consistently (maybe entirely consistently) primarily coloured for concealment: that is, they have camouflaging colours and patterns which hide their presence from their prey.

On a possible pattern (not precise correlation) between extravagant ornamentation and colour/patterning:

Faces are often sites for signalling patterns and colours in modern species (e.g. Caro et al. 2017) and a reduction in bony facial ornament could indicate a lessened emphasis on this behaviour, possibly including muted facial colouration.

On other factors that impact colour selection and some of the surprising pros/cons:

Darker pigments, for instance, can protect skin from harmful UV rays and may have antibacterial properties but, conversely, also absorb more solar heat and increase an animal’s thermal load

On how it is likely that dinosaurs would have significantly changed colours across their life:

We should not imagine that juvenile theropods transitioned to their adult colours straight away, however. It took decades to grow gigantic theropodan predators and, in all probability, the route to adulthood was via several different ecological niches (e.g. Holtz 2021), each of which may have had different adaptive pressures on colouration.

There have long been issues (mainly due to browser regressions) with using display: contents; in the wild, but there are still some potential use-cases for effectively removing non-semantic elements from impacting layout calculations and styling.

On the inherent risks of using display: contents:

We have reached a point where we cannot trust that display: contents will ever be safe to use on semantically important elements (like <button>) because it can completely destroy semantics and keyboard navigation.

On rethinking why and when display: contents is useful:

Rather than something you would use for “preserving semantics”, it’s something you should put on a generic wrapper. As long as the user won’t miss the HTML element not being there, display: contents is fair game.On donut-scoping styles so that internal slot components can be made ignorant to the parent containers styles using @scope: quote.If we ever get [CSS `@scope`](https://drafts.csswg.org/css-c...), we’ll be able to slot `the-slot` into the lower boundary, making it breeze to create [donuts](http://www.stubbornella.org/co...) without hashing any strings

Many people use disposable emails to preserve privacy and enhance digital security, so why not do the same with your phone number?

Certainly in the US, where spam calls are a major issue, this does feel like a logical route to take. Terence has a good write-up of the strategies that they use to achieve this, as well as providing an overview of some past attempts at services that could help out.

On the current best option for disposable phone numbers:

The easiest way is to get a dual SIM phone. I have my main SIM which holds my primary phone number. That's the number used by my family, my banks, and anyone vaguely trustworthy. My second SIM contains a free disposable PAYG SIM.

And once I start getting too much spam to that number I throw the SIM away and get a new one with a new number.

On an alternative option, SIP calling plans:

Or, you can set up a SIP calling plan. Install an app and have calls automatically routed to you.

A step-by-step guide to forcing Lightroom to rebuild preview files. This can help reduce the overall size of the Previews folder/database, which often retains outdated previews for files you've deleted, and therefore speed up the catalog as a whole. Below are some of the key steps:

3. Find all missing photos. Before you remove the previews, you’ll want to know if any files can’t be found by the catalog. You’ll want to do this while you still have the previews intact, so you can see what the missing pictures look like. Make sure all drives are connected to your computer or mounted over a network. Go to Library>Find All Missing Photos. You’ll get a notice from Lightroom that all photos are present, or that some are missing.

5. Close Lightroom and remove the Previews. The previews are contained in the catalog folder. They are named [CatalogName] Previews.lrdata. On Windows this appears as a folder, on Mac it looks like a single file. You can either move it out of the catalog folder if you have enough space on the drive, or delete it.

6. Rebuild Previews. Open Lightroom, select images, and go to Library > Previews > Build Standard Size previews. They will start to rebuild.

Tip: If you want this to go as fast as possible, it can be best to run multiple batches at the same time. Select half your files, and start the rebuild, then select the other half and start. This will force Lightroom to use as much of the computer’s processor as possible. It may cut the preview building time significantly.

A lot of JavaScript used on web pages simply waits for a user to click on some element on the page, and then executes a function.

The traditional way of handling this is to use event listeners, but Jeremy points out that this can get a bit hard to maintain if you're applying lots of them.

Instead, use event.target.closest and a universal event listener (e.g. apply a click listener to the whole page) to determine the target and then apply the relevant function. Much neater!

document.addEventListener('click', doSomethingSpecial, false);

function doSomethingSpecial(event) {
  if (event.target.closest('button.special')) {
    // do something
  }
}

On the problems of applying event listeners en masse:

But if you’ve got a lot of special buttons, you’ve now got a lot of event listeners.

The code you’ve written runs once, when the page loads.

If a new special button shows up on the page, it won’t have an event handler attached to it.

On how closest() can help invert that logic and (possibly) improve efficiencies:

You can switch things around. Instead of adding lots of event handlers to lots of elements, you can add one event handler to the root element. Then figure out whether the element that just got clicked is special or not.

On closest() vs matches():

There’s a similar method to closest called matches. But that will only work if the user clicks directly on the element you’re interested in.

Patrick Brosset covers a range of new(ish) web and browser APIs that allow PWAs to benefit from OS-level functionality to style and utilise more of the browser chrome. Specifically, the Windows Control Overlay API

On the new Windows Control Overlay API and what it does:

Window Controls Overlay removes the physical constraint of the title bar and window controls areas. It frees up the full height of the app window, enabling the title bar and window control buttons to be overlaid on top of the application’s web content.

In reality, this feature only gives us about 30 pixels of extra room and comes with challenges on how to deal with the window controls. And yet, this extra room and those challenges can be turned into exciting design opportunities

An excellent look into the new trend of no-or-low-JavaScript web components, which almost operate more like HTML fragments, with graceful fallbacks to native elements. Jeremy proposes terming these "HTML Web Components", but I'm not totally sold on that.

On some of the key positives of native web components:

It’s not just that web components are portable. They’re also web standards, which means they’ll be around as long as web browsers. No framework can make that claim

On thinking about web components as ways to extend native HTML elements rather than create them from scratch:

HTML web components encourage a mindset of augmentation instead.

Instead of all-singing, all-dancing web components, it feels a lot more elegant to use web components to augment your existing markup with just enough extra behaviour.

An official statement from the European Commission on accessibility "overlays" and EAA compliance. The outcome? Overlays are insufficient and potentially damaging to accessibility. Whilst they don't go as far as to actively state "do not use" or "considered harmful" both conclusions are supported by their statements:

Claims that a website can be made fully compliant without manual intervention are not realistic, since no automated tool can cover all the WCAG 2.1 level A and AA criteria. It is even less realistic to expect to detect automatically the additional EN 301549 criteria.

In other words, overlay tools may make a website less accessible for some users.

Ashur has voiced something I've been doing for years: feed readers may be efficient, but that efficiency robs websites of their individuality. I've long had sites that I subscribe to but will always press the button to "open in new tab" rather than read them in the browser, from the genuinely art-directed (e.g. ILoveTypography) to the beautifully simple (e.g. adactio or Ethan Marcotte's site). Some sites are information-first and don't need this treatment, but I wish readers wouldn't try so hard to sanitise the web.

Of course, the action suggested here – set your feed to excerpt only – doesn't actually solve the problem for some modern readers. My own tool of choice, Readwise Reader, doesn't even use the RSS feed to aggregate data, but instead uses it as a list of links to scrape. I don't love this behaviour and find it less reliable than just using RSS most of the time, but it's also a slight reaction to excerpt feeds. Ah well, I can still open in new tab myself 😉

On the joy that is lost by consuming content in a sanitised "reader" environment:

... it’s not just the occasional art-directed post that goes unseen, but the personality — and, dare I say, humanity — of a site altogether, by treating my feed reader as the de facto way of catching up

On shifting from viewing items in the reader versus using it as a notification system:

... the feed transforms from a lifeless simulacrum of the original text to a gentle reminder to check in on something that's bound to be quite lovely.

On how excerpts can help guide readers to treat feeds differently:

Truncate those posts, embrace the beauty of "Read More" links, and drive people to your actual site! You and your readers both deserve it.

A beautiful and extremely clever animation that takes you on a journey through the major theories and breakthroughs in physics, with an excellent score and an ultimate twist that makes me desperately want someone to adapt it into a Journey-like video game, with no dialogue and mind-bending sequences. Seriously, how cool would that final bit be, crafted three-dimensional objects on a world line and controlling time to retroactively help your own prior playthrough progress 🤯