Tagged “feedPosts”

Over the last few years I’ve played some radio shows but hadn’t done a mix of my own. I managed to rectify that the other night.

I read this book in two days while on holiday in Ibiza. It’s been a while since I’ve finished a book so quickly, but it’s short and once it had me locked in I couldn’t put it down.

The old adage that you shouldn’t judge a book by its cover is definitely true of this one. The cover depicts a faun standing on a marble column and conjures images of fantasy and mythology. There is an element of that, but with constant hints to the modern world. And as clues emerge you start to wonder if you’re really in an another time and space, or in the middle of a dream or some Jacob’s Ladder style trip.

The protagonist, Piranesi, is really likeable and I loved the humour too. The puzzle he’s trying to solve called to mind Memento and the dream-like feel reminded me of the scene in Inception where Cobb meets Saito in Limbo.

I loved it! Thanks to Craigy B for the recommendation.

I’ve written before that CSS transition is great for simple animations triggered by an event. You might want to transition something in response to a focus or hover event. Or, perhaps your use case is that the user activates a button to launch a previously-hidden dialog element and you want to use transition to animate the dialogue’s entrance and exit.

Recently I updated this website’s git repository README to include a summary of my approach to supporting post excerpts.

I define an initial part of a post as the excerpt by adding a separator string between it and the remaining content. Then in my posts list I grab 11ty’s post.page.excerpt and pass that through a custom markdown-parsing filter.

This works pretty well but sometimes it’s a bit inflexible that the excerpt has to be part of the post. Sometimes you might want to say something different, or shorter and snappier in the excerpt.

I’m partial to going down the rabbit-hole on a niche aspect of front-end development. For example a few years ago I got the urge to dig into what’s going on with containers and items in Flexbox-powered layouts and noted my findings in Flexbox-fu. I do it to go beyond the thing’s theory and into its practical application for solving real web development challenges; to gain a deeper understanding of why things behave the way they do. These deep dives take time but are rewarding; usually I’ll learn about more than I expected.

Recently I dug into the characteristics and behaviour of the CSS outline property. The catalyst was seeing Heydon Pickering’s clever use of outline to automate divider lines within a flexbox powered navigation menu. I couldn’t fathom how it works so decided to reverse-engineer it. More on Heydon’s trick later, but I’ll start with a recap of what outline is good for.

A thought-provoking look at how LLMs might lower the burden of writing useful alt text for images, and – given the right prompts – produce better results than humans doing it manually.

It’s far more descriptive than what I would have written without it.

Jared goes on to argue that the benefits really multiply when working at scale. This part made me think of the content team at my work who maintain a customer-facing knowledge base and need to write alt text for hundreds of screenshots.

A huge time-saver is if you’re working with a large set of images. You can write the prompt only once and then say you want the same applied to each image you upload.

Hidde is, like me, both an “accessibility nerd” and “a components enthusiast”. So it’s interesting to see him tackle whether it’s sensible for design systems – even really good ones – to “promise accessibility”.

We should definitely test how accessible components are and document what they can and can't contribute to a website's accessibility. And WCAG requirements can help with this. However, I think claiming WCAG conformance about pages or sets of pages, as we do today, approaches it at the right level. I don't think we should want to claim conformity of components by themselves.

He goes on to say:

There's a real risk in overpromising the value of a component if we say it is accessible or conforms to some accessible standard. It could make people believe that they no longer need to worry about accessibility once they use or buy the component. That creates the wrong expectations: accessibility is a continuous process. Like we want to always iterate on user experience, we want to always iterate on accessibility.

Here are my main takeaways.

In my recent post Website updates I said:

I’ve added myself to 11ty’s community and am now listed as an Eleventy author. I hope that some day I’ll find that fuzzylogic.me has been added to 11ty’s Speedlify Leaderboard too – that’d be cool!

Well, about a week ago I noticed that I have been added to 11ty’s Speedlify Leaderboard and not only that I’ve gone straight in at the very respectable rank of #23. I’m among some really talented company there so I’m proud of that!

At work, my talented colleague Anda and I have been taking a fresh look at modal dialogues with a view to modernising relevant design system components. During this project I’ve expanded my knowledge of the HTML dialog element, especially the nitty-gritty of using it in practice.

I’ve recently been updating my website over a series of nights and weekends. The changes aren’t very noticeable to the eye but involved some careful modernisation and streamlining of back-end features and technology, plus improvements to accessibility and performance. I’m really happy to have made them.

Danish composer and producer Marie Louise Buch’s LP from last year is on heavy rotation chez moi at the moment. It’s a chill but heartfelt mix of sun-drenched guitars, electronics and ML’s pure vocals that has elements of The Durutti Column and maybe even The Cocteau Twins… and it’s really hitting the spot for me.

You can preview in full and buy on Bandcamp.

Thanks to Phillip H for the excellent recommendation. And I’m of course now jealous that I wasn’t a fan of ML in time to go to her Glasgow gig last year.

I didn’t have the appetite for Kazuo Ishiguro’s latest novel during the pandemic. I started it, but as the underlying sense of melancholy and “something bad around the corner” began to set in – just like it did in Never let me go – I realised I wasn’t in the right frame of mind for it. Cut to 2025 and it was time to give it another go.

I’d read before that Ishiguro is primarily interested in exploring what it is to be human, and uses science and technology elements as a device to support that. In Never let me go the device was cloning. In this book, the narrator is an “artificial friend” named Klara who is an AI-powered, empathetic android, and Ishiguro uses Klara’s unique perspective to shine a light on human behaviour and motivations.

I won’t attempt to properly review the book when others have done it much better. I’ll just say I really enjoyed it and recommend it.

Here are a few scrappy notes about themes I found interesting and jotted down.

• Scientific and technological advancements that present moral questions
• the idea of genetic editing (modification, I guess) to gain advantage, but with risks and side-effects. The gamble this represents.
• human loneliness
• blind faith/religion (which even Klara, as a rational machine, learned)
• Klara’s capacity for innocence, morality, contentment in a way that the humans seemed incapable of
• The idea that we can’t create identical clones of people because it’s not just their makeup that makes them unique; there’s also how others love and perceive them (which can’t be copied)
• the potential dark side-effects of our societal choices and technological advances: environment collapse and pollution; societal divisions (the father Paul’s armed community)

Clair bought me Jude Rogers’ book for Christmas thinking I would enjoy it – and I did. I love the idea of chronicling the milestones of your life using music – music that touched you, that you were obsessed with, or that bonded you with significant others.

I also enjoyed reading the science behind the feelings. As Jude asked in the first chapter:

How do songs affect our emotions so profoundly? How can they activate memories instantly?

It turns out that babies can recall what they heard while in the womb, and are predisposed to get music in a manner beyond advanced computers. The medial prefontal cortex – an area of the brain linked to our sense of self – is involved in tracking melodies. There are lots of these interesting insights.

Jude’s tunes ranged from Abba to Krafterk to Toots and the Maytals, which I found good fun. And as proof of music’s facility for time-travel, her final chapter on Prefab Sprout’s I trawl the megahertz transported me back instantly to my desk at Bright Signals’ office in 2018 during my contract there, where my friend Andy’s playlists introduced me to that unique tune.

I’ve just finished reading F. Scott Fitzgerald’s The Great Gatsby. It’s short so was a perfect holiday read.

I enjoyed the ride as the mystery of Gatsby’s identity was revealed. Although it transpired he was no angel, I sympathised with his aspirations to make the most of himself. I felt sorry for him as he pushed against the tide, and others either exploited his generosity or (in the case of the “old money” set personified by Tom Buchanan) blocked him from moving in their circles.

The last passage is pretty thought-provoking:

Gatsby believed in the green light, the orgastic future that year by year recedes before us. It eluded us then, but that’s no matter—tomorrow we will run faster, stretch out our arms farther. . . . And one fine morning——

So we beat on, boats against the current, borne back ceaselessly into the past.

From what I can gather it alludes to the futility of constantly “reaching” in the face of opposition and at the expense of the good opportunities and life you could already have. It’s a path that can lead you to bad morals and values and end in unhapiness. It has special meaning in the context of the American Dream but I think there’s a general theme. Live in the present; learn to value what you have.

I loved Jason Pargin’s I’m starting to worry about this black box of doom.

It’s one of those stories that captures the zeitgeist amazingly well (a bit like The Social Network did back at the time). In this case it captures the tendency for folks online to blow things out of proportion; to catastrophise and to think the worst.

The black box has a boogie-man physical form in the book, but it soon becomes clear that it’s a clever metaphor for perhaps the real source of anxiety and division in the modern culture.

I loved the charcacters, the dialogue and the dark comedy. I especially enjoyed Ether’s vain attempts to make Abbot realise that everything isn’t really terrible and is arguably – arguably! – the best we’ve ever had it.

I 100% recommend this book.

Had a great local night out there. After meeting Gillian and Aarti for some lovely food at Lobo, Clair joined us at the local Tramway theatre for the show.

I’ve previously read and enjoyed a couple of Haruki Marukami’s books and from what I’ve learned about his interests I generally like the cut of his jib. So it was great to hear that there’d be a Murakami theatre production on our doorstep, and intriguing to see how they’d pull off the weird, dreamy nature of his stories. As it happens our neighbour Matt is the artistic director of Vanishing Point and he’d already mentioned in passing that they’d been collaborating with Japanese organisation KAAT, so I’d been looking out for this one.

The show didn’t disappoint. The performances (joint Japanese and UK performers, each speaking in their own language), shapeshifting set design and lighting were fantastic. In particular we loved the creative ways they presented the ryokan and onsen (hot springs bath) scenes, which took me and Clair back to our 2016 trip to Kyoto. The theme of losing your identity was interesting too.

At the end we all hung out in the concourse where there were some tasty plates on offer from Sushi Riot.

Shout out to Gillian who got us our tickets for show. We loved it.

Our 2024 Christmas present to each other was to take advantage of cheap winter flights and go somewhere we’d never been for a weekend. We settled on Venice and I’m so glad we did.

We stayed at The Venice Times hotel which was a great choice – well located near Santa Lucia station at the north-west of the island city and friendly, quiet and cosy. It was a little cold while we were there as we’d expected but the sun still shone most of the time and it was warm enough for us to occasionally sit by the Grand Canal to enjoy a spritz or glass of wine.

Among the highlights of our trip were:

• Lunch at Osteria alle Testiere
• The Peggy Gugenheim Collection
• Seeing and hearing Vivaldi’s The Four Seasons played live by string ensemble Interpreti Veneziani at Chiesa San Vidal
• Rialto fish market
• walking the winding streets, through networks of canals
• beautiful bridges, stunning views and the occasional boat-bus
• Ritaridiente mezcal cocktail at Chet’s Bar, Dorsoduro

With more time we would have taken a trip to Burano. But maybe next time.

I purchased Scott’s course back in 2021 and immediately liked it, but hadn’t found the space to complete it until now. Anyway, I’m glad I have as it’s well structured and full of insights and practical tips. I’ll use this post to summarise my main takeaways.

Having completed the course I have much more rounded knowledge in the following areas:

• Why performance matters to users and business
• Performance-related metrics and “moments”: defining fast and slow
• Identifying performance problems: the tools and how to use them
• Making things faster, via various good practices and fixes

I’ll update this post soon to add some key bullet-points for each of the above headings.

I loved books like Tim Brown’s Flexible Typesetting, Jason Santa Maria’s On Web Typography and Richard’s own Web Typography. And I’ve used lots of their tips in my work. But I’ll be honest: they’re esoteric, complicated, hard to remember, changing rapidly with browser support… and the advice varies from one expert to the other. So I’m very grateful that Richard has provided this reusable stylesheet of great typographic defaults, making it easier to handle all the complexities of good web typography.

I’m testing out the Eleventy Image plugin. Here’s a post with an image which, if all goes well, will be converted by the plugin from source jpeg into lightweight avif and webp formats and the underlying code transformed from a basic img element into comprehensive modern HTML image syntax.

Glad I accepted the invite from Jason and Tom to attend their in-store event. After some free beer and pizza, Luke introduced Jordan from Tough Luck, an Instagram account spotlighting up-and-coming youth culture photographers. He interviewed Glasgow photographer Selina Paton (@glesgaonfilm). I ended up sat next to Selina’s Dad for that part!

A book entitled Tough Luck: You out tonight? is out now on Velocity Press. I got a lovely sense of enthusiasm for clubs and club culture from the guests, and enjoyed their analogy about film versus digital photography being a bit like vinyl versus digital audio – it’s just different and you can’t recreate the feel retrospectively.

Aside from Tom and Jason it was also nice to see and chat to folks like Lydia (and her friendly crew of edgelord neighbours), Dom C and Hayley.

Ethan assembles numerous technology articles, some of which are enthusiastic about generative AI and LLMs while others highlight political, social and health impacts and risks.

I’ve just finished reading Bicycle Diaries City, by David Byrne. It’s a log of Byrne’s observations and insights as he pedals through major cities of the world including Istanbul, London, Berlin, Buenos Aires, San Francisco and Manilla.

It was an enjoyable read that ambled along pleasantly throughout but got much better in the final chapters as he describes his efforts to effect change and his thoughts about how things could be.

He was a prince.

Alejandro Innaruto’s description of Ryuichi Sakamoto puts it perfectly.

This BBC Sunday feature offers a fascinating insight into an amazing man. I loved it!

It starts with how 1952, the year of Sakamoto’s birth, was an important year in Japan’s post-war transition. It explores his influences including Debussy, his exceptional talent for melody combined with a taste for experimentalism, and how with YMO he satirised anti-Japanese prejudice. It covers his anti-nuclear stance, and how he is a huge icon in Japan where they see him holistically for everything he represented.

Most of all I just marvel at his music – it perfectly captures my taste (and I realise after this documentary that I still have so much of his to explore, which is a happy thought). I loved the parts where the commentators gush at the beauty of his Last Emperor soundtrack (“every note is like paradise”) and when Alejandro Innaruto relates his experience of first hearing the opening two notes of his soundtrack for The Revenant.

Yesterday was the celebration of the life of Ewan (Ginny). It was a beautiful service held at The Hurlet crematorium then at No 10 Hotel.

His was really a unique life and it was wonderful to hear from Sally and others about his family life, his time at university (we were at Strathclyde Uni at the same time), good times with friends, his love of music, his inspiring career, the way he handled his medical condition and more. I’ve also never heard music I love such as Carl Craig’s A Wonderful Life and Underground Resistance’s Journey of the dragons played in the context of a funeral and I found that aspect (and how Marty had thoughfully chosen those pieces) very moving.

It really was a mixture of sad and happy. I hope Ruth was happy with how everything went – I think she was. A fitting send-off to a great person.

I’m not the most confident public speaker these days. So I had mixed emotions when my neighbour asked me to talk about my career at Pollokshields Primary School where he teaches.

However, I liked the theme of helping the kids to expand their horizons. And I’m keen to be involved in the local community, so this was a good opportunity.

I also had my fears dispelled somewhat when I heard that although there’d be lots of kids they were all around 11 years old. I’m working on my presenting and workshop facilitation skills at the moment so again, a good opportunity with – hopefully - a captive and gentle crowd!

I’m pleased to say it went well and generally gave me a warm glow. On reflection I think I prepared well, my nerves were manageable, and I communicated clearly. The kids were lovely and asked lots of questions! What characteristics do you need to be a good software engineer? Did my parents support my career choices? And so on.

They also gave me a lovely certificate and a large Dairy Milk bar (something that’s always welcome in our house).

Having a lovely Sunday morning stroll with Clair and Rudy through Crawick Multiverse, a land art installation. Here’s a bit about this interesting place:

Nestled within the rolling hills of Upper Nithsdale in Dumfries and Galloway, this major land restoration project has transformed a former open cast coal mine into a spectacular artland and public amenity.

A renowned cultural theorist, land artist, architectural historian and co-founder of the Maggie’s Cancer Care Centres, Charles Jencks was commissioned by the Duke of Buccleuch in 2015 to design an inspiring landscape on the former open-cast coal mine near Sanquhar in Dumfries and Galloway.

We made our way through the Amphitheatre and between “landforms” with names such as Andromeda, Supercluster of Galaxies and Omphalos. And we stopped to enjoye a lovely wee picnic atop The Milky Way. Most definitely something different, and Rudy seemed to enjoy his first spacewalk too.

I loved this insight into Adam Silver’s thought process. And it came at a timely moment since at work I’m currently trying to promote evidence-based, considered choices regarding user interface patterns.

My summary of Adam’s key points is:

• he found a UI pattern (let’s call it pattern x) in his project and flagged that while it’s not always bad it risks numerous usability problems. He lists these problems.
• he advises that pattern x is beneficial only in very specific situation y
• and that otherwise, pattern x is unnecessary and a more basic solution would not only require less work but provide a better user experience
• given this context, he asks others working on the project the following:
  • can they explain why pattern x was used?
  • did research (really) indicate a need? (this implicitly also asks if evidence or research was considered at all)
  • what else was tried beforehand? (this also subtly checks for awareness of the risks of pattern x and whether other options were even considered)
  • even if the use case was appropriate, given the downsides of pattern x were you comfortable the benefits outweigh those?

Adam also mentions how on this occasion, in the end, he had to grudgingly stick with pattern x because even though there were possible alternatives, his team didn’t have time to research or implement them. A familiar dose of real life, there. It’s worth being clear, though, that their implementation of pattern x (an accordion) is at least accessible, since as far as I can tell it uses their modern accordion design system component. If that were not the case, I imagine it’d be even less viable to leave it in place.

I was recently sorting through some old stuff when I found a tatty old poster I used to love and that brought back good memories. It shows the gated basement vault of the original Tresor nightclub at Potsdamer Platz, Berlin. Smoke is billowing out of the room dramatically and it includes the text The Extremist. I bought or otherwise acquired this poster on a night in 2005 when me and friends Davie and Tom visited the famous club during a trip to Berlin.

That was a great trip. While Davie wasn’t in the best of health at the time, we still got up to a variety of high jinks, including a memorable drinking session with techno legend Dan Curtin who was releasing music on Tom’s label at the time. (I think that was my introduction to strong Belgian beer, and I remember being mightily impressed when Dan cycled off at the end.) I also remember we stayed in Prenzlauer Berg, at Transit Loft if I recall rightly.

Anyway while reminiscing I embarked on a little bit of internet spelunking. It turns out that there is some interesting video and audio footage from the time we were at Tresor.

I remember that the DJs/acts playing in the Globus upstairs area of the club that night included Blake Baxter and Abe Duque. And guess what, here’s a cool video Abe Duque made that very night. It shows him walking through Berlin, arriving at the club (you see that striking Tresor logo projected on the building) then entering. There’s also some cool footage of the vibe in Globus.

One of my strongest memories of the night was hearing Vainqueur’s Lyot while we were downstairs in the basement. The track is a Basic Channel classic and, while on the harder end of their output, it feels to me like it was tailor-made for environs such as the one we were in. What a moment! So imagine my delight when I found a live recording of that set by DJs Julien & Gonzague with Lyot at 46 minutes. So good to be able to relive the moment!

Lastly, here are some excellent articles (with photos) I found on my internet travels which are worth a look.

• Tresor by BLDGBLOG
• Tresor: A History of Berlin’s Iconic Music Venues on the Love from Berlin blog

With Clair off having fun in Skye, the boys (me and Rudy) have been spending some quality time together. On Friday night we watched Dune 11. Rudy wasn’t too bothered but I really enjoyed it. It looks absolutely stunning, especially the all-white gladiator scene. And I thought the heavy, growling soundtrack marked a return to form for Hans Zimmer. While watching I munched on a paneer palak from local heroes Kebabish which, let’s be honest, is inifinitely better than popcorn.

On Saturday with the sun shining and some post-curry guilt, we set off early and walked up Drumgoyne Hill. It was steep but really good fun.

We even made it home just in time to watch Celtic beat Rangers to (just about) clinch the league title.

Recently my work colleague Francesco told me about a new Edinburgh branch of Homebrew Website Club. Exciting! I unfortunately couldn’t make their first event but just attended their second event. Here’s how it was billed:

Join us in Edinburgh for demos of personal sites, recent breakthroughs, discussions about the independent web, and to meet IndieWeb community members!

It was good fun! Great to chat about and personal websites and writing with fellow tinkerers. I’m sure I’ll be back.

I like the metaphor for personal websites of tending to a digital garden.

Like all gardens, they can become a bit unruly and need some weeding. Right now, as I consider updating some software and freshening things up, I realise that I’ve let it overgrow a tad.

So, here’s a post in which I’ll log my website’s current features. This should be useful in and of itself as a stepping stone to writing a proper readme. However it’ll also help me reflect on my website’s health and maintainability so I can decide which features to nourish and which to prune.

Note: this post will take a bit of time and a few sessions, so please regard it as a work in progress.

What I want

Before getting lost in stuff I have, I thought it’d be good to set out my higher-level goals and what I feel I have the time to sustain. I think I’d like:

• to retain URLs and SEO through updates
• excellent accessibility and performance (four hundos on lighthouse is a good start)
• it to use the best of modern web standards
• simplicity: minimal dependencies, easy to make technical updates
• to maintain some documentation to support ease of updating
• minimal noise: I don’t want a bunch of emails from third parties, nor ongoing dependency update alerts
• sensibly organised content
• a search function
• a way for folks to contact me
• some personality in the design and content
• be able to add and edit content easily (a mobile-friendly CMS rather than via code only)
• be able to insert photos into content easily

And here are a few secondary and lower-level wants:

• code snippets should look good
• images complexities handled behind the scenes
• some indieweb features supporting interactivity with other bloggers and friends

What I actually have

This is gonna be a much lower-level set of features than the above goals, but that’s OK. I can ask myself whether each supports my wider goals and are worth the effort.

Main tech stack

It’s a statically generated site powered by Eleventy.

The code is hosted on GitHub.

I use Netlify for production builds, deployments and hosting.

I’m happy with this stack. The parts play well together, it’s free, and it brings a lot of flexibility and performance benefits.

CMS

I use Decap CMS. It’s free and is working OK, however the UI is rubbish on a small screen.

I previously tried both Netlify CMS and Forestry for a while then gave up on them. I also sometimes use github.com as my CMS. That works but isn’t ideal.

SEO

I provide an XML sitemap which is intended for search engines and a human-readable sitemap.

Key pages

Home

An intro, and a list of latest posts.

About

Some information about me that’s currently split between my interests in the web and music.

Contact

It’s a form, and for its backend I use Netlify Forms. That gives me the server-side handling, database storage and admin management aspects of a form for my otherwise-static site.

Journal Archive

Access to all published posts.

Search

A JS-based form for searching all posts, with an autosuggest function. I use pagefind to power the search.

I don’t like how it’s JavaScript dependant and in future I should look at trying Zach Leatherman’s web component.

404 page

I have a 404.md file which sets a permalink of (i.e. is built as) 404.html. Having made that file available, Netlify does the rest… which is nice!

Detailed features

Avatar

I serve an avatar from a conventional location per Jim Neilsen’s idea – see my avatar.

Environment variables

I set NODE_ENV to production as an environment variable in my Netlify dashboard. This should mean that packages under devDependencies are not built in production which is good because that’d be a waste of time. With the dotenv module installed, if the NODE_ENV variable is present its value is loaded into Node.js’s process.env property. That allows me to check in JavaScript whether or not the current environment is production. With that, I might avoid outputting draft posts to physical files in production, or avoid hitting API resources in local development.

Only JS files can access process.env. So, in order to be able to check “is this production?” in other files such as Nunjucks templates I have an eleventy data file named app.js which makes the environment value available via `production.

Incidentally I used to set another custom environemt variable called ELEVENTY_ENV to production in the source-controlled package.json, within the build NPM script. I think this is now redundant given that I can use NODE_ENV for the same purpose. I previously used it within a Netlify lambda function that posted to the Github API to create new bookmark posts. I don’t do that any more so I can delete this environment variable.

Excerpts

I use gray-matter’s default approach for including, delimiting and parsing excerpts from posts. The excerpt is both part of the post content but also accessible separately, which is useful for showing only the excerpt in post lists.

It’s not perfect. It’d be useful to have a class on the excerpt. It’d be useful to be able to apply different styling to it on-demand and not on every post.

Favicons

To do: write a description.

Image plugin

I use Eleventy Image to perform build-time image transformations. It takes images I’ve added in posts and pages and converts and saves them into multiple formats and sizes, and swaps the original markup for modern, responsive, multi-format image markup using picture and source and pointing to the converted image files.

Linting and code formatting tools

I use a .editorconfig file to set how my editor should handle things like nested line indentation, inserting an end of file newline and so on. I just go pretty much with what the 11ty base blog repo uses, although I haven’t yet switched from spaces to tabs.

I have a .prettierrc config file which sets things like a preference for single rather than double quotes. The idea is that you also have a prettier editor extension enabled (I have one for VS Code enabled) and in your editor settings you set your editor’s default formatter to that prettier extension. It’ll then format files on save.

Netlify config

I have a .netlify.toml file in which I specify the build command (npm run build) and the directory to publish to. I also use it to set far-future expires on custom font .woff2 files. As far as I’m aware, this is still required. Lastly I have some redirects in there too.

Node.js

Eleventy is written in JavaScript and running it requires Node.js, both locally and in production. The minimum Node.js version is set in a .nvmrc configuration file. I do it this way because that’s how it’s done in the Eleventy Base Blog. I’m happy to follow that to avoid confusion when doing future 11ty upgrades, and it also seems sensible to set this value in the project code rather than only in Netlify as the latter could lock me into Netlify and cause confusion in future. Things to remember (from experience) are that this setting in .nvrmc overrides any node version set in Netlify’s Build and deploy settings and also that I should avoid setting a node version in netlify.toml too otherwise they fight with each other.

Readable time

I created this Eleventy filter to show “time of post” on posts of type note. That’s a situation where the readableDate filter included with the Eleventy starter blog wasn’t precise enough.

Tags

When I create a post I apply relevant tags to it. The tag post is applied automatically to all posts. And when I create a note using my custom Decap note template it also applies tag note. (I should do the same for entry and bookmark). But aside from those special tags, I apply tag names arbitrarily.

Each post page shows its associated tags (as links) at the bottom. Each post shows beside its title the “most notable” tag. (Currently it just grabs the third tag since the first tag should automatically be post and in second place should be note, entry or bookmark).

And I have the following tag-related pages and templates:

• an all tags page
• a template for each tag that generates a page listing all posts tagged with that tag

Actions I’ve realised I can take

• rename eleventy.js to eleventy.config.js like in the Eleventy base blog
• …

To be continued!

Update 15-08-24

I added Decap CMS.

Update 30-06-24

I’ve addressed the “a means of contacting me” item on my wants list by adding a contact form using Netlify forms.

Update 39-12-24

I recently removed a bunch of features and pages that had gone stale and only served to make my website harder to maintain.

• Photos section, including an 11ty JavaScript data file where I fetched photos from Cloudinary using an 11ty
• Bookshelf
• Inspiration page
• Records for sale page and data file
• Forestry CMS stuff
• Bookmarker script and lambda folder
• DIY search feature
• JavaScript patch for CSS’s min() for grids, since that now has wide browser support

This was a great watch. Big Zuu (Zubair Hassan) approached his pilgrimage with good humour, curiosity and genenrosity. And I learned lots from it about Islam in general and muslim men and their friendships in particular.

Chef and rapper Big Zuu makes a pilgrimage to Mecca on a personal spiritual journey to try and understand more about his faith and what it means to be 'a good Muslim'.

I really liked some of the contradictory things Big Zuu tried to reconcile. For example could he be a good mulsim but also enjoy some western ways such as alcohol? How would he feel being in Saudi Arabia (Jeddah and Mecca) in light of negative way the region is stereotyped? And is the fee of nearly £8000 paid to the Saudi government the best place to use his money?

In the end there’s a nice theme where Zuu say he’s not perfect nor will he become so… but that understanding his faith is part of striving to become the best version of himself.

David’s template provides not just the starter component code but also a nice readme, issue template, and publish-to-NPM flow.

It’s also always interesting to see how different developers structure their web component JavaScript. David’s code includes a neat and interesting approach to registering the comoponent, and favours setup being written in the connectedCallback().

Here are a couple of his real web components which started from the template:

• link-peek (really nice and here’s David’s corresponding explainer)
• mastodon-post (explainer)

Incidentally, I noticed the comment querying where event listeners should go and referencing Hawk Ticehurst’s article You're (probably) using connectedCallback wrong. While their seems to be a degree of validity there, I’m not going to sweat it. I’ve checked Keith Cirkel’s advice on this, which is:

If your component has additional set up logic, like adding event listeners, then the constructor() isn't the best place for that - as the Web Component isn't yet inserted into (or connected) to a DOM tree, and so it won't have a parent. For that, you'll need a lifecycle callback.

I note that even Hawk Ticehurst isn’t 100% sure about the constructor approach.

So I’m gonna go with putting event listeners in callbacks per Keith and David’s approach.

Martin introduces the “Now” page concept and how he adapted it for showing on his homepage.

I quite like the Now concept in general and have already starting tinkering with it. I also really like Martin’s neat, front matter-free solution in Eleventy (single config file plus date-oriented filenames) and could see that being more widely reusable for me for other “light-touch, non-page collections”.

Hard to argue with Brad’s logic.

Right now, vast numbers of human beings are devoting their time and energy to designing, building, documenting, and maintaining the exact same set of common components.

Our efforts to reduce duplicative work at the individual level are resulting in duplicative work at the inter-organization level.

A Global Design System would improve the quality and accessibility of the world’s web experiences, save the world’s web designers and developers millions of hours, and make better use of our collective human potential.

A Global Design System would exist as a standalone library of components that consumers would pull into their projects, style to match their brand/visual language, and integrate into their application’s business logic. Not only would this be far more efficient than having to design, build, test, deploy, and integrate bespoke components from scratch, a Global Design System would give teams added confidence that the components are sturdy and reliable.

Adrian recommends that we underline links in body copy and provides a host of evidence and rationale to back that up.

WCAG guidelines tell us to make sure we do not rely on color alone to distinguish links and even explicitly suggest underlines.

Usability researchers and practitioners generally suggest that underlines are the most clear way to indicate a link that lives within content.

Academic researchers confirm that … when you have them you can reduce additional cognitive load by making them apparent. Underlines performed well.

There are other sites on the web which have set expectations, but many of them likely do not correspond directly to your own circumstance. Additionally, some of them are already violating WCAG, which removes them from consideration as appropriate analogues.

Other styling options can work, but they are not necessarily universal, sometimes requiring users to learn them. They may also conflict with other styles on your site, increasing the effort (cost) for you to come up with usable, novel and progressive indicators.

Given all these factors, I recommend you underline links in your body content.

Here’s Eric Bailey with some very relatable thoughts on the need to tell design system stories even though it’s difficult.

The component works. And because it works, nobody pays attention to it.

This is the promise of a design system made manifest: Consistent, quality experiences for complicated interactions, distributed at scale with minimal fuss.

This is objectively great. The problem, however, is how we talk, or fail to talk about this type of success.

A lack of bug reports, accessibility issues, design tweaks, etc. are all objectively great, but there are no easy datapoints you can measure here. By this, I mean it is difficult to quantify a void.

Eric advices crafting stories about the important aspects of design system work that are not directly about components:

• Identifying and collecting various ways to weave compelling narratives about the invisible, successful work you’ve done, and then
• Putting those stories in front of the people who need to know them.

At work we are currently working on that very thing as part of a communication strategy.

Sidenote: Eric frames all this in the context of a Data table component he recently worked on for GitHub. It looks good! This is also highly relatable, because I built one of these a few years back, too, and know how much work is involved.

The FT’s design system Origami not only has a cool name but also some interesting metrics.

Community engagement: We are measuring how many people attend our design system guild meetings. While not a goal in itself, we need an engaged community to help us make the right decisions, and an engaged community is also a sign that we’re solving problems that people want solved!

This is a wonderful guide that’s choc-full of practical examples.

CSS container queries help us to write a truly fluid components that change based on their container size. In the next few years, we’ll see less media queries and more container queries.

Lots of inspiration here for when I start using Container Queries in earnest.

Question: when presenting users with a means of downloading a file, should you use the anchor element or the button element?

Answer: you should use the anchor element.

Eric starts by quoting accessibility expert Scott O’Hara to explain why anchor is the appropriate element:

The debate about whether a button or link should be used to download a file is a bit silly, as the whole purpose of a link has always been to download content. HTML is a file, and like all other files, it needs to be retrieved from a server and downloaded before it can be presented to a user.

The confusion seems to come from developers getting super literal with the “links go places, buttons perform actions.” Yes, that is true, but links don’t actually go anywhere. They retrieve information and download it.

Long story short, the download attribute is unique to anchor links for a reason. download augments the inherent functionality of the link retrieving data. It side steps the attempt to render the file in the browser and instead says, “You know what? I’m just going to save this for later…”

Eric follows up by suggesting that as designers and developers we should make the experience of interacting with a download link as good as possible. To that end:

• Ensure it looks like a link, i.e. underlined. You’re using a link (because it’s semantically appropriate) so now encourage the appropriate perceived affordances via conventional visual design for a link
• Use verb plus noun for the text. For example, Download fonts
• Include the file size (for example 34 MB) to give an indication of the download time
• Consider adding an indicator that the link does something other than take you to another place on your website. A downward-facing arrow is conventional

When asking users for numbers and dates, which HTML form elements should we use?

When asking the user for numeric information it might feel obvious to use the HTML input type meant for that purpose, namely number.

However the UK GDS wrote in 2020 that they had switched to using inputs of type text, with inputmode set to numeric. This was after conducting tests which had revealed a variety of usability and accessibility issues.

In the same article a reader questioned why GDS’s use of text inputs also extended to gathering dates (a subset of numbers) when there is a dedicated input type date for that purpose. GDS answered that there are accessibility and usability problems with browser implementations of <input type"date"> and linked to Hassell Inclusion’s 2019 article on date inputs as evidence.

I love the level of research and detail that the GDS and Hassell articles provide. But the notion of not using the HTML elements meant for the job annoys me. I’m also aware that smart developers like Jeremy Keith note that input type date now has wide browser support and are using it. (Update: it seems Jeremy has found some browser support issues too.)

It’s also worth reiterating that the Hassell article is from 2019 and the GDS one from 2020, and four or five years is a long time in browser support.

So what should we do, and how should we make the decision? I’m gonna circle back to this and update it with some answers soon, once I’ve worked them out.

Scott proposes an interview question relating to web standards and intelligent use of JavaScript.

How would you attempt to build Wordle (...or some other complex app) if you could only use HTML and CSS? Which features of that app would make more sense to build with JavaScript than with other technologies? And, can you imagine a change or addition to the HTML or CSS standard that could make any of those features more straight-forward to build?

Discussing any approaches to this challenge will reveal the candidate's broad knowledge of web standards–including new and emerging HTML and CSS features–and as a huge benefit, it would help select for the type of folks who are best suited to lead us out of the JavaScript over-reliance problems that are holding back the web today.

I hate interviews (and the mere thought of interviews), but I could handle being asked a question like this.

Just had a memorable midweek night at the cinema with Craig and Jason.

Opus presents Ryuichi Sakamato at the piano in the final year of his life. It consists of him playing twenty pieces one after the other and is beautifully shot in black and white by his son, Neo Sora.

I found the film’s style and starkness to be quite unusual at first, but once I got into its rhythm it was very immersive. The music and playing were at times just mesmerising and given the circumstances it was quite moving.

It was great to unexpectedly bump into Liam, too. I might have known this film would be up his strasse!

This was an interesting read, recommended by some experienced players at my table tennis club. (The book focuses on tennis but most of it is transferable). This tip came at a good time, as I’m looking to reduce tension from my game.

The author presents the following ideas:

You have two selves. Self 1 is your ego. Self 2 is your body and unconscious brain/memory.

Tension with negative impact comes from trying and overthinking – characteristics of Self 1. Let’s avoid this.

Self 2 is amazing. Let it do its thing without ego interference. Don’t “try hard”.

Observe what’s happening during a game without attributing good or bad, criticism or praise.

Learn to concentrate and still the mind. One method is to focus on the ball, both visually and on sonic rhythm. In between points when those aren’t available, just notice your breathing (without trying to breath differently).

During training or before matches, program self 2. This involves visualising (without verbal instructing) a stroke as I want to play it, then let it happen.

When programming Self 2 you can program for:

• results: (visualise the ball arcing over net and onto other side); or
• form: shadow the stroke inc proper start and finish position. Pause and store the visual. Shut eyes and imagine the visual. Do it again and notice how it feels. Then play but don’t “ask” Self 2 to do it, let it happen. Or
• identity: in training pretend I’m an actor playing the role of, say, Timo Boll. Don’t worry about the ball going out. Just play like them and go for it.

Without ego interference, Self 2 will automatically correct things so that the results match the programming.

It occurred to that I could try this programming for some of the harder techniques such as the reverse pendulum serve.

The writing style of this book felt a bit dated (it was written in the seventies so it’s perhaps understandable). However the ideas are really interesting and I’ve been trying things out in training, with some success so far.

Here are a bunch of great tips and resources for creating charts and graphs, condensed into a 6-minute read.

It’d be interesting to look at the key recommendations in this article and compare our web-based charts at work against them.

My thanks to Vitaly and the Smashing team for this roundup.

This retelling of an incredible story featuring unbelievable examples of human skill, endurance and hope is the best TV programme I’ve watched in years.

Chronicling the story that transfixed the world in 2018 – the daring rescue of 12 boys and their coach from deep inside a flooded cave in northern Thailand. This film shines a light on the high-risk world of cave diving, the astounding courage and compassion of the rescuers and the shared humanity of an international community that united to save the boys.

Growing up, I recall my Dad often used the old Scots phrase mony a mickle maks a muckle and I’ve always loved it. It’s about the value of taking care of the little things because if you keep it up you get something bigger.

It’s true, and here’s a good example. Over the last six months I’ve made lots of small changes to my life and I’m feeling an overall benefit.

Where I started

It’s useful for me to reflect on what was happening in my life last year. Although there was no particular emergency there were a number of lower-level flags.

I’d taken days off work for stress and mental fatigue triggered by aspects of my job. I often became frustrated by work.

I was pretty obsessive – work projects, web trends, supposedly fun hobbies – you name it. My OCD-like symptoms lead to paralysis and were mentally draining.

My life felt disorganised; cluttered and messy.

I suffered bouts of low mood which affected aspects of personal and home life. I felt tired and disconnected.

I was getting my priorities wrong which wasn’t fair on those closest to me.

During and after lockdown, partly as a result of working from home, I’d developed bad habits. I often stayed up late then struggled to get up, with knock-on effects for the rest of my day. I would only just start work on time each day but without having eaten properly. I would dress lazily due to lack of time and organisation.

I was overweight, and probably drinking a little more than I should when socialising.

This collection of issues had snowballed into a general malaise.

It was while on holiday last August with a chance to reflect that I started making changes.

Eating better

Clair told me about scientist and author Tim Spector’s ideas about diet, avoiding harmful blood sugar spikes, and gut health. Until then I’d thought it was relatively healthy to drink a glass of Tropicana every morning, and did so for years. Upon learning the short and long term sugar-related impacts I decided to cut this out completely… and have stuck to it.

I was pleasantly surprised by Tim’s advice that coffee is good for you! So I now have no OJ but two strong black-ish coffees (minus sugar) with breakfast.

Food-wise I now tend to make a breakfast of eggs with seeded toast on days when I’m working from home. I’ll combine that with oily fish like mackerel. Along with my coffee it’s so tasty – I love it! And it really fuels me for the morning ahead. I still sometimes eat granola but have cut back on the amount and the sugary varieties, introducing more nuts, seeds and proper yoghurt.

Action first (thing)

I used to hit the snooze button on my alarm clock every morning – a terrible habit. It made me late which is a bad start to the day. Worse still, appparently the start-stop-start action also plays badly with your brain and your chances of productivity that day.

Listening to Mel Robbins who espouses the “action first” mantra gave me a nudge to exert some control over the impulse and change the bad habit.

Since deciding to stop hitting the snooze button several months back, I’ve got up straight away every single day. I’ve surprised myself!

It’s a small but mighty change, this one, which feels less about alarm clocks and more generally about better self-awareness and decision-making.

And since it gets me up earlier I often have an opportunity for a few press-ups and sit-ups too, helping keep me in better shape.

Self-respect

I realised that although in years gone by I dressed smartly for work, I had drifted into lazier habits. I think it was partly a legacy of the Covid situation and home-working becoming the norm… although also symptomatic of having less energy. I’d do the morning dog walk and stay in the same clothes, or generally just default to a hoody. Dressing like this for work even when working from home didn’t make make me feel particularly good.

I should say that I think people should dress how they like; if they’re comfortable and happy, great. And I like that my employer provides that freedom. But equally I’ve always admired people who dress well. And I know I personally feel happier and more confident when I make an effort.

So I started to better organise and look after my clothes. I retired some old stuff and bought a few new things. I earmarked some work outfits so I’d look more put-together, less thrown-together. I started to choose and lay out clothes the night before work, as a wee courtesy to my future self.

The overall effect is that I feel I’m now showing myself (and the day ahead) a bit more respect.

Taking sleep seriously

In order to have enough pre-work time for a decent dog-walk and to eat well, I needed an earlier start. And to avoid that urge to snooze the alarm I needed to be well rested.

So I started going to bed for 10pm. I stopped taking my phone into the bedroom. I allowed twenty minutes reading time because it helps my brain wind down naturally.

This particular change has been brilliant and really impactful.

I’ll admit that, as a night owl, it’s a tough one to sustain. Recently I’ve noticed a couple of old habits creeping back in, for example messing about on the internet ‘til late, or taking my laptop (rather than my phone) into bed. But I quickly recognised these were happening, that they’re not conducive to a good night’s sleep, and am working on quitting those too.

A happier workspace

In winter 2023, Harry Roberts posted an image of his new workspace. It struck me how lean and clean it looked and how that clutter-free environment must be doing wonders for his state of mind at work. So I made some changes to my own. It didn’t take long and it’s now a small source of joy each home-working day.

Acknowledging mental health and talking about it

By December 2023 I had already started making a few small changes but there was a bigger fish to fry. The ocurrences of low mood, brought on by work-induced stress or anxiety over other apparent issues, were too frequent to ignore. It wasn’t good for me or anyone.

Clair encouraged me to talk to someone. I agreed, which strangely felt like a small win in itself.

In early 2024 I had a short but productive session with a mental health consultant arranged through a work benefit. I didn’t know what to expect, but the consultant allowed me to talk about frustration, mental fatigue and a sense of disconnection. She encouraged me to reflect on what things gave or sapped energy, and to define my values so that I can ensure to do things that support them.

She also recommended that I read Lost Connections and this was really beneficial in helping me understand what was ailing me and how to go about reconnecting.

Taking care

One thing I’m sure does me no favours is a tendency when socialising to have a few drinks too many. It has various downsides but two of the worst are that it would make me pretty sad and that it would sap my energy to do things.

To address this I’ve been shifting my attitude.

When socialising, drinking alcohol shouldn’t be the default. Doing it on 50% of ocassions would be more sensible.

I’ve been normalising drinking non-alcoholic beers (which most venues sell) either all night, at the start or interspersed.

I’ve been planning the night in advance – how and when I’ll get there, when I’ll eat, what time I should leave and how I’ll get home. This really helps avoid the night going off the rails unnecessarily.

I’ve been gently leaning on close friends to help encourage me in the right rather than wrong directions.

This is a hard one. I’ve long used alcohol for dutch courage and old habits die hard. I live in the west of scotland where it’s part of the culture.

But so far, I’ve been doing pretty well. I think the key for me is to be a bit more planned about things when I’m socialising. That tends to trigger the right thoughts and guardrails. It also helps to think about the real social reason why I’m going out, which helps me realise that it’s more than enough and I don’t need more.

Reconnecting with what’s important

I’ve been making more effort to see and keep up with my (large) family.

I’ve been taking every opportunity to catch up with friends.

Let’s be honest – doing this is a pleasure. I’m lucky to have amazing people in my life. But it’s weird how you can lose your way. In my case, I realise that I previously filled up my bandwidth with other stuff. Not only did this suck time and energy, it led to stress and social anxiety.

Seeing friends and family, and hearing all their news, is a tonic.

So far, so good

This year, 2024, has felt really positive so far. I think those small changes have really helped. My state of mind is good and furthermore I feel like I’m generally putting some better vibes out there. I’m gonna do my best to keep this good thing going!

Thanks for reading. I know that some of the issues that affected me (and I’m still working on) affect others too. If you ever want to talk about it, just shout. It’ll probably be good for both of us.

When chatting with a consellor in January about some bouts of low mood and mental fatigue, I described one symptom as a strange sense of disconnection. And while the recent lockdowns during the pandemic were obvious contributors to that, they didn’t feel like the full story.

Reassuringly it seems I’m far from alone in feeling this way, since one of her suggestions was to read Johann Hari’s bestselling book Lost Connections: why you’re depressed and how to find hope.

Hari argues that the primary factors causing depression and anxiety are environmental and societal – not the “chemical imbalance” nor the pill-based solution story we’ve been sold for so long.

Hari frames depression and anxiety as natural reactions to and signifiers of an imbalance caused by unmet human psychological needs. The modern world can be lonely and runs on dubious values. We need community, meaningful values, interaction with the natural world, a sense of worth and being respected, a secure future, and release from any shame resulting from previous mistreatment.

On the whole I really enjoyed this book – well, as much as you can enjoy a book about depression!

Pitchfork’s review of Jeff Mills’ seminal mixtape is the best-written and most enjoyable music article I’ve read in years. The mixtape in question is also very close to my heart.

this is a mix without equal, the Techno Bible, unequivocally The One.

Then, as now, Liquid Room stands as a high-water mark of a Black artform built around space travel and the necessity of forward motion: ’90s techno at its most unyielding and free.

Agreed! Fun fact: in 1996, having played the shit out of my cassette copy for a few months, I went to see Jeff DJ at the Arena in Glasgow in 1996 and he signed the inlay! I would normally be embarassed at having done this… but not in this case.

Whitney Lewis covers four accessibility considerations for implementing forms: autofill, error messaging, date fields and auto-formatting fields.

I found the explanatations of the autocomplete attribute and the section on an accessible error message pattern particularly useful. The latter part felt similar to the good advice Adam Silver gives in his book Form Design Patterns.

Last weekend was pretty dull and rainy in Glasgow but Clair and I visited a bunch of great local places to keep the spirits up.

On Friday night we ate at Wasabi for the first time. It’s a lovely little spot on Pollokshaws Road with a nicely-sized menu. Between us we had Chicken Karage, Avocado Maki, King Prawn Tempura and Beef Ramen. We loved it and will be back.

On Saturday early afternoon we took Rudy for a walk around Pollokshields including Maxwell Park. We were then able to leave him nicely tired and chillin’, and headed to the FONDS exhibition at the Tramway.

Next was a visit to Pisces although we were runnning a bit early so stopped for a drink at Heraghty’s. Tom and Nessa have been telling me they do a good pint of Guinness so I gave it a try.

At Pisces (which was once the site of the legendary Greek Golden Kebab) we both tried the Smash burger and fries, and it was pretty tasty.

We’d hoped to visit the ‘hood’s latest cafe, bar and restaurant Henry’s for a nightcap, but on arrival there it was jam-packed so we resolved to come back another time.

Prior to Christmas we’d been talking about giving ourselves the present of a trip to London. However the train prices were pretty offensive so we opted for a different type of weekend trip – one that was rural, cosy and Rudy-friendly.

Friday’s check-in wasn’t til 4pm so we started with a drive to North Berwick. There, we visited the Lobster Shack. Clair had fish and chips while I had seafood chowder (which Clair admitted was the pick of the dishes). The weather was of the good January sort – chilly but sunny so we had a wee stroll along the beach and let Rudy have a run.

Charlton Gate cottage was perfect. We were in splended isolation, except for the neighbouring sheep and grouse. The cottage itself was comfortable with all the cooking and telly-watching facilities you’d need, plus a comfy bed.

On Saturday we visited Newbiggin-by-the-sea for more beach-walking fun.

Later that day we also paid a brief visit to Morpeth, which is a lovely town.

I really enjoyed my morning walks with Rudy. It was so peaceful and the sky and scenery were beautiful.

Thanks as always to my fam Clair and Rudy for a beautiful weekend.

I just deactivated my Twitter (X) account. Within the wider current context of other small, positive changes I’m making, it feels like the time is right.

I gave it a little thought, but not much. There were plenty of reasons to deactivate (for my own good and because X under Elon is x-crutiating) and not many good reasons to stay.

I used their download your archive feature before deactivating.

I guess I might lose a bit of touch with some web and music folks but I’m sure I’ll catch up with them in other ways.

And I s’ppose someone might try to get in touch via Twitter and find I’m no longer there, but if they want to find me online, I’m sure they will.

One less avenue for procrastination!

I’m starting 2024 as I mean to continue – by seeing and hanging out with friends more often. Yesterday Tom and I had a great day moseying around Edinburgh.

After meeting at Waverley and grabbing a quick coffee and bite, we headed to the Scottish National Gallery on The Mound. Tom was keen to see the Turner watercolours exhibition which is on every January – apparently the ideal time of year to best show off the works. I probably wouldn’t have visited this unprompted but I’m glad I did. My favourites were perhaps The Falls of Clyde and Lake Albano.

From there we made the short walk to Cockburn Street and into an old haunt, Underground Solush’n, for some record shopping. I got a few, with the pick being the album Flying Wig by Devendra Banhart.

Next stop was St Andrew’s Square for a saunter around the menswear floor in Harvey Nichols. Neither of us were in the market for anything in particular but still it was nice to browse their sale including coats by Copenhagen-based brand NN.07 as sported by Jeremy Allen White in The Bear.

We hopped on an Edinburgh tram outside (first time for both of us) headed for Port of Leith. We caught the Leith Saturday market where Tom was beguiled by a purveyor of exotic olive oil (I can't believe I'm typing this) before we stumbled upon a great wee record stall. To my surprise it wasn’t just the usual selection of records no-one wants but instead had plenty of gems. I picked up two LPs from my wishlist – Vangelis's Earth (featuring the glorious Let it happen) and Spacek’s Curvatia.

All that record shopping gives you an appetite so it was off to Teuchter’s Landing for some food and refreshments. With Burns Night just around the corner we honoured the bard by enjoying haggis, neeps and tatties and a dram (Craigellachie 13y).

Our final stop was the Shore Bar where we caught up with a couple of Edinburgh-dwelling pals, Gav and Nick.

After all that I was back on the train home by around 10 pm – mission accomplished.

My generous nieces and nephews clubbed together to give us the Christmas present of a voucher for Ox and Finch. Keen to use it, we got together with James and Grant for a lovely Sunday dinner.

It’s a “small plates” affair, so sharing is the order of the day. We had sourdough and butter (the bread in good restaurants is always amazing), whipped feta with honey, fried artichokes with garlic yoghurt, and – my two favourites – the crab tubetti and beef tartare. To drink I had a white wine – the ‘le campuget’ grenache viognier – then their px old fashioned (the px standing for pedro ximénez).

We also shared the warm ginger cake with poached pear, while James had the affogato.

It was fantastic and – thanks to that thoughful gift – didn’t cost us a penny. What a great Christmas present.

At work today I mentioned Mr Scruff’s tip for quick tea-making. My teammates laughed and said they felt like they were on an episode of Would I lie to you? I had to prove I wasn’t talking rubbish and went looking for the tip online. It has all but disappeared from the web but thanks to Wayback Machine I was able to find a cache of the page from 2007.

So here is the tea-making tip, listed in full for posteri-tea! (Sorry…)

Mr Scruff starts by saying:

Some people ask me about the teabag on a spoon technique, which I learnt from Peter Parker of Fingathing. Here is the full breakdown of the method for making black tea in a mug with a teabag.

And here are the steps:

1. Boil the kettle with fresh water… no reboiling!
2. Warm the mug… you can do this by pouring in a little warm water from the kettle while it is boiling, swishing it around & emptying it. This will help keep your brew warm for longer, essential for forgetful types like myself!
3. Pour milk into the cup. If this offends you, you can add it later.
4. Take a spoon (tablespoons are best, but a teaspoon will do)
5. Place the teabag on the spoon, and hold it horizontally over the mug.
6. When the kettle has boiled, hold it over the teabag, and pour as slowly as possible from as high as possible, without making the water splash upwards off the teabag. If you are doing this correctly, you will see little bubbles in the teabag, which is a sign of the oxygen in the boiling water doing its job.
7. When the cup is full, add the milk if you have not done so, and examine your brew. If your tea is the correct colour (mine is a kind of brick red/malty brown) then you can discard the teabag. If it is not strong enough for your taste, then delicately lower the teabag onto the top of the tea, and slip the spoon out from under it. Leave it there until the brew is strong enough, and gently remove the bag with the spoon. There is no need to stir the bag or squash it in any way..tease the flavour out!
8. Add sugar/salt/cheese/pickle to taste.
9. Sit down and enjoy your brew!
10. Repeat from stage 1.

Cheers!

PS if you don’t already know Mr Scruff I heartily recommend getting acquainted.

How was 2023 for you? For me, it was like this.

Music gigs

In welcome contrast to the Covid years I went to a variety of in-person events, including seven gigs:

• Apiento in London,
• Melting Pot at Queen’s Park Rec (where I saw Luke Una and Odyssey),
• Melting Pot vs Let’s Go Way Back at BAAD,
• Om Unit at Sleazy’s,
• Robert Henke at Tramway,
• A Certain Ratio at Stereo in November, and
• Sleaford Mods in December.

Of those, my highlights were definitely Robert Henke and A Certain Ratio.

Music buying, listening and playing

I’m still buying music on vinyl and more, albeit at a slightly reduced rate. My taste continues to shift organically and I really enjoy exploring. My highlights included Skinshape’s Craterellus Tubaeformis, A Certain Ratio’s 1982 and Jamma-Dee’s Perceptions.

I recorded three radio shows and was pretty pleased with them, on the whole.

Seeing friends

My April trip to London with Tom was a real highlight of the year. We went record and clothes shopping, caught up with friends, listened to great music in brilliant venues, and enjoyed some lovely food and drinks. If Carlsberg did weekends, they’d struggle to top that one.

There were lots of other fun get-togethers.

When I look back, I realise that I’ve done not too badly at keeping in touch with friends in 2023. Obviously there are those that I saw too rarely or not at all, and I’ll try to rectify that in the new year.

One sadder entry: in late August, my close pal Simon’s mum died. It was a beautiful ceremony for an inspirational lady.

Travel

Abroad

I travelled to six different countries, if you include England.

First stop was Amsterdam in June for work: I attended the CSS Day conference for the second year running.

Also in June. Clair and I went to Sicily for Fiona’s 40th birthday, staying in Palermo then Taormina.

In August Clair and I enjoyed ten days in Geneva and Annecy.

In November I took my parents for a week in Marbella.

In Scotland

I enjoyed a couple of trips around Scotland.

There was our March weekend at Banchory Farm in Fife.

Then in July I had an overnight stay in Alyth.

Eating out

While in London, Tom and I enjoyed a nice breakfast at Fallow on Clair’s recommendation. (Although she was subsequently horrified at me missing the foodie opportunity by only ordering scrambled eggs on toast! My excuse is I was hungover and needed comfort food). On the same trip we had amazing sushi at Brilliant Corners in Dalston. It really is my happy place.

In Spring, Clair and I had an overdue catchup with Charlie over a lovely lunch at Inver.

I made a first visit to Dishoom in Edinburgh, alongside two good pals, and it lived up to the hype.

In autumn I enjoyed a lovely Saturday afternoon at Crabshakk on Byres Road with Gillian, Tom and Nessa.

On Hogmanay, Clair and I ate at Brett and loved it.

Special mention has to go to our evening at Café du Soleil in Geneva where we both had our first taste of fondue. Cheese heaven.

Family

All the major family-related activity seemed to happen in June. Sadly, my Aunt Elsie died. She was in her nineties and the last ten years had seen a steep decline.

On a happier note my niece Caitlin married her partner Ross in June in a beautiful wedding at Lochside House Hotel.

My niece Charlotte had her second child – Mason, a brother for Marc.

That eventful June aside, everything seems to be ticking along. My mum and dad are well. Clair had a challenging year with work, but the work she does is brilliant and with fantastic clients. She’s generally doing well and happy in her new fitness groove, which makes me happy too.

Rudy, our nervous border terrier, has been a mixed bag behaviour-wise, but mostly good. There are lots of signs of improvement. And regardless of the behavioural issues he is just a wee legend who’s full of love and we adore him.

Books

It wasn’t a productive year for reading; I just couldn’t find the motivation. Still, I read a few.

• Possibilities, Herbie Hancock’s autobiography
• Open, Andre Agassi’s autobiography
• Join the Future
• The Islander

And I started The Candy House.

The good news is that they are all great, and recommended.

Films

Of note were Aftersun and Oppenheimer, the latter of which I saw at the GFT in July.

I also saw Captain Fantastic which isn’t new but is… fantastic!

Other arts

In January we visited the Tramway theatre and checked out two exhibitions. The first was a selection of works by Glasgow artist Norman Gilbert, and the second the installation The Rumble of a Tireless Land by Iza Tarasewicz.

In July I went to Banksy’s Cut and run exhibition at the GOMA, which I loved. Later that month I saw the excellent Moorcroft at the Tron theatre.

In September I went to the Armadillo to see the updated version of The Celtic Story with Marty and Michael (with thanks to Gillian for the tickets). I had first seen this thirty years previous and it was nice to revisit the club’s history.

TV

Back in January I loved Mystery Road – Origin.

Later in the year, the Succession finale really lived up to its billing – a fitting end to a brilliant show.

Latterly I really enjoyed Mr Inbetween. Scott Ryan, the lead, is a talent.

Other noteworthy stuff

I learned to make coffee from whole beans.

I’ve been learning Spanish, using Language Transfer’s course and am enjoying that.

Work

I’m lucky – I have a good job with great benefits. I work with smart and lovely people. Even still, me and my job don’t always see eye to eye.

In the positive column for 2023:

• our team was instrumental in implementing a brand refresh
• we made material progress in promoting company-wide accessible practices
• I began learning how to write documentation more formally, and we have made strides on that front
• at scoring I seem to be progressing and had some nice feedback
• I’m trying to get better at empowering others. I’m having some success but have lots of room for improvement
• I went to three inspiring conferences: CSS Day, Design Systems Day in Edinburgh, and my employer’s own internal staff conference which was excellent.

In the negative column:

• I had at least one mental blowout. It was caused by thinking too deeply about a complex and frustrating area. It left me in pretty bad shape mentally, and needing time off.
• latterly I lost energy and focus. I couldn’t find energy to read the various articles I receive by subscription, nor write on my blog. This marked a change for me – I’m usually pretty motivated in that regard.

Health

My physical health was fine. I’m doing enough exercise to keep my weight in check. I can’t remember being ill very often, although being stuck in bed with the cold on my birthday was no fun. I could always be fitter but generally speaking I’m physically fit and well.

A couple of small but impactful changes of note: after Clair told me about Tim Spector and how we shoud avoid spiking our blood sugar, I cut out the large glass of Tropicana orange juice I drank daily for years. I also cut down the amount of granola I eat at breakfast and swapped in nuts and seeds, or a breakfast of brown toast and eggs. This is no doubt having a positive impact on my weight but also, I hope, keeping me healthier long-term. On a similar note, I now try hard to go to sleep earlier and avoid feeling the need to snooze the alarm.

As for mood and mental stability, that’s less straightforward. Firstly I’ve noticed changes to preferences and comfort zones. There are situations I used to enjoy – such as larger gatherings – and now don’t. Generally I’m OK with this. It could be a post-pandemic effect, or a symptom of ageing. Regardless it feels natural so I’m adapting. As long as I find time to see the important people in my life one way or another, it’s fine.

More concerning were the too-regular occurences of low mood, low energy, frustration and mental fatigue. Working on a Design System team can feel overwhelming or futile or both. Working primarily from home saves time and money but can feel claustrophobic, and mixes parts of life that should be separate. I also generally find too many things vying for my attention and struggle to focus. A big, noticeable change is that my mental resilience isn’t what it was.

While low mood has a significant negative impact on me, it can impact others too. At times I’ve struggled to see the bigger picture and dropped the ball, forgetting people I should prioritise.

In summary my mental health wasn’t always great and it was time to acknowledge that properly. Since then I’ve done this and I feel better for it. There’s a journey ahead. Maybe I’ll write about it more soon.

Let’s go round again

So long, 2023 – you were mostly pretty good and I’m grateful. Even the bad bits have given me helpful pause for thought. I’ve been making positive change already, so onwards and upwards.

David cleverly uses CSS alone (and only a few lines) to show a “back to top” link only after the user has started scrolling, then pin its position to the bottom-left of the screen.

The clever margin-top: 110vh combined with position: sticky – since 110vh is slightly more than 100% of the page’s height – gives the link a starting position that is not initially visible but becomes visible once the user starts scrolling. The bottom: 0 then ensures that when the user continues scrolling vertically the link “sticks” to the bottom-left of the page.

So little code and so clever!

PS if you’re wondering why you’d want a “back to top” link in the first place, it’s to let a user who has scrolled far down a long page to easily get back to options located at the top. See NN Group’s Back-to-Top Button Design Guidelines.

Clair and I just rounded off the year in style with lunch and drinks at Bar Brett on Great Western Road. We had a bird’s eye view too, sat overlooking the pass watching the chefs at work.

Between us we enjoyed a variety of small dishes including oysters, sourdough bread with chicken fat butter, cod toast, smoked beetroot with tahini, clams, lobster ravioli, mushroom XO linguine, Peterhead Coley with curried mussel sauce and a Basque cheesecake.

We tried a few glasses of wine: Veiled Vineyards Old Vine Semillon (white), a Delamotte Blanc de Blancs (champagne), and Le Grand A (Burgundy white) – all lovely.

Brett is fantastic and the staff made us feel very welcome.

We just enjoyed a lovely festive visit to Doug and Zoe’s house where we hung out with them and their girls Zara and Nina. As an unexpected bonus our friend Pablo also stopped by.

After the rush and stress of organising Christmas it was just what the doctor ordered. Doug made a delicious and light panzanella salad. I taught Zara how to play hangmam on good ol’ pencil and paper. We enjoyed a chat and a laugh.

Cheers, pals!

Heather explores why we no longer have “web designers”.

It's been belittled and othered away. It's why we've split that web design role into two; now you're either a UX designer and you can sit at that table over there or you're a front-end developer and you can sit at the table with the people that build websites.

Heather makes lots of good points in this post. But the part that resonates most with me is the observation that we have split design and engineering in a way that is dangerous for building proper websites.

We all lost when the web design role was split in two.

if our design partners are now at a different table, how do we expect them to acquire the deeply technical knowledge they need to know? The people we task with designing websites, I've found, often have huge gaps in their understanding of… the core concepts of web design.

Heather argues that designers don’t need to learn to code but that “design requires a deep understanding of a subject”. Strong agree!

Likewise, the arrival and evolution of the front-end role such that i) developers are separate from designers; and ii) within developers there’s a further split where the majority lack “front of the front-end” skills has meant that:

We now live in a world where our designers aren't allowed to… acquire the technical design knowledge they need to actually do their job and our engineers never learn about the technical design knowledge that they need to build the thing correctly.

Heather’s post does a great job of articulating the problem. They understandably don’t have the answers, but suggest that firstly education gaps and secondly how companies hire are contributing factors. So changes there could be impactful.

Over the years I’ve seen Herr Henke (of Monolake fame) doing variously-themed live shows and in a variety of locations. I loved this particular show and it was made even better by catching him at The Tramway Theatre, one of my favourite venues and just 10 minutes walk from home.

Here’s a little about CBM 8032 AV in the great man’s own words:

CBM 8032 AV is an exploration of the beauty of simple graphics and sound, using computers from the early 1980’s. Everything presented within the project could have been done already in the 1980, but it needed the cultural backdrop of today to come up with the artistic ideas driving it. On stage are five carefully restored Commodore CBM 8032 computers, running custom software developed by the artist and his team. Three computers create sound, one machine is responsible for the graphics and one is controlling all the others, with their green cathode ray tube displays facing the audience, operated by the artist during the show.

I was there with Tom and Simon. Here’s a little phone recording captured by Tom.

We left in agreement that Robert really is a genius. I’ve always loved his music and he is still doing fresh, inventive and wonderful things.

Additional info:

• Tramway event page for CBM 8032 AV

This is a great one-hour interview and a fantatic insight into John Kennedy’s brief but eventful career – the highs and the crushing lows.

I already liked John Kennedy but after hearing him speak so candidly and well, and getting more of an insight into his “don’t waste a minute” attitude, he’s gone even further up in my estimations.

My folks haven’t managed a holiday outside of Scotland in a long time. So it’s been nice to spend a week together in Spain.

Here we are, just about to board the No. 3 bus to Marbella’s old town.

In this talk at State of the Browser, Amy offers some suggestions for making work feel more meaningful.

Don’t treat work like an end in itself; treat it as a means to the end of fulfilling your purpose.

What are your key skills, experiences and values? Write them down, them summarise how these come together as your “core perspective” or purpose.

Now, we want to find ways to fulfil that purpose, and to do that we can set goals.

When considering candidate goals, ask:

• Does this connect to my purpose?
• Do I actually care about achieving this goal?
• Is this a goal I can actually achieve?
• How will I know if I’m making progress?

This recipe from Gousto, with a few tweaks from Clair, is a straight winner. Although I’m sure it’s delicious as they list it, Clair substituted linguine for rigatoni and as a treat added some artichoke hearts which took it to the next level.

Delicious, and a perfect example of a vegetarian meal where I didn’t miss meat at all.

I’ll have a go at this one myself soon. I think most people would enjoy it!

Here are some recurring development decisions I make when maintaining my personal website/blog, with some accompanying rationale.

Where should landmark-related HTML elements be in the source?

I set one header, one main and one footer element as direct children of the body element.

<body>
  <header>…</header>
  <main>…</main>
  <footer>…</footer>
</body>

This isn’t arbitrary. A header at this level will be treated as a banner landmark. A footer is regarded as the page’s contentinfo landmark. Whereas when they are nested more deeply such as within a “wrapper” div they are not automatically given landmark status. You’d have to bolt-on ARIA attributes. My understanding is that it’s better to use elements with implicit semantics than to bolt on semantics manually.

How should I centre the main content in a way that’s responsive and supports full-width backgrounds?

My hard-learned approach is to use composition rather than try to do everything with “god” layouts.

I mentally break the page up from top to bottom into slices that correspond to logical groups of content and/or parts that need a dedicated full-width background. I give each slice padding on all sides. The lateral padding handily gives you the gutters you need on narrow screens. (You could use a Box layout for these sections. I tend not to consider them to be “true boxes” because usually their lateral padding differs from their vertical padding. So I just apply their styles on a case by case basis.)

Within each section, nest a dedicated Center layout to handle your fluid width-constraining wrappers.

This approach offers the best of all worlds. It doesn’t constrain your markup, which I find useful for achieving appropriate semantics and accessibility. You don’t need to put a “wrapper div” around everything. Instead you can have landmark-related elements as direct children of body, applying padding to those and nesting centred wrappers inside them.

By making proper use of padding, this approach also avoids problems of “collapsing margins” and other margin weirdness that make life difficult when you have sections with background colours. You don’t want to be using vertical margins in situations where “boxes with padding” would be more appropriate. Relatedly, I find that flow (or stack) layouts generally work best within each of your nested wrappers rather than at the top level.

How should I mark up lists of articles?

Should they be a bunch of sibling articles? Should they be in a list element like a ul?

Different switched-on developers tackle this differently, so it’s hard to offer a definitive best approach. Some developers even do it differently across different pages on their own site! Here are some examples in the wild:

• Leonie Watson’s homepage employs a list of article elements with no wrapping list
• Manuel Matuzovic’s homepage does the same as Léonie’s
• Adrian Roselli’s posts page uses the same structure as above whereas Adrian’s homepage uses a ul with no article elements!
• Tetralogical’s blog section employs sibling section elements whereas their news section uses an ol but with nothing special nested inside
• Ethan Marcotte’s journal uses nested lists to group by years then months, with each teaser marked up as an article inside an li

So, clear as mud!

I currently use sibling articles with no wrapping list. Using article elements feel right because each (per MDN’s definition of article) “represents a self-contained composition… intended to be independently distributable or reusable (e.g., in syndication)”. I could be persuaded to wrap these in a list because that would announce to screen reader users upfront that it’s a list of articles and say how many there are. (It tends to make your CSS a tad gnarlier but that’s not the end of the world.)

Should a blog post page be marked up as an article or just using main?

I mark it up as an article for the same reasons as above. That article is nested inside a main because all of my pages have one main element wrapping around the primary, non-repeated content of the page.

To be continued

I’ll add more to this article over time.

The naturalist, TV campaigner and activist on growing up, autism and asking himself “what is the best use of me?”.

He’s such a brilliant, sensitive soul, but it must be hard work being Chris Packham.

Growing up I was never a fan of nature programmes like The Really Wild Show so I didn’t pay Chris Packham too much attention. However in the last few years I've grown really fond of him. That's in part due to his revelations about his punky musical leanings and attitude, but more so due to his candid description of his autism, then his work to bring the true nature of autism and neruodivergency into the public eye and in doing so help others.

He’s also quite inspirational in trying to do the right thing in many ways, despite significant challenges.

This was an enjoyable and insightful interview although some of the parts about his losing beloved animals alongside other dark moments make for tough reading. Still though, I'm now considering reading Fingers in the sparkle jar.

Adam offers tips for how to proceed when we are presented with a request for a shiny new pattern which is not grounded in research but rather follows a fad.

The purpose of design is to solve actual problems. Not made up “I’m bored so I’ll come up with something new” problems.

So how can we evaluate these patterns, avoid unnecessary work and ultimately avoid patterns that degrade UX?

He recommends we should start by asking three questions:

1. Does research show this pattern solves a problem?
2. Are there any potential usability issues with this pattern?
3. How much effort is it to build?

Heather suggests that in developers’ excitement to do cool new stuff and use cool new tools and techniques “we stopped letting people do very normal web things”. Things like:

• the ability to copy text so you can then paste it
• ensuring elements which navigate also behave like normal links by offering standard right-click and keyboard shortcut options etc. Which is to say – please use the anchor element and leave it alone to do its thing
• letting people go back using the back button
• letting people scroll with native scrollbars. Relatedly, letting people get to the links at the bottom of the page rather than having infinite scrolling results which mean that the footer is always just beyond reach!
• letting the user’s browser autocomplete form fields rather than making them type it

An interesting article which helps the author – and his readers – understand some of the lesser-used and more obscure HTML elements.

While Patrick confesses he is still learning certain things and therefore I won’t regard his implementations as gospel in the way I might an article by someone with greater HTML and accessibility expertise such as Adrian Roselli, I see this as another useful resource to help me when deciding whether or not an HTML choice is the semantic and or correct tool for a given situation.

Thanks, Patrick!

I’m interested by Shoelace’s MO as a collection of pre-rolled, customisable web components. The idea is that it lets individuals and teams start building with web components – components that are web-native, framework-agnostic and portable – way more quickly.

I guess it’s a kind of Bootstrap for web components? I’m interested to see how well it’s done, how customisable the components are, and how useful it is in real life. Or if nothing else, I’m interested to see how they built their components!

It’s definitely an interesting idea.

I'll delve into Shoelace in more detail in the future when I have time, but in the meantime I was able to very quickly knock together a codepen that renders a Dropdown instance.

Thanks to Chris Ferdinandi for sharing Shoelace.

This post from earlier this year offers a similar encouraging message to Henny Swan’s recent The only accessibility specialist in the room. It contains advice that’s worth remembering when we have one of those ”what’s the point?’ moments!

Advice like:

• Get started; don't wait until everything is done and perfect
• Small steps make a big difference
• Educate, don't berate
• Think of accessibility as an ongoing journey with no finish line

Nathan on how complex components require comprehensive specifications rather than ill-advised assumptions, and how Figma can be used to guide engineers to reliably build such components.

I’m still amazed when designers schlep together a few pictures, publish a configurable Figma component, point their developer counterparts at the main component and say “Use Figma’s inspect tool.”

Things have changed. Components are more complicated. Designers are delivering to many different developers. Accessibility has risen to the fore. For design systems that scale, teams are finding it necessary to write down all the details again.

At work in our project to improve our component documentation across the component life-cycle, we’ve been following Nathan’s advice and using his plug-in to assist with the “specification” aspect.

Had a great day with Mark and Alan on Saturday climbing Ben Lomond. Although I’m not much of a hill-walker I reckon that’s the third Munro I have bagged.

We were staying overnight at our friend Jim’s family cabin at Rowardennan and it was a short walk from there to the mountain. The start is steep and the weather progressively worsened until the rain was horizontal, but nonetheless we reached the summit (3200 feet above sea level) in around two hours then skipped back down in just one more hour. We were pretty proud of ourselves to complete the walk in just over three hours!

After that we enjoyed steak pie, fish and chips and victory pints at the Rowardennan hotel. A perfect day.

Mind you, over the last couple of days I’ve been feeling pain in muscles I didn’t know existed!

I’ve been:

• reading The Islander by Chris Blackwell and Paul Morley
• watching Oppenheimer on the big screen and The Bear on TV
• listening to 1982 by A Certain Ratio and Matt Wilde’s Hello World
• out to see Moorcroft at the Tron and thinking about it ever since
• enjoying collaborating and socialising with teammates in the office but not loving the commute
• at one wedding (Lou and Tom) and one funeral (Aunt Elsie)
• losing sleep while Rudy goes through a night-whines phase
• starting to re-find some form at table tennis training
• wanting to write regular posts like this – this is the test run!

Something Adrian Roselli said recently has stuck with me. The gist was that when developers need definitive guidance they shouldn’t treat MDN as gospel, but rather refer to the proper specifications for web standards.

Note: this post is a work in progress. I’ll refine it over time.

HTML

The HTML Living Standard

The Edition for Web Developers version looks handy. It seems to be streamlined and you can also use the forward-slash key to jump straight into a search then type something like “popover” to access that specification quickly.

WCAG Accessibility

How to Meet WCAG (Quick Reference)

Adrian referenced the above in one of his blog articles.

ARIA

W3C’s ARIA in HTML document

Adrian will quote or reference this when talking about roles, landmarks and the like… for example when he tweeted about developers using section.

Note: the above resource somewhat confusingly describes itself as a W3C recommendation. But despite that naming it should be regarded as definitive guidance. That description links to an explainer of W3C recommendation confirming that these are specifications which have been endorsed by W3C, that software manufacturers should implement, and that may be cited as W3C standards. My understanding is that if a specification is at an earlier stage it will be described as a W3C proposed recommendation.

Miscellaneous notes

How useful is MDN? I’ve read before that it’s not definitive. But it has recently had some good people work to improve its references to accessibility

MDN typically references WHATWG HTML, which often gets accessibility… well, not quite right. Part of my efforts included updating the accessibility content to point to the W3C specs wherever appropriate.

Adrian tests how blockquotes, marked up in a variety of ways, are announced in different screen readers.

He concludes that his personal choice is as follows:

<main>
  <!-- other content -->
  <blockquote>
    <p>A common mistake that people make when trying to design something completely foolproof is to underestimate the ingenuity of complete fools.</p>
    <footer>— <cite>Douglas Adams, <a href="https://en.wikipedia.org/wiki/Mostly_Harmless">Mostly Harmless</a></cite></footer>
  </blockquote>
  <!-- other content -->
</main>

He avoids the cite attribute completely because it creates noise in JAWS, and recommends against using figure with figcaption because it results in unnecessarily verbose and duplicate announcements.

In his chosen approach the footer is used mainly as a sensible styling hook, since in the context of a main (as opposed to as a direct child of body) it is not regarded a landmark and is strictly presentational. The cite element has semantic intent – it’s the element for marking up the title of a cited creative work – even if those semantics are not always exposed to users.

So there’s an action for my team at work, because our blockquote component currently uses figure and figcaption. Perhaps at the time of build we took advice from one of the MDN or W3C pages which Adrian has now shown weren’t ideal.

There’s a great section on Source order and layers in Every Layout’s Imposter layout. It’s a reminder that when needing to layer one element on top of the other you should:

1. favour a modern layout approach such as CSS Grid over absolute positioning; and
2. not apply z-index unless it’s necessary.

which elements appear over which is, by default, a question of source order. That is: if two elements share the same space, the one that appears above the other will be the one that comes last in the source.

z-index is only necessary where you want to layer positioned elements irrespective of their source order. It’s another kind of override, and should be avoided wherever possible.

An arms race of escalating z-index values is often cited as one of those irritating but necessary things you have to deal with using CSS. I rarely have z-index problems, because I rarely use positioning, and I’m mindful of source order when I do.

In web-based products from e-commerce stores to email clients to accounting software you often find index pages where each item in a list (or row in a table) has a Delete option. This is often coded as a link… but it shouldn’t be.

I liked this comment by Rails developer Dan where he advises a fellow Rails developer that to create his Delete control he should use a form rather than a link, via Rails’s button_to method.

Dan mentions that in the past Rails UJS set an unsdesirable historical precedent by including a pattern of hijacking links for non-GET reqests.

But per the HTML standard, links are for navigation:

Hyperlinks… are links to other resources that… cause the user agent to navigate to those resources, e.g. to visit them in a browser or download them.

And as Dan goes on to say that’s why links make a GET request.

A GET request is a visit, it says “show me this” and it’s idempotent. When you make the same request it’ll show the same thing.

If on the other hand you want a control that performs an action (in this case request an entity to be deleted) then the appropriate HTML element is usually a button, and in this case a submit button within a form.

Relatedly, Jeremy Keith previously wrote about how to use request methods properly in his excellent post Get safe.

Love Matt Wilde’s music and his new LP Hello World is even better than expected. Beautiful laid-back and understated vibe from start to finish. Lovely artwork too.

Cheers also to Band on the Wall recordings for the surprise tote bag!

I really like Jim’s idea of putting an avatar file somewhere that’s memorable and easy to access by me wherever I am and that also (in the future) might be automatically grabbable by any platform that needs my avatar.

So I’ve put my avatar at fuzzylogic.me/.well-known/avatar.

Great idea, Jim!

Great post by Chris here on the double-edged-sword of our rapidly-evolving web standards, and how to stay sane. On the one hand the latest additions to the HTML, CSS and JavaScript standards are removing the need for many custom tools which is positive. However:

it can also leave you feeling like it’s impossible to keep up or learn it all. And that’s because you can’t! The field is literally too big to learn everything. “Keeping up” is both impossible and overrated. It’s the path to burnout.

Chris’s suggestion – something I find reassuring and will return to in moments of doubt – is that we focus on:

• a good understanding of the fundamentals,
• staying aware of general trends in the industry (such as important forthcoming native HTML elements; and the different approaches to building a website etc),
• problem-solving: being good at “solving problems with tech” rather than just knowing a bunch of tools.

Clair recently brought her fancy coffee machine home from work. It’s a Sage Barista Touch. Since then, I’ve been learning what’s involved in making a coffee by grinding fresh from whole beans, barista-style!

It’s more complicated than I would have thought, and has involved lots of learning and trial and error.

Here are my go-to resources and my rules-of-thumb. I’m not saying they’re perfect, but they’re working for me! Any additional tips from people more in the know are, of course, very welcome.

Dialling in: my rule of thumb

Overall I want:

• a good taste, as a result of
• a grind of 18-19g, and
• a pull where liquid flows from 7 seconds or more, and
• a conventional yield such as a 2oz double-espresso.

Once you’ve achieved the above from a process of trial and error, dial in the settings (grind, dose) and log any additional notes so that you can easily repeat the same process achieving the same results.

How it works in practice

If I buy a new bag of coffee beans for a coffee I’m trying for the first time, here’s how I’d set about dialling in.

Note: before you start, you want your coffee’s roast date to be no more than 3 weeks ago and you’ll need coffee scales and one or two espresso shot glasses with measuring lines.

Fill up the tank with fresh water. Use the hot water feature to pour out some hot water into your mug to warm everything up.

Start with a grind size of 12 and a grind time of 20 seconds (they’re sensible middling starting points).

Place your portafilter with funnel attached on your scales (turned off) then turn on the scales so that they’re zeroed appropriately.

Remove the portafilter and grind out coffee based on the previously set grind time. Use the scales to check how much you’ve ground. Remove some, or grind and add more, til you have 18g. Jot down how much time it takes to grind 18g.

Settle, level (roughly) and tamp the coffee in the basket.

Remove the funnel then screw the portafilter in so that it’s ready to brew.

Place your espresso measuring mug under the portafilter, ready to receive brewed coffee.

Start brewing and note the point when liquid starts flowing. If it starts flowing before seven seconds, set the grind size finer. Get this aspect locked down first.

Once we’ve achieved a good begin-flow point and a steady flow, I want to identify the number of seconds it takes to achieve my target yield – meaning the time at which the crema hits the 2oz double espresso line.

Once you’ve hit your yield, and so long as the time was between 25-35 seconds, taste it. If you like it you could dial in that brew time and stop there. If it’s at say 28+ seconds (indicating that the water’s taking a long time to make its way though the coffee) I might also try increasing the grind size by one (larger grind = less dense = water gets through faster) and seeing if I can achieve the target yield within a few less seconds.

Another little tweak I sometimes make to achieve the balance of begin-flow-time, steady flow and yield is to slightly increase or reduce the amount of coffee. For example adding a few milligrams (a dose of 18.5g versus 18g) might start the flow just a little later, when that’s what you need.

If you tried different settings, compare the taste in separate shot glasses. Go with the one you like! Dial in (save/overwrite) your grind size, grind time and brew time. I’ve noticed that the grind size can move a bit of its own accord between uses, so noting the settings for this coffee down somewhere is a good idea too.

Now that you have a good shot of espresso, you could make (for example) a flat white… or add water and a drop of milk for an americano… or just have the espresso itself if you’re feeling Italian.

Resources

• Sage Barista Touch intruction manual
• Dialling in tutorial for the Sage Barista Touch by American barista Matt Davis
• Dave Wells’s instructional video
• Breville’s video tutorial playlist

This lasagne was meat-free, fun to cook, easy on the eye and tasted great.

It’s important to set the record straight. Normally when people talk about the early UK scene the same few things get mentioned. The real underground never gets talked about."

I loved this! It tells the stories behind many of the lesser-reported UK scenes and record labels. And it really helped to join a lot of musical dots for me, covering music I first heard on cassettes as a teenager thirty years ago. (That includes fairly obscure labels such as Chill – that brilliant quote about “setting the record straight” was from their A+R man Tim Raidl).

I also loved Matt’s passion for telling the stories of these people and communities.

Highly recommended.

Clair and I, along with our pal Fiona, just went to see Banksy’s Cut and run exhibition at the GOMA in Glasgow. I loved it!

Banksy describes it as follows:

I’ve kept these stencils hidden away for years, mindful they could be used as evidence in a charge of criminal damage. But that moment seems to have passed, so now I’m exhibiting them in a gallery as works of art. I’m not sure which is the greater crime.

He mentions that one of the main reasons he chose Glasgow’s GOMA is because the ever-present cone on the head of the Duke of Wellington statue outside is his favourite work of art in the UK.

…the statue out the front has had a cone on its head continuously for the past 40 odd years. Despite the best efforts of the council and the police, every time one is removed another takes its place."

I really enjoyed the way the exhibition was arranged and presented with the various use of corridors, rooms, concourses and other objects such as elevators and phone booths.

I liked Banky self-effacing introduction saying that really he was cheating and gets (steals) all his inspiration from others, or real artists.

I loved where he talked about the light-switch moment about not needing to add a background but rather to make the real-life location the background, and how that then fires the imagination with the challenge “How much of the environment can you integrate into the piece?”. How much space could there be between the girl and the balloon?

Lastly, the final area is a treat. It simulates Banksy’s bedroom growing up and the music, art and films which influenced him. There’s a great description of how the graffitied sign in Jaws – where a sign presenting Amity Island as a paradise is doctored with a shark fin and “Help!” speech bubble – was an early example of art that really spoke to him. In this graffiti he saw a wonderful combination of satire, powerless people finding a way to make their voice heard, humour, art and rebellion.

Here are my quick links and tips for creating a markdown-file-based blog post using only github.com and no CMS. I’ve put these on this site so that they’re on the web therefore I can access them wherever I am.

Why do I create posts this way? Because I’ve tried forestry.io (now Tina) and Netlify CMS and I no longer have the time or inclination to maintain their dependencies, load their JavaScript or make ongoing updates as they evolve. I’ve also found them a little flaky. So instead let’s see how this lo-fi approach works.

This post is mainly for my own reference but who knows, maybe it’ll be useful to someone else too.

Step 1:

Create a new markdown file in my posts directory

Step 2: use one of these previous posts as a template (use the “copy raw file” icon-button then paste into my new markdown file):

• Standard blog entry
• Bookmark
• Short note
• Note with photo
• Book I’ve started reading
• Film I just watched
• (Video of) record I bought/love
• Mix I’ve just recorded

Useful references

• grab current datetime in right format (see the Date/time field under Convert from strings)
• All of my tags
• Images: how I optimise, host, and code for performance and responsiveness
• Set frontmatter date to Created

Other notes

Reminder to self: create a bookmark for this post on all my devices. Name it “Nu Gh post”.

In this tutorial video Seth Pech shares what he’s learned about that most foundational (and important) of table-tennis shots – the block.

Fundamentals:

1. keep the racket in front rather than blocking on the side of your body. You can see it better and transition faster
2. for the basic block just use the opponent’s energy – don’t add anything
3. for backhand, block in your normal backhand posture (rather than a lollipop, or poking) to aid transitioning to attack
4. don’t bend your wrist back lots – it’s painful. Bend it back just a little.
5. timing: catch it on rise or at top of the bounce, rather than just off the bounce
6. against a heavy-spin loop, let the ball come to you and push down on it. Don’t move into it

Backhand punch block:

1. have a relaxed wrist
2. small backswing – imagine your hand hitting a sheet of paper and getting a nice “smack” on it for a “pop” sound
3. catch ball at the top of the bounce. Going early makes it hard to get over the net.
4. ascend very slightly through shot for a tiny bit of topspin (but tiny, as it’s still a punch)

Nice video here from Tom Lodziak in which coach Emma Harradine demonstrates a forehand loop (against backspin) that just looks so spinny, safe and reliable.

I’ve always liked the idea of this shot – the archetypal third ball in the rally – being like a well-oiled machine, but have never quite nailed it. So I’m gonna study this!

The key points are:

1. Drop the right knee and put weight on right foot
2. Rotate hips and upper body so that non-playing shoulder, elbow face table and non-playing upper-arm is horizontal like table surface
3. Drop bat below height of the ball
4. Brush the ball
5. Contact ball at top of its bounce – don’t let it drop
6. Rotate hips, upper-body
7. The key is consistency and spin. This shot is a set-up not a winner
8. Next shot can be more direct and faster, but don’t blast it either – there’s no need. Going for position is really effective.

Matthias feels that the recent slew of additions to CSS have completely changed the game.

this time, something feels different… the changes coming to CSS are so fundamental on so many levels that it almost feels like a singularity. There is now the CSS before and the CSS after the early 2020s.

Want to emulate and confidently design a layout that leverages the potential of CSS Grid in any of the major design tools like Figma, Adobe XD, or Sketch? Not possible. Want to define a color in one of the wide gamut color spaces like OKLCH, which result in more vibrant and natural colors on modern screens, maybe by using a color picker? Not possible. You want to simulate fluid typography that dynamically scales font sizes based on the viewport or container size and also define minimum and maximum values like you can do it in CSS with clamp()? Not possible. Or how about defining a fallback font in case your web font doesn’t load? Good luck using any screen design tool on the market. Not only are all of those things – very clearly – important design decisions, but they are also easily possible with just a few lines of CSS. In this new era of CSS, the design tools are now the limiting factor.

He also hopes and suggests that CSS might become more respected and teams might “shift left” with regard to prototyping in the browser.

What I expect to see overall is that the perception and thus the role of CSS in the design process will change from being mainly a presentational styling tool at the end of the waterfall to a tool that is being used at the heart of making design decisions early on. The value of a designer who knows how to prototype and build web components with modern CSS will therefore increase a lot. As a design engineering freelancer, I’m noticing this already.

A tasty and healthy asian-style recipe from Gousto, which I enjoyed cooking and eating and would like to make again.

Ingredients (for two people)

• Diced chicken thigh (250g)
• Dried chilli flakes (0.5 tbsp)
• Fine egg noodle nests (2)
• Ginger and garilc paste (15g)
• Pho broth base (25g)
• Soy sauce (8ml)
• Spinach (80g)
• Toasted sesame oil (10ml)
• Vegetable oil

Instructions

Take chicken out of fridge, open the packet and let it air.

Boil a full kettle.

Heat a large, wide-based pan with a drizzle of veg oil over a high heat.

Once hot add your diced chicken thigh with your soy sauce and cook for an initial 5-6 min or until beginning to brown.

Was your spinach and pat it dry with kitchen paper.

Dissolve your pho broth paste in 600ml boiled water – this is your stock.

Reboil a kettle.

Add your fine egg noodles to a large bowl, cover them with boiled water and stir for 10 secs to separate the noodles. Set aside to soak for 4 min.

Once te chicken as ad an initial 5-6 min, add your ginger and garilc paste and half your chilli flakes and cook for a further 2-3 min or until fragrant.

Once fragrant add the stock to the pan with the chicken and bring to the boil over a high heat.

Once boiling, reduce the heat to medium and cook for a final 3 min or until the chicken is cooked through (no pink meat!).

Add the spinach to the pan and mix everything together until the spinach has slightly wilted – this is your fragrant chicken thigh and spinach broth.

Drain the soaked noodles.

Add the drained noodles to a bowl and pour in the fragrant chicken thigh and spinach broth.

Drizzle over your toasted sesame oil and sprinkle over the remaining chilli flakes.

Enjoy!

This interesting website from the GDS accessibility team sets out seven personas, each with different access needs.

You can use these profiles to experience the web from the perspective of the personas and gain more understanding of accessibility issues.

The site explains how to set up a device or browser to give each persona its own profile simulating the persona’s condition(s) and runs the assistive technology they use to help them.

Henny Swan, director at Tetralogical, with some great advice for those whom accessibility responsibility often falls to.

Henny advises:

On responsibility: accessibility is everyone’s responsibility all the time, not just your responsibility all the time. Establish that you can support accessibility, but others also need to do accessibility work and make accessibility-related decisions.

On relationship-building: build relationships with decision-makers with authority to embed accessibility and practitioners ready to build up their skills.

On sustainability and scalability: look for ways to scale what you do through demonstration and documentation.

On expectations: manage expectations and be clear about what you can do. You can give advice, but teams themselves need to make informed decsions. Also – you won’t know everyting, and sometimes you need the help of expert consultancy.

On having support to hand: build a support network through community groups and mentor programmes. I’ve also taken Henny’s advice and subscribed to the WebAIM accessibility discussion list.

This Design System reference website sports a smart architecture with some interesting sections.

The components are neatly organised into categories. And I like the Foundations area which includes a Design System Concepts section serving as a glossary of property and anatomical terms, plus an Accessibility section with neat diagrams.

I think what I like best about this site/system is its organisation and naming.

Working as a web developer, you’ll meet colleagues who don’t realise that accessibility should be non-negotiable. So I’m bookmarking for ready access Tim Berners-Lee’s oft-quoted but still powerful statement of intent from 1997.

The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect.

This particular W3C WAI page goes on to say:

The Web is fundamentally designed to work for all people, whatever their hardware, software, language, location, or ability. When the Web meets this goal, it is accessible to people with a diverse range of hearing, movement, sight, and cognitive ability.

Thus the impact of disability is radically changed on the Web because the Web removes barriers to communication and interaction that many people face in the physical world. However, when websites, applications, technologies, or tools are badly designed, they can create barriers that exclude people from using the Web.

Accessibility is essential for developers and organizations that want to create high-quality websites and web tools, and not exclude people from using their products and services.

A spicy but somewhat relatable thought from Adam Silver:

UX observation: I think there might be more devs who care about good design than there are designers. By “good” I mean works for everyone (is accessible) rather than looks nice. What do you think?

The ensuing conversation is pretty interesting. I particularly liked these contributions from Martin Hoyer:

Absolutely. Thinking about the design code-first and understanding how HTML works is so valuable. I don’t think designers should learn HTML but they shouldn’t be the first people to decide how something is built!

He goes on to describe how he thinks design should be done as follows:

In an ideal world (and I don’t think I’ve ever fully achieved this) I’d like to get some requirements (from product I guess), build a prototype in code, then collaboratively iterate on the design from there. Maybe call it a design sprint or whatever!

Applying opacity to an existing colour value is a pretty common design requirement, and here Chris presents five ways to achieve it.

I’ll admit that the explosion of colour models is one aspect of CSS that leaves me dizzy, so this explanation framed around a practical requirement really helps. The main approaches presented by Chris are:

• 8 digit hex code
• relative colour syntax (currently only supported in Safari)
• using a format other than hex such as HSL since it’s easier to apply transparency
• using (in a progressively enanced approach) HDR-display-friendly colours, via a new colour format such as oklch

My latest radio show is dedicated to Ryuichi Sakamoto, who sadly died recently. I played a couple of tracks by the great man alongside more of my favourite music.

Listen to the show on Soundcloud.

Here’s the tracklist:

1. Ryuichi Sakamoto & Alva Noto - Aurora
2. Matt Wilde - Who Cares
3. Kaidi Tatham - Funky Fool
4. Mac DeMarco - 20180702 2
5. Robert Ffrench - I am wondering
6. Ryuichi Sakamoto - Plastic Bamboo
7. Kraftwerk - Vitamin
8. Mac DeMarco - 20180924
9. Gal Costa - Relance (Bernhard Pinheiro edit)
10. Imagination - So good, so right (12″ mix then dub)
11. Romaal Kultan - Between Us, Part One
12. Jayme Marques - Berimbao
13. Souldrummers - Space And Time

I really enjoyed this one and I’m pleased with how it turned out. Thanks to Susan and Speedy for having me back.

Two lovely new websites (or website updates) appeared on my radar this last week that I wanted to note here for future front-end inspiration.

Vitaly Friedman’s Smart Interface Patterns has had some lovely animation and component work from Clearleft alumni Cassie Evans and Trys Mudford. Given Vitaly’s obsession with creating accessible, user-friendly components and the collaborators he has on board, I expect this site to be choc-full of well crafted nuggets for reference! It looks ace, too.

I noted a while ago that the W3C had a new Design System, and now the W3C has a new website in beta too. I imagine it might use components from that Design System alongside other carefully-considered patterns of markup, style and behaviour.

Nice job on these sites, to all concerned!

In responsive design we generally want a single component to get different styles in different contexts. Up until recently the prevailing method of context-awareness was to use a CSS media query to query the viewport size. This wasn’t ideal. For example you might want an component to be styled differently when in a narrow context such as a sidebar (regardless of the device size), and viewport-based queries don’t help with that.

But everything has changed. We can now use CSS to query the size of any given container and this feature is supported in all major browsers.

There’s a bit of new syntax to learn, so I recently had my first play with container queries on codepen.

My pen is pretty trivial, but the goal was specifically to do the most minimal test that lets me test-drive the key syntax. It turns out that it’s quite straightforward.

Define an element as a container:

.sidebar {
  container: ctr-sidebar / inline-size;
}

Change the styles of another element (.foo) when it’s inside that container and the container’s inline-size (the logical property name for width) matches a given query:

@container ctr-sidebar (max-width: 300px) {
  .foo {
    // context-specific styles go here 
  }
}

Note that you could also omit the ctr-sidebar context in the above query, if you wanted the change to apply in all defined containers.

I’m a fan of web designers and developers collaborating closely rather than designers throwing mock-ups over the wall. Recently I read two newsletters relating to this topic, or perhaps more accurately about perceived divisions between design and development and some better, more modern ways of thinking.

The first, The best handoff is no handoff from Smashing Magazine, presents alternatives to waterfall including The Hot Potato Process espoused by Brad Frost and Dan Mall.

The second, Promises from Clearleft argues that presenting flat designs for sign-off at an early stage of a project doesn’t make sense given the nature of the web, and that it makes promises that can’t be kept.

In practice, sign-off leads to disappointment for everyone involved. A design created in isolation in a graphics-design tool almost never survives contact with the reality of the web. The client is disappointed that the final output doesn’t match what was signed off. The developer is disappointed that they weren’t consulted sooner. The designer is disappointed that the code doesn’t match the design.

Clearleft argue instead for presenting the coded page in the browser because it avoids broken promises and presents reality.

My work colleague Ryan recently drew my attention to the new HTML search element. This morning I read Scott O’Hara’s excellent primer. Scott worked on implementing <search>, and his article cleared up my questions around what it is and when we can start using it.

Firstly <search> is not a “search input” – it’s not a replacement for any existing input elements. Instead it’s a native HTML element to create a search landmark, something that until now we could only achieve by applying role="search" to another element.

Landmarks are an important semantic structure allowing screen reader users to orient themselves and jump to important areas of a web page. Existing landmark-signalling elements you might know include <header>, <main>, <footer>. So you would use <search> to wrap around a search function, thus providing additional accessibility. And it lets you do so with a native HTML element instead of re-purposing another element by adding ARIA properties, per the first rule of ARIA use. It’d look something like this:

So as Scott himself admits:

To be brutally honest, this is not the most important element that’s ever been added to the HTML specification. It is however a nice little accessibility win.

Do I have a use for this?

If you have a search function or search page and currently miss the opportunity to offer a search landmark you could do so and improve the user experience.

Can I use the <search> element today?

As Scott mentions, it’s not yet available in browsers (although it likely will arrive soon). So if you added <search> (just as I’ve typed it there) to a page, it wouldn’t currently create a search landmark. So you could wait for a while before using the element. Alternatively, because HTML’s design is intentionally geared toward a progressive enhancement mindset, you could take Jeremy Keith’s approach and safely use the following today:

Jeremy knows that when browsers encounter an HTML element they don’t know, they don’t break but rather treat it as an anonymous element and carry on. So he includes <search> to start adopting the new element today, but bolts on role=search temporarily to manually provide the landmark until browsers understand search. He’ll then remove the role=search part once support for search is widespread.

I’ve been listening to lots of jazz of late and loved seeing Herbie Hancock live in August 22.

So I thought I’d explore further and listen to the audio recording of Herbie’s autobiography Possibilities, narrated by the great man himself.

I really enjoyed it. Herbie’s story is really interesting and entertaining. He’s been at the forefront of so many iconic scenes – from playing in Miles Davis’s band, to writing many classics of his own, to breaking new ground with his Mwandishi sextet and the Headhunters.

I love his carefree and curious spirit and his willingness to experiment with technology (from the fender Rhodes, to other synths, to the internet) and take risks in other aspects of life.

What a talent and what a guy!

I recorded my second radio show of 2023 live at the Clyde Built Radio studio at the weekend. It was great playing records there on a sunny Sunday with the clocks just gone forward and the Barras buzzing as it hosted a Hong Kong street market.

This month I went for a set of reggae, electronics and other assorted good vibes.

Listen to the show on Soundcloud.

Here’s the tracklist:

1. Mali-I - Next Level Intro
2. Robert Ffrench - You are so special
3. Radio Trip - No Oud
4. Lucas Croon - Japon
5. Babeth - Orchestra Reggae
6. Tyrone Evans - Rise Up (Version)
7. Gateway Shuffle - Snapping
8. Cloud - Moon Rock
9. Azura - Theme from Azura
10. Visage - Pleasure Boys
11. Romaal Kultan - Meditate
12. Language - Tranquility Bass

Thanks to Amy for arranging, and to Matthew, the engineer on the day.

I’m wary of list-based clickbait – and Adam’s recent 6 CSS snippets every front-end developer should know in 2023 feels like that – however I like this modern and minimal approach to creating a circle. I’ve previously seen aspect-ratio: 1 used to create a square box and it’s a lovely shorthand for “make width and height equal”. It makes sense that you can use it for a circle too, just by adding some border-radius.

.circle { inline-size: 25ch; aspect-ratio: 1; border-radius: 50%; }

System font stack CSS organized by typeface classification for every modern OS. The fastest fonts available. No downloading, no layout shifts, no flashes — just instant renders.

This is a great resource for when you want a particular style of font (workhorse sans-serif, grotesque, monospace, display slab serif etc) and to favour a system font rather than a custom font to get performance and simplicity benefits allied to having many weights and characters natively available.

To grab a stack, just copy the font-family declaration from its card then paste that into your CSS.

To easily preview how custom text of your choice would look in each stack, use the handy form at the top of the page.

Aside from its utility I also love this page as a learning resource. For each font category, the font and weight your browsing context is currently using is highlighted in blue with a solid underline, while those available but not currently in use and those unavailable are also separately highlighted. This gives you even more information than Firefox’s font panel or the WhatFont extension for Chrome.

Notes:

• if you notice support for a font when you wouldn’t expect it (because your OS doesn’t include it), it’s worth remembering that you may have previously installed it locally. This was the case for me with Inter in the Neo-Grotesque stack. You can click the little “info” icon links beside each stack’s title for detailed info on that stack including which OSs use which font
• the declaration font-family: system-ui, sans-serif as a means of serving the Operating System’s default sans-serif seemed suspiciously simple given the complicated iterations I’ve seen previously. However after some digging I confirmed that Firefox added support for system-ui a few years ago so previous, verbose alternatives are no longer necessary.

I was delighted to discover that my talented colleague Anda has her own website and uses it to write articles like this! This one is obviously pretty relevant to me too, given that I work on the same team.

I particularly liked the fifth lesson – “You are an integral part of the company”. This is an aspect of Design System work that I care about because it’s important to me to work on impactful things that get into a lot of users’ hands.

Something we often talk about in our Design System team is that components should not be like Swiss Army Knives. It’s better for them to be laser-focused because by limiting their scope to a single task they are more reusable and support a more extensible system through composition.

Discussions often arise when we consider the flip-side – components which do too much, know too much, or care too much! When they cover too much ground or make assumptions about their context, things go wrong. Here are some examples.

Card

In websites where many elements have a “rounded panel”-like appearance so as to pop off the background, you can run into problems. Because of the somewhat Card-like appearance, people start to regard many semantically distinct things as “Cards” (rather than limiting the meaning of Card to a more conventional definition). Here are some of the problems this can cause:

• If the name covers a million use cases, then how can you describe it sensibly, or define its boundaries?
• When do you stop piling on different things it can mean? How do you stop it growing? How do you avoid bloat?
• Ongoing naming/confusion issues: you’re setting yourself up for continued confusion and code disparity. If something is “semantically” a note, or a comment, or a message etc then you can expect that future staff are gonna describe it as that rather than a Card! They’ll likely (understandably) write code that feels appropriate too. The problem will continue.

I appreciate that often we need pragmatic solutions, so if our designs have lots of similar-looking elements then there is still something we can do. If the repeated thing is more of a “shape” than a something with common-purpose, then just call it out as that! That could either be by name – for example Every Layout have a Box layout which could be a starting point – or by categorisation i.e. by moving the non-ideally named thing into a clearly demarcated Utilities (or similar) category in your Design System.

Flex

It seems that a number of Design Systems have a Flex component. My feeling, though, is that these represent an early reaction to the emergence of CSS’s Flexbox, rather than necessarily being sensible system-friendly or consumer-friendly components. CSS layout covers a lot and I think breaking this down into different smaller tools (Stack, Inline, Grid etc) works better.

Button

I’ve talked before about the “Everything is a button” mindset and how it’s harmful. Buttons and links are fundamentally different HTML elements with totally different purposes, and bundling them together has various ill effects that I see on a regular basis.

References

• Shifting left: how introducing accessibility earlier helps the BBC’s design system (by Sophie Beaumont)

Getting to profitability is no longer a distant, post-IPO nice-to-have, but a short-term necessity for survival. But how to do that without cutting off the legs of the product team? By using better tools and techniques, that's how.

DHH of 37 Signals and Basecamp offers three pieces of advice for productivity and profitability.

1: Unless market conditions demand otherwise, delay native app development for as long as possible.

2: Hire full-stack developers, and don't let them split the frontend and backend into separate jurisdictions.

3: Hire designers who work natively with the web.

I’m not a fan of the term “full-stack” and also think it underestimates the complexity/speciality required to work (properly) as a front-end developer. However that aside, I think there is sense in these, even though others I know would disagree.

Me, Clair and Rudy just enjoyed a lovely weekend break. We stayed at Drinkbetween cottage on Banchory Farm. While only 70 minutes drive from home it provided some lovely countryside isolation, with the bonus of nice nearby towns to visit nearby too.

The cottage has recently been restored by the farm owners and was the perfect environment to relax.

Our nearest neighbours were some colourful pheasants, a flock of sheep and three highland cows grazing in the fields opposite. Beyond them, there was a view onto the firth of forth and Forth bridges.

On the Saturday we enjoyed a short trip to the nearby towns of Aberdour via Burntisland, and moseyed down to the lovely Silver beach where we stopped for a coffee at Sands.

Clair brought and made beautiful food and at night we watched Captain Fantastic.

It was a reminder of just how great a well-needed change of pace and scenery you can get in a short distance and space of time.

Clair and I loved this story of Viggo Mortensen’s Ben Cash and family temporarily leaving their off-grid existence in the Pacific Northwest to enter civilisation. It poses some interesting questions about parenting, lifestyle and morality but mainly, it’s just a lot of fun.

Judging by his movie review for The Guardian, Mark Kermode seemed to like Captain Fantastic too.

Having pre-recorded previous shows, I recently made a first visit to Clyde Built Radio’s station at the Barras market for a live show and really enjoyed it. It’s such a great location and it was a nice change to spin records on a Sunday morning.

I started off gently with atmospheric music from Detroit’s Ian Finklestein followed by a modern take on Steve Reich from Bitchin Bajas. From there it was into some hazy electronics and a dash of 80s boogie before landing on sounds from house music legends Abacus and Larry Heard.

Listen to the show.

Here’s the tracklist:

1. Ian Finklestein – Ago-ra
2. Bitchin Bajas – Amorpha
3. Isotope 217 – Audio Boxing
4. Coral D & PST – Send it
5. Komiko – Feel Alright
6. Visions of Tomorrow – Galaxy
7. Wheelup – Infinity feat. Abacus
8. Cy Gorman – Dewy Drip
9. Peech Boys – Don’t make me wait (Dub)
10. Purelink – Dozen Sunbeams (Nice Girl version)
11. Abacus – The Lower End Theory
12. Ossie – I hurt you
13. Fingers Inc – Bye Bye

Thanks to Amy for the invite, and Brandon, the engineer on the day.

Responsive design for tables is tricky. Sure, you can just make the table’s container horizontally scrollable but that’s more a developer convenience than a great user experience. And if you instead try to do something more clever, you can run into challenges as I did in the past. Still, we should strive to design good narrow screen user experiences for tables, alongside feasible technical solutions to achieve them.

In terms of UI design, I was interested to read Erik Kennedy’s recent newsletter on The best way to display tables on mobile. Erik lists three different approaches, which are (in reverse order of his preference):

1. Hide the least important columns
2. Cards with rows of Label-Value pairs
3. More radical “remix” as a “Mobile List”

Another article worth checking is Andrew Coyle’s The Responsive Table. He describes the following approaches:

1. Horizontal overflow table (inc. fixed first column)
2. Transitional table
3. Priority responsive table

For the transitional table, Andrew links to Charlie Cathcart’s Responsive & Accessible Data Table codepen. It looks similar (perhaps better looking but not quite as accessible) to Adrian Roselli’s Responsive Accessible Table.

I’ve started reading some entries from Manuel Matuzovic’s 100 days of (more or less) modern CSS series, and began with the excellent Day 99: Native Nesting. It clearly explains how to use the now-agreed syntax for various common scenarios.

The syntax is pretty close to what we’re used to doing with Sass, which is great!

Also, I’m now also clear that nested selectors must always start with a symbol rather than a letter. Often they would naturally do so anyway, for example when nesting a class since that already starts with a symbol (a full stop). But in cases where they wouldn’t – essentially only when nesting an “element selector” – we start it with an “&”. So:

main { & article { ... } }

Straightforward enough!

Regarding browser support for CSS nesting, at the time of writing it is available in Chrome and Safari Technology Preview only.

I would therefore only use it for demos and for the most non-essential enhancements. We’ll need to hold off any full-scale switch from Sass nesting to CSS nesting for large and important production websites until this is in Firefox and standard Safari, and until a sufficient percentage of users has the up-to-date versions. So a little while away yet, but given the current rate of browser updates, likely sooner than we might think!

Adam Silver’s collection of accessible form-related components – a companion to his book Form Design Patterns – is a brilliant reference.

In there you’ll find Autocomplete, date fields, validation and lots of other tricky components and patterns.

The component gallery is an up-to-date list of interface component examples. It’s really helpful for looking up existing naming conventions. It also contains a list of Design Systems.

Here’s an important update on native modal dialogues. TL;DR – it’s now OK to use dialog.

Last year I posted that Safari now supported the HTML dialog element meaning that we were within touching distance of being able to adopt it with confidence. My caveat was:

However first I think we’d need to make an informed decision regarding our satisfaction with support, based on the updated advice in Scott O’Hara’s article Having an Open Dialog.

(Accessibility expert Scott O’Hara has been diligently testing the dialog element for years.)

However the happy day has arrived. The other day Scott posted Use the dialog element (reasonably). It includes this advice:

I personally think it’s time to move away from using custom dialogs, and to use the dialog element instead.

That’s an important green-light!

And this of course means that we can stop DIYing modal dialogues from divs plus super-complicated scripting and custom ARIA, and instead let a native HTML element do most of the heavy lifting for us.

From a Design System perspective, I’d previously suggested to my team that when we revisit our Modal component we should err toward a good custom dialogue library first, however I’m now likely to recommend we go for native dialog instead. Which is great!

This new resource on Web Components from Keith Cirkel and Kristján Oddsson of GitHub (and friends) is looking great so far.

As I recently tweeted, I love that it’s demoing “vanilla” Web Components first rather than using a library for the demos.

So far I’ve found that the various web component development frameworks (Lit etc) are cool, but generally I’d like to see more demos that create components without using abstractions. The frameworks include dependencies, opinions and proprietary syntax that (for me at least) make an already tricky learning curve more steep so they’re not (yet) my preferred approach. Right now I want to properly understand what’s going on at the web standards level.

Aside from tutorials this guide also includes a great Learn section which digs into JavaScript topics such as Classes and Events and why these are important for Web Components.

I hope that in future the guide will cover testing Web Components too.

Lastly, I like the Embed Mastodon Toot web component tutorial, and to help it sink in (and save the code for posterity) I’ve chucked the code into a pen.

This is the best TV I’ve watched in a while, and Clair and I eagerly binged it in two days. I loved how it looked, the atmospheric music, the characters, the acting and the issues. I’ll now need to watch the other two Mystery Road series.

My teammate Colin just shared this brilliant designers’ guide to documenting accessibility and user interactions. It’s really thorough and includes some pretty clever annotation techniques.

I agree with Stephanie that unless you ask the questions and document the answers regarding how a design will translate to an accessible reality then it can fall short at lots of points from the start to the implementation. This called to mind a similar perspective from Sophie Beaumont on how the BBC shift left regarding accessibility.

This type of annotation and discussion also feels like another healthy way for designers and engineers to talk to (and learn from) each other more.

I really like Stephanie’s conclusion that you won’t always have time for all of the techniques she mentions, so pick your battles.

I enjoyed this two-part tutorial from Chris arising from his critique of a subscription form plugin which includes the entire React library to achieve what could be done with a lightweight HTML and vanilla JavaScript solution. Chris advocates a progressively-enhanced approach. Instead of rendering the form with JavaScript he renders it in HTML and argues that not only is there no need for the former approach – because forms natively work without JavaScript – but also it only introduces fragility where we could provide resilience.

Part one: Using a wrecking ball when a hammer would suffice

Part two: More HTML, less JavaScript

I also recreated the front-end parts in a codepen to help this sink in.

Lastly, as someone who always favours resilience over fragility I wanted to take a moment to consider the part that Chris didn’t cover – why JavaScript is required at all. I guess it’s because, being a plugin, this is intended for portability and you as author have decided you want the error and success messaging to be “white-labelled” on the consuming website rather than for the user to be taken to a separate website. You don’t know the context’s stack so to provide a universally-supported solution you use JavaScript to handle the messaging, which then means you need to use JS to orchestrate everything else – preventing default submission, validating, fetch-based submission and API response handling.

Went to see BadBadNotGood with Marty, Jenni and Zippy last night, and they were fantastic.

We braved -7° conditions to meet at Tennent’s Bar on Byres Rd where we watched Argentia beat Croatia in the World Cup semi-final. Then onto the QMU, which provided a real nostalgia hit – I think the last time we were there was to see Roni Size and Reprazent in the Brown Paper Bag era.

We wangled a standing position on the balcony which was ideal as we could see the band, the visuals (lovely 16mm and 35mm film projections created specially for the music) and generally hear things much better. Each band member – drummer, bassist, saxophonist and keyboard player – are outstanding musicians, and together they’re incredibly tight. Led by drummer Alex Sowinski’s good vibes on the mic, they finished off their tour hitting all the right notes to send us into Christmas on a high.

Last thing to mention is I have BadBadNotGood to thank for introducing me to the music of Arthur Verocai, via his amazing string arrangements on Talk Memory. And for that I’m very thankful!

During a recent November week off I enjoyed a first visit to North Berwick. It’s a beautiful seaside town and I was lucky enough to get lovely cold-but-sunny winter weather.

Here are some of the things I did:

• Stayed at the Marine Hotel. This was a treat as it was quite posh, but I save money these days from being at home a lot and it was only for a couple of days so I’m gonna allow myself this one. The breakfast (porridge followed by cooked breakfast) was amazing and I also loved the pool and outdoor jacuzzi!
• Beach walk beside the golf course into town
• A walk around the harbour including great cliff views out to the Firth of Forth
• A visit to the seabird centre where, amongst other things, I learned that gannets inhabit the Bass rock and that a gathering of gannets is called a gannetry!
• Pretty good lil’ shops! I particularly enjoyed the Steampunk coffee shop which also houses the Orange Moon record store.
• Enjoyed a pint at The Ship Inn and The Auld Hoose. It turns out that my friend Kris’s dad (who I knew pretty well) was a regular at the latter.
• A nice frutti de mare pasta dinner at Bella Italia

Next time I visit (hopefully with Clair and Rudy) I should go in summer so I can catch The Lobster Shack open! I’d also like to visit nearby Tantallon Castle.

Here’s another tool from the Utopia creators to assist with breakpoint-free fluid responsive design.

Until now, the tooling for Utopia has been predominantly developer-focused, but we know that's only half the story. To start to address this, we've created a pair of Figma plugins to help designers set out Utopian project foundations.

I also really like the idea of having three sets of type styles at both defined viewport sizes.

We typically use a Strong style for headings and other text that we want to visually punctuate our designs. The Prose style is useful for longer-form text which might benefit from a larger, more relaxed line height. The Default style is a catch-all for other snippets of text in our designs, like a standlone link, a short piece of explainer text, or perhaps an image caption. The number and variety of styles required will vary depending on your design's purpose and style but these three serve as a reasonable starting point.

The best SL-1200/10 set-up video I’ve seen.

I especially like the section on testing for channel imbalance by playing a mono record (such as Nat Birchall's Upright Living LP) and comparing the output meter for any differences between left and right, then untightening the relevant tonearm screws in order to make adjustments.

Update 26/10/25:

This one from Resident Advisor and the Hoppetosse nightclub ain’t bad either (although the Longbox tutorial still edges it).

At the height of my playing career, David Baddiel wore blackface and put a pineapple on his head to mock me on national television every Friday night. While the chants have remained ever present, and David’s name has become synonymous with mine, it’s taken 25 years for us to finally meet face-to-face. In this episode, I talk with David about the impact his racist sketches had on me, my family and the wider community, and why allyship needs to become a bigger part of football.

While watching David Baddiel's excellent Jews Don't Count documentary on Channel Four I was intrigued by the section in which he spoke to Jason Lee, leading me to seek out this podcast episode.

In the nineties at the height of “lads’ culture”, Baddiel and Frank Skinner essentially bullied and abused footballer Lee, mocking his appearance in particular.

This conversation, difficult as it sounded, is fascinating. It throws up so many moral ambiguities, such as whether or not Baddiel is a fit person to publicly campaign against racism, and related questions around acceptance, rehabilitation and moving on.

It also made me question my own prejudices and behaviours, past and present.

Most of all I was impressed by Jason Lee. His past treatment has meant that he and his family have had a lot to endure, but he speaks with such dignity, positivity and resolve.

This article is not about when or why you would use visually-hidden content. There’s a number of excellent articles that discuss these questions in detail, notably Scott O’Hara’s Inclusively Hidden. But most of them don’t go into much detail about the specific CSS involved — why do we use this particular pattern, with these specific properties? So today I’m going to dissect it, looking at each of the properties in turn, why it’s there, and why it isn’t something else.

Relevant to How to hide elements on a web page.

I also liked this nugget:

it’s often called .sr-only (screen reader only, but that’s not a good name, because visually-hidden content is not just for screen readers).

Loved this thoughtful and insightful interview with Jeff Mills by Marcus Barnes.

Among the highlights were Jeff’s thoughts on whether his music could viably still be described as “Detroit” given how long he’s lived away from the motor city, and also his reflections on the impact on his peer group of the 1980 film American Gigolo.

Here’s a lovely slow-mo comparison of Liam Pitchford’s backhand technique versus that of an amateur.

The main things I take from it are:

• his posture – really low with weight forward
• how far in front of his body he strikes the ball – it’s way in front of his head and even in front of his non-playing hand, with impact at the back edge of the table
• the bat angle at the start (forehand side facing ceiling like you’re holding a frying pan)
• as he prepares, the bat’s left edge tilts up a bit and he gets slightly lower
• elbow moves forward (helping him rotate wrist back) but only as far as to create a virtual parallel horizontal line with the table’s back edge. This is the perfect stopping point for wrist pivoting (whereas I’ve let the elbow go further forward which is unnatural)
• uses wrist to bring bat tip way back to point back at his belly button – I think this greater “travel distance” might be crucial versus an amateur’s version of a wristy backhand
• then there’s a little forearm forward movement and a lot of wrist rotation to get the bat to the impact point
• stays low and on follow-through the bat only gets as high as his chin

People have used the HTML title attribute to achieve a native “tooltip” effect for many years. However accessibility experts have recommended that we should avoid this practice, and here I summarise my research on the topic.

Renowned accessibility solutions provider The Paciello Group recommend the title attribute should almost always be avoided. It causes problems for lots of different usage contexts (keyboard, touch device, screen readers). The only place where I can see that it is still helpful is on iframe. It was beneficial on form inputs in cases where a visible text label would be redundant and we want to provide our control with a programmatically associated label, however we now have aria attributes which do a better job.

So on anything other than iframe the title attribute is undesirable. To back this up, at work my team recently received the following accessibility feedback from Tetralogical when they reviewed one of our tables.

The Edit and Delete links use the title attribute to provide additional context for each link. The title attribute can be unreliable (for example, in testing VoiceOver announces the title in French). Provide additional context using the aria-describedby attribute to reference the name or reference value of the item.

I’ve been stockpiling good records for a while and it’s time they got an airing. I’ll be playing a few on Radio Buena Vida, Saturday 19/11 at 4–5pm. Tune in or even come hang out in the café, if you’re in the hood.

There’s a classic web developer interview question that goes something like this:

What happens when you type in “bbc.co.uk” into a browser? Describe the journey that results in you seeing a page.

You could answer it like this:

Your browser sends an HTTP request which gets routed through a local modem/router then gets sent to a nameserver. That nameserver routes the request to the correct IP address, which will resolve to some sort of web server. That server will serve up either some static files, or run some backend code in order to generate a resource (probably an html page). When the HTML page is returned, your browser will parse it, which will likely generate more requests, and the cycle will repeat.

To do:

• add something about HTTPS
• add more about the front-end aspects: DOM, CSSOM, Accessibility tree, render blocking resources etc

References:

• My favorite interview question, by Ben McCormick
• How browsers work, on MDN

There’s so much to admire in Nord Health’s Design System and specifically its reference website.

I love the way it looks and is organised.

There’s a fantastic, practical accessibility checklist.

They document their naming conventions and the rationale behind them.

They were a trailblazer in adopting web components and I love the docs explaining why.

We’ve chosen to use Web Components because there is a strong requirement for Nord to be used in many different contexts and with varying technologies — from static HTML pages to server-rendered apps, through to single page applications authored with frameworks such as React and Vue. Web Components work great for Nord, because they:

• Are tech-agnostic instead of tech-specific
• Future proof our system with Web Standards
• Allow us to use any framework or no framework at all
• Provide great encapsulation for styles and functionality

Lastly their components look great and show a really high-level of front-end and accessibility literacy.

Whether I’m thinking about inclusive hiding, hamburger menus or web components one UI pattern I keep revisiting is the disclosure widget. Perhaps it’s because you can use this small pattern to bring together so many other wider aspects of good web development. So for future reference, here’s a braindump of my knowledge and resources on the subject.

A disclosure widget is for collapsing and expanding something. You might alternately describe that as hiding and showing something. The reason we collapse content is to save space. The thinking goes that users have a finite amount of screen estate (and attention) so we might want to reduce the space taken up by secondary content, or finer details, or repeated content so as to push the page’s key messages to the fore and save the user some scrolling. With a disclosure widget we collapse detailed content into a smaller snippet that acts as a button the user can activate to expand the full details (and collapse them again).

Adrian Roselli’s article Disclosure Widgets is a great primer on the available native and custom ARIA options, how to implement them and where each might be appropriate. Adrian’s article helpfully offers that a disclosure widget (the custom ARIA flavour) can be used as a base in order to achieve some other common UI requirements so long as you’re aware there are extra considerations and handle those carefully. Examples include:

• link and disclosure widget navigation
• table with expando rows
• accordion
• hamburger navigation
• highly custom select alternatives when listbox is innapropriate because it needs to include items that do not have the option role
• a toggle-tip

Something Adrian addresses (and I’ve previously written about) is the question around for which collapse/expand use cases we can safely use the native details element. There’s a lot to mention but since I’d prefer to present a simple heuristic let’s go meta here and use a details:

I’ve also noticed that Adrian has a handy pen combining code for numerous disclosure widget variations.

Heydon Pickering’s Collapsible sections on Inclusive Components is excellent, and includes consideration of progressive enhancement and an excellent web component version. It’s also oriented toward multiple adjacent sections (an accordion although it doesn’t use that term) and includes fantastic advice regarding:

• appropriate markup including screen reader considerations
• how best to programmatically switch state (such as open/closed) within a web component
• how to make that state accessible via an HTML attribute on the web component (e.g. <toggle-section open=true>)
• how that attribute is then accessible outside the component, for example to a button and script that collapses and expands all sections simultaneously

There’s my DIY Disclosure widget demo on Codepen. I first created it to use as an example in a talk on Hiding elements on the web, but since then its implementation has taken a few twists and turns. In its latest incarnation I’ve taken some inspiration from the way Manuel Matuzovic’s navigation tutorial uses a template in the markup to prepare the “hamburger toggle” button.

I’ve also been reflecting on how the hidden attribute’s boolean nature is ideal for a toggle button in theory – it’s semantic and therefore programattically conveys state – but how hiding with CSS can be more flexible, chiefly because hidden (like CSS’s display) is not animatible. If you hide with CSS, you could opt to use visibility: hidden (perhaps augmented with position so to avoid taking up space while hidden) which similarly hides from everyone in terms of accessibilty.

As it happens, the first web component I created was a disclosure widget. It could definitely be improved by some tweaks and additions along the lines of Heydon Pickering’s web component mentioned above. I’ll try to do that soon.

Troubleshooting

For some disclosure widget use cases (such as a custom link menu often called a Dropdown) there are a few events that typically should collapse the expanded widget. One is the escape key. Another is when the user moves focus outside the widget. One possible scenario is that the user might activate the trigger button, assess the expanded options and subsequently decide none are suitable and move elsewhere. The act of clicking/tapping elsewhere should collapse the widget. However there’s a challenge. In order for the widget to be able to fire unfocus so that an event listener can act upon that, it would have to be focused in the first place. And in Safari – unlike other browsers – buttons do not automatically receive focus when activated. (I think Firefox used to be the same but was updated.) The workaround is to set focus manually via focus() in your click event listener for the trigger button.

We want to find out if adding a 'date picker' component to the Design System is a good idea.

We're currently looking for: examples of date pickers in services: screenshots, prototypes, links to live services; use cases: explanations of why a 'date picker' was used in a service instead of a 'date input', or something else; research: how well 'date pickers' tested with users to complete different tasks.

This discussion thread will be really helpful for everyone attempting to create an accessible Date Picker.

At work there are plans afoot to reconcile various differing Autocomplete implementations into a single, reusable component. So far there’s been a written audit presenting all instances and how they differ in functional and technical respects. There’s also been design work to identify visual commonalities and avoid future inconsistencies. I’d now like to add another perspective: an investigation into which HTML materials and (if necessary) ARIA supplements are appropriate to ensure we build something accessible and resilient.

My experience is that to achieve the right result, HTML semantics and related concerns can’t just follow and bend to spec and visual design goals, but rather must influence the setting of those goals.

I’ll flesh out my findings in due course, but for now here are the key resources I’ve identified and plan to dig deep into.

Adrian Roselli’s article Stop Using ‘Drop-down’. To summarise the options of interest:

• ARIA Listbox lets you create a DIY thing that has the same roles and semantics as a <select> but where you have greater stylistic control. There are different ways to implement a Listbox.
• Datalist is the native HTML version of a combo box. A combo box is essentially a <select> with a text field. Datalist is announced by screen readers in different ways but as far as I can gather these are quirky rather than terrible. I found a nice Twitter thread on DataList which not only shows off its function but also includes a promising accessibility-related comment from Patrick H Lauke of Tetralogical. The drawback, because Datalist is native HTML, is that its options are not stylelable.
• ARIA Combobox is a pattern that combines ARIA combobox, textbox and listbox roles, and the benefit it brings is to allow a level of custom design that you couldn’t achieve with Datalist.
• Autocomplete (not to be confused with the HTML autocomplete attribute) describes a control which provides users with suggestions that may not be available in the DOM already… for example when you fetch options via Ajax in reponse to what the user types.

With regard to Autocomplete, Adrian points to Adam Silver’s Building an accessible autocomplete control.

And for advice on whether or not to go with a native select or a custom control, and how best to implement listbox and combobox if that’s your choice, Adrian points to the following resources from Sarah Higley:

• <select> your poison part 2 (see the Roll your own section at bottom)
• Recommended Combobox Patterns pen

I also see that GOV.UK have marked a possible Autocomplete component as one of their next priorities to review. Their Autocomplete discussion thread includes examples and research and will be really helpful.

I’ve been using schema.org for a few years now, but haven’t yet logged any notes and usage advice. Schema.org gives websites a practical, structured data approach for communicating the meaning of their content in finer detail than they could with native HTML alone. Google etc can then parse this and use it in their interfaces to offer users a richer view of your data.

Schema.org lets you pick from different types of properties for describing your content, such as book, person, place or event. Alternatively a more generic article you might use BlogPosting.

Schema.org is still current and celebrated its ten year anniversary in 2021.

One bit of troubleshooting advice worth mentioning is to validate your page using validator.schema.org. Thanks to Liam who recently pointed out a schema issue on my site, which reminded me I need to use the validator any time I make changes to the relevant markup.

Here’s a half-formed thought (the sort of thing personal websites that nobody else reads are perfect for). As a web developer, something I’ve noticed when interviewing candidates and hearing how they do things, or when I myself am being assessed in expectations reviews is that our industry seems obsessed with discussing the organisation of work. You know – PR review protocol, agile ceremonies, organising a Trello board, automation, linters. All of which is really important, of course. But the amount of airtime that gets leaves me frustrated. What about the actual job?

Are responsive strategy, web typography, layout, interactive JS components, animation (to name but a few very high-level topics) not interesting, complex and impactful enough as to warrant a higher percentage of the conversation? I want an insight into other folks’ knowledge of and opinions on how best to build things, and feel it gets relegated behind organisational topics.

Or do people just see the nitty-gritty stuff as the domain of enthusiasts on Twitter and personal blogs, or as “implementation details” that are secondary to the organisation of something – anything – that will “get the job done”?

As I say, a half-formed thought and probably just reveals my leanings! But writing it helps me gather my thoughts even if I eventually decide I’m in the wrong.

Brad breaks down the good, bad and ugly of web components but also makes a compelling argument that we should get behind this technology.

I come from the Zeldman school of web standards, am a strong proponent of progressive enhancement, care deeply about accessibility, and want to do my part to make sure that the web lives up to its ideals. And I bet you feel similar. It’s in that spirit that I want to see web components succeed. Because web components are a part of the web!

I’m with you, Brad. I just need to find practical ways to make them work.

WebC, the latest addition to the Eleventy suite of technologies, is focused on making Web Components easier to use. I have to admit, it took me a while to work out the idea behind this one, but I see it now and it looks interesting.

Here are a few of the selling points for WebC, as I see them.

With WebC, web components are the consumer developer’s authoring interface. So for example you might add a badge component into your page with <my-badge text='Lorem ipsum'></my-badge>.

Using web components is great – especially for Design Systems – because unlike with proprietary component frameworks, components are not coupled to a single technology stack but rather are platform and stack-agnostic, meaning they could be reused across products.

From the component creator perspective: whereas normally web components frustratingly require writing accompanying JavaScript and depending on JavaScript availability even for “JavaScript-free” components, with WebC this is not the case. You can create “HTML-only” components and rely on them to be rendered to screen. This is because WebC takes your .webc component file and compiles it to the simplest output HTML required.

WebC is progressive enhancement friendly. As mentioned above, your no-JS HTML foundation will render. But going further, you can also colocate your foundational baseline beside the scripts and CSS that enhance it within the same file.

This ability to write components within a single file (rather than separate template and script files) is pretty nice in general.

There are lots of other goodies too such as the ability to scope your styles and JavaScript to your component, and to set styles and JS to be aggregated in such a way that your layout file can optionally load only the styles and scripts required for the components in use on the current page.

Useful resources:

• WebC docs
• Crash course video tutorial
• Progressively enhanced interactive components video tutorial

I’ve never properly understood when you would need to use the ARIA presentation role. This is perhaps in part because it is often used inappropriately, for example in situations where aria-hidden would be more appropriate. However I think the penny has finally dropped.

It’s fairly nuanced stuff so I’ll forgive myself this time!

You might use role=presentation in JavaScript which progressively enhances a basic JS-independent HTML foundation into a more advanced JS-dependent experience. In such cases you might want to reuse the baseline HTML but remove semantics which are no longer appropriate.

As an example, Inclusive Components Tabbed Interfaces starts with a Table of Contents marked up as an unordered list of links. However in enhanced mode the links take on a new role as tabs in a tablist so role=presentation is applied to their containing <li> elements so that the tab list is announced appropriately and not as a plain list.

Max Böck just tweeted his excitement about htmx:

htmx (and similar "HTML over the wire" approaches) could someday replace Javascript SPAs. Cool to see a real-world case study on that, and with promising results

There’s similar excitement at my place of work (and among the Rails community in general) about Turbo. It promises:

the speed of an SPA without having to write any JS

These new approaches are attractive because they let us create user interfaces that update the current page sans reload – usually communicating with the server to get swap-in content or update the database – but by writing HTML rather than JavaScript. Developers have long wished for HTML alone to handle common interactive patterns so a set of simple, declarative conventions really appeals. Writing less JavaScript feels good for performance and lightening maintenance burden. Furthermore the Single Page App (SPA) approach via JS frameworks like React and Vue is heavier and more complicated than most situations call for.

However I have some concerns.

I’m concerned about the “no javascript” language being used, for example in articles titled Hotwire: reactive Rails with no JavaScript. Let’s be clear about what Turbo and htmx are in simple material terms. As Reddit user nnuri puts it in do Hotwire and htmx have a commitment to accessibility? the approach is based on:

a JavaScript library in the client's browser that manipulates the DOM.

Your UI that uses htmx or Turbo is dependent on that JS library. And JS is the most brittle part of the stack. So you need to think about resilience and access. The htmx docs has a section on progressive enhancement but I’m not convinced it’s part of the design.

Secondly if you have client-side JS that changes content and state, that brings added accessibility responsibilities. When the content or state of a page is changed, you need to convey this programatically. We normally need to handle this in JavaScript. Do these solutions cover the requirements of accessible JS components, or even let you customise them to do add the necessary state changes yourself? For example when replacing HTML you need to add aria-live (see also Léonie Watson on accessible forms with ARIA live regions).

Another concern relates to user expectations. Just because you can do something doesn’t mean you should. For example, links should not be used to do the job of a button. If you do, they need role=button however this is inadvisable because you then need to recreate (and will likely miss) the other features of a button, and will also likely confuse people due to mismatches between perceived affordance and actual functionality. Additionally, as Jeremy Keith has written, links should not delete things.

In general I feel the message of the new HTML over the wire solutions is very weighted toward developer experience but doesn’t make user experience considerations and implications clear. Due to unanswered questions regarding accessibility I worry that firstly they’re not natively mature in their understanding and approach on that front, and secondly that their framing of benefits is likely to make accessibility ignored due to engineers thinking that they can totally rely on the library.

I’d be really pleased if my concerns could be allayed because in general I like the approach.

Update 30/1//22

I decided to revisit a book I read back in 2007 – Jeremy Keith’s Bulletproof Ajax. I had forgotten this, but it actually contains a section titled “Ajax and accessibility”. It acknowledged that reconciling the two is challenging and despite listing ideas for mitigating issues, it admitted that the situation was not great. However since 2007 – specifically since around 2014 – WAI-ARIA has been a completed W3C recommendation and provides a means of making web pages more accessible, particularly when dealing with dynamic content.

I don’t often have cause to use more than a few go-to ARIA attributes, however here’s my understanding of how you might approach making Ajax-driven content changes accessible by using ARIA.

To do: write this section.

References:

• ARIA Live Regions on MDN

This article is a couple of years old but just popped up on my radar again. UX Designer Alex Chen asserts that arguments which pit accessibility against aesthetics create a dangerous false equivalence… and I agree.

The article claims that if we are “too accessible” we will meet the needs of the minority but end up hurting those of the majority. This creates a false equivalence between having legitimate access needs and having a preference for a certain aesthetic.

Alex goes on to praise examples where accessibility is used to drive aesthetics – such as the Eames leg splint and GOV.UK’s design system – as opposed to considering the two ideals opposites or that one needs sacrificed for the other.

Something I’ve found interesting while reviewing recent code test submissions (within job applications) at work is that more developers than I’d expect still use display: inline-block when they need to lay out multiple elements horizontally such as the items in a navigation menu. It’s interesting because Flexbox – which has now been around for almost 10 years – gives you a modern, purpose-built solution to that.

Of course, there is no crime in taking the inline-block approach. It’s an option. And I did take a moment just to challenge my assumptions. But having given it a little thought, I am pretty convinced that Flexbox is the better approach and so I think their choice is worth a query.

Here’s why I think Flexbox is much better:

1. Modern CSS layout is purpose-built for constructing multi-element layouts. Older methods were lacking, quirky and slightly hacky. Using (and knowing to use) purpose-built tools is generally a good thing for reliability, predictability and scalability.
2. Modern CSS layout provides more control, because it’s fundamentally different. You get a parent context (the flex container or grid) that lets you style the context (with gap, for example). We didn’t have this before.
3. Styling a context rather than individual items plays better with modern component-oriented organisation and ideas. It‘s good to keep components encapsulated and context-agnostic, handing off layout to separate, fit-for-purpose tools.
4. Flexbox is built for responsiveness, i.e. built for the modern era. inline-block was not.
5. the default align-items:stretch means that items laid out in a row are automatically full parent-height which is often desirable for larger touch targets and achieving hover styles.
6. inline-block retains some of the properties of inline that are undesirable for this type of use-case. Who can be bothered with whitespace in the code appearing on the screen, or having to work with vertical-align when you don’t need to.

I also don’t see any reason to not use Flexbox. It’s conventional (see for example navigation menus on BBC, Tetralogical), recommended by CSS experts (Rachel Andrew, Jen Simmons etc), performant and well-supported by browsers. You are not going “fancy”, “cutting edge” or “overkill” by using Flexbox. For the “horizontal menu” use case, it’s simply a more suitable choice than the older alternatives.

Related: Chris Coyier’s article When do you use inline block is an excellent investigation into whether any necessary uses for inline-block remain. I reserve the right to change my mind on this, but aside from the “apply transform to an inline element” use case I can’t really see any that have not now been superseded.

I’ve written previously about the important differences between buttons and links. While reviewing some “component refresh” design mocks at work yesterday I noticed the designs were a bit unclear in this regard so I sent the designers a little decision-tree, which I’m noting here for future reference.

It’s important both for our users and for us as practitioners to distinguish between links (the <a> element) and the <button> element. The reason I push this is because they’re fundamentally different functionally, which has important usability implications. Users expect to use mouse, keyboard, browser back-button and assistive tech differently for links than they do for <button>s. And if they can’t visually distinguish one from the other, they’ll try things they expect to work then get confused when they don’t work.

I think this is an area where design and materials can’t be considered separately and need a joined-up approach.

Here’s a flow I hope is helpful.

Ask: does it…

1. take the user to another page? Then it’ll be a link – the <a> (anchor) element.
2. cause something to change on the current page, or submit a form? Then it’ll be a button – i.e. the <button> element.

If it’s a link (<a>):

• it should be underlined so people know it’s a link
• it should have a hover state, for example stay underlined but change colour
• in cases where it’s a CTA you might choose to design it to look button-like and remove some standard link affordances. Just be aware you’re only “calling” it a button. In real user-experienced terms, it’s still a link.
• it does not natively have a disabled state. We shouldn’t be disabling links.

If it’s a button (<button>):

• it should look like a button, i.e. like a pill or rectangle
• It should not look like a link – that’d confuse users into thinking it takes them to another page.
• So it shouldn’t be underlined by default or on hover. It should have some other hover state.

Testing the decision tree

Let’s take the example of a control for launching a modal dialogue.

The obvious choice is a button, because the control causes something to change on the current page. In this case it causes a dialogue to appear on the current page.

Some might argue that it could be a link. This is usually influenced by the fact that dialogues are often (perhaps inadvisably) used as a kind of “fake page”. And to get someone to a “page” we use a link, right? Advocates of the link option might also have progressive enhancement in mind. If they present a link either to a named fragment further down the page or to a separate page, that offers a resilient baseline experience regardless of whether or not JavaScript is available. The idea is that they also have JavaScript to enhance the link when the user’s environment supports it, perhaps adding role=button.

However a button is the more accessible and user-friendly approach for launching the modal.

• Adrian Roselli on stackoverflow
• Adrian Roselli conversation with Jeremy Keith
• Other Adrian Roselli musings on Jeremy’s post
• Chris Ferdinandi on a progressive enhancement approach which replaces a link with a button

Accessible names are used by assistive technologies to refer to elements on a web page. Hidde tells us how to word them so that they are more useful.

Because of how we use accessible names, we want to keep them functional and avoid naming controls after what they look like. Ideally, you do this in the imperative form, that makes it easiest to quickly grasp what a thing is going to do.

My summary of Hidde’s top tips is:

• Name after function rather than form (“Open navigation” over “Hamburger”)
• Put the most unique part first as this makes it more easy to distinguish between elements (so “Midnight Marauders - Album” rather than “Album - Midnight Marauders”)
• Be concise – keep a name to the most important 1-3 words
• No roles as part of the name (for example don’t include the word ‘button’ or nav. The browser already handles this part so it’d be redundant and annoying)
• Start names with a capital letter and don't end with a full stop, because a name is not a sentence
• Avoid ARIA if you can just use good element text content

By day I’m currently working on our Design System’s Table component. In order to achieve a design spec where the table has no bottom-border I needed to set:

1. all cells in the final row of the <tfoot> to have no bottom-border; but also
2. if there is no <tfoot> then set all cells in the final row of the <tbody> to have no bottom-border.

Modern CSS’s support for writing selectors which traverse the DOM up, down and sideways is pretty amazing here.

I’ve gone with:

tfoot > :last-child td, tbody:not(:has(+ tfoot)) > :last-child td { border-bottom-width: 0; }

(Some BEM stuff renamed for brevity but that’s the gist of it)

In the past we’ve had to bloat the backend layer with complex and awkward logic that adds “convenience classes” like .fe-Table-bodyLastRow but as Eric Meyer has been saying :has() in particular is going to remove the need for those convenience classes.

Hat-tip to Jhey Tompkins for his excellent recent article on :has which was a great help.

Although I don’t work on native apps, I’ve recently been wondering about how accessibility considerations for them compare to those for websites. So this is a timely and useful reference.

iOS provides a lot of accessibility behavior for free, so it’s a great start to making a mobile application accessible. Unfortunately, accessibility is more complicated than the iOS behavior can address, and using only default behavior can actually cause the app to have additional issues.

My colleague Anda and I just had a good conversation about tabs, and specifically the company’s tabs component. I’ve mentioned before that our tabs are unconventional and potentially confusing, and Anda was interested to hear more.

What’s the purpose of a tabbed interface?

A tabbed interface is a space-saving tool for collapsing parallel content into panels, with one panel visible at a time but all accessible on-demand. While switching between tab panels the user is kept within the same wider context i.e. the same page, rather than being moved around.

Conventional tabbed interfaces

Here are some great examples of tabs components.

• Inclusive Components – Tabbed Interfaces
• Tabs component in GOV.UK Design System
• ARIA Tabs by Adrian Roselli

Tabs are a device intended to improve content density. They should deliver a same-page experience. Activating a tab reveals its corresponding tab panel. Ideally the approach employs progressive enhancement, starting as a basic Table of Contents. There’s quite a lot of advanced semantics, state and interactivity under the hood.

Faux tabs

But in our Design System at work, ours are currently just the “tabs” with no tab panels, and each “tab” generally points to another page rather than somewhere on the same page. In other words it’s a navigation menu made to look like a tabbed interface.

I’m not happy with this from an affordance point of view. Naming and presenting something as one thing but then having it function differently leads to usability problems and communication breakdowns. As the Inclusive Components Tabbed Interfaces page says:

making the set of links in site navigation appear like a set of tabs is deceptive: A user should expect the keyboard behaviors of a tabbed interface, as well as focus remaining on a tab in the current page. A link pointing to a different page will load that page and move focus to its document (body) element.

Confused language causes problems

One real-life problem with our tabs is that they have been engineered as if they are conventional tabs, however since the actual use case is often navigation the semantics are inappropriate.

We currently give each “tab” the ARIA tab role, defined as follows:

The ARIA tab role indicates an interactive element inside a tablist that, when activated, displays its associated tabpanel.

But our tabs have no corresponding tabpanel; they don’t use JavaScript for a single-page experience balancing semantics, interactivity and state as is conventional. They’re just navigation links. And this mismatch of tabs-oriented ARIA within a non-tabs use case will do more harm than good. It’s an accessibility fail.

A stop-gap solution

If content for one or more tabpanel is provided, apply the complicated ARIA attributes for proper tabs. If not, don’t. This means we allow component consumers to either create i) a real tabbed interface, or ii) “a nav menu that looks like tabs” (but without any inappropriate ARIA attributes). I don’t agree with the latter as a design approach, but that’s a conversation for another day!

Tabs in the future

Some clever people involved with Open UI are using web components to explore how a useful tabs element could work if it were an HTML element. Check out the Tabvengers’ spicy-sections component. Again, this is based on the conventional expectation of tabs as a same-page experience for arranging content, rather than as a navigation menu. And I think it’d make sense to stay on the same path as the rest of the web.

Yesterday the Design System team received a tentative enquiry regarding making table cells editable. I’m not yet sure whether or not this is a good idea – experience and spidey sense tell me it’s not – but regardless I decided to start exploring so as to base my answer on facts and avoid being overly cautious.

In my mind’s eye, there are two ways to achieve this:

1. on clicking the cell, the cell content is presented in an (editable) form input; or
2. apply the contenteditable attribute

In both cases you get into slightly gnarlier territory when you start considering the need for a submit button and how to position it.

I don’t have anything further to add at the moment other than to say that if I had to spike this out, I’d probably start by following Scott O’Hara’s article Using JavaScript & contenteditable.

I’d probably also tweet Scott and ask if he can say anything more on his closing statement which was:

I have more thoughts on the accessibility of contenteditable elements, but that will also have to be a topic for another day…

Update 27-09-22: I’ve also remembered that (if I were to pursue Option 1: input within cell) Adrian Roselli has an article on Accessibly including inputs in tables.

learn about semantic HTML, accessibility, and how using ARIA attributes can sometimes do more harm than good.

Alongside all the sound accessibility and hiding-related advice, I also found Manuel’s approach to progressive enhancement interesting. Rather than i) include a hamburger button directly in the DOM and set its initial state to hidden; or ii) create the button element with JavaScript, he instead nests the button in a template element then clones that element with JavaScript. He later tweeted his rationale for this approach:

If JS doesn't work, the markup inside the template won't be rendered on screen and it's more convenient to prepare the markup upfront instead of using document.createElement().

The ability to prepare complex, JS-dependent component markup upfront in declarative HTML rather than recreating it in JavaScript is a compelling argument for his approach. Especially so if you don’t work in JS framework-based systems therefore your components are not written in JavaScript.

Had such a good day yesterday @weoutherefest with Tom, Jason and Craig. In the afternoon we checked Enny, Sally Rodgers (A Man Called Adam) and Aletha. We then stopped for a short break to sample the food and drink (Char Sui Vermicelli from the NAM stall and a break from beer for a cracking coffee). Our nighttime choices were Bake, Charlie Dark, Pearson Sound and Alex Nut.

The absolute highlight was Charlie Dark in the forest. Amazing woodland setting and a killer set! Charlie has such great energy both on the decks and on the mic. He played a mix of house, techno, disco and broken biznizz – right up my street! Great mixing too (aided by his old-school lollipop headphone).

Time for Round Two!

Great tip here from Jhey. He advises using a button with ARIA and a little JavaScript for your dark-mode toggle. And to apply the dark styles, use a CSS selector which targets the :root parent of the button when in “pressed” state and sets a root-level custom property to “on”.

:root:has([aria-pressed=true]) {
  --dark:1;
}

Seriously clever stuff!

And aside from the CSS, I really like the way Jhey advocates using a button rather than a form element such as a checkbox for this kind of interface, much like Léonie did recently.

Back in June I attended CSS Day in Amsterdam. One of my favourite talks was The CSS Cascade – A Deep Dive by Bramus van Damme. Bramus covered everything we wanted to know about the cascade but were afraid to ask! And that included an introduction to CSS Cascade Layers – the latest game-changing CSS feature.

I previously enjoyed Stephanie Eckles’s article Getting Started with CSS Cascade Layers so my interest was already piqued. However seeing Bramus’s talk in person really helped bring home the practical benefits of CSS layers.

For example, currently if we have the selectors ul[class] defined early in the “reset” section of our styles and .nav defined later in a “components” section, the former selector wins due to its higher specificity. That’s not what we want – we want our component styles to override our global styles. This has previously led people to hack around the problem by adding extra specificity to the latter selector, or by wrapping :where() around the former to decrease its specificity, neither of which are desirable. With layers we can do:

@layer reset, components;
  
@layer reset {
  ul[class] {
    /* set margin to 0 here */
  }
}
  
@layer components {
  .nav {
    /* give .nav ul custom margins */
  }
}

And .nav gets that higher specificity that we want.

I also like that layers align well with an ITCSS approach.

Taking layers for a spin

Cascade Layers are relatively newly-supported in browsers but pretty all-or-nothing in CSS terms to the extent that using them in a progressively-enhanced approach isn’t really an option. So I wouldn’t yet advocate using Layers on an important production website. However there’s nothing to stop me test-driving them on my personal site. Users on old browsers still get the essential content (although very few styles) and for this site, that’s good enough. So I’ve taken the plunge.

And it’s working really well already! Recently while rewriting some CSS I found that if the top of my styles featured a reset which disabled margins on h2 but I also wanted an h2 to take on margins when used within a low-specificity flow utility, the reset style was winning and that was frustrating. But when I moved my reset styles into a reset layer and my layout styles into a layouts layer with the layer order set as reset, layouts then the layout styles win! Really cool.

At our fortnightly Accessibility Forum at work, we just had a great discussion about modal dialogues. We started by discussing whether focus should be completely trapped within the modal or if the user should at least have access to the browser toolbar (we decided on the former). We then moved onto a general discussion on the pros and cons of modals, which led me to share MODALZ MODALZ MODALZ with the team.

Adrian Egger’s website presents some interesting suggestions, which I’ll summarise below:

Have you considered using the following alternatives to modals?

• Non-modal dialogs (e.g. toasts): for non-critical interactions that don’t block the user, use these rather than modals
• New page: lead the user to a different page to isolate the interaction without losing access to functionality such as navigation.
• Go inline: present your content inline to be less disruptive.
• Expanding elements: Use expanding elements such as accordions, toolbars, tooltips, or sliding sidebars (or other modeless elements).
• “Undo” patterns: instead of confirmation modals, consider using inline “Undo” option to speed up the user’s interactions.

When all else fails here’s how to get modals right:

Do:

• Make it easy to close: make it simple to get rid of ‐ by escape key, clicking outside the modal window, and a clearly labelled close button.
• Single purpose: limit the interaction to one, straightforward task.
• Keep it short: be brief and concise in your content
• Accessibility: this is fairly self-explanatory — if you can’t make it accessible, don’t use a modal.

Do not:

• Modal inception: avoid opening a modal from a modal.
• Fullscreen modals: you might as well navigate to a new page.
• Multi-step modals: never create a multi-step modal. That way madness lies.
• Self-spawning modals: never present modals unless prompted by the user.
• Marketing modals: seriously, nobody wants that sh*t — especially not your newsletter.

Modals are so hard to do well and present so many possible issues that I think before diving into designing/building one, it’s worth questioning if a modal is really appropriate for your use case.

At work we’ve recently been shown a couple of design proposals where truncation was presented as a solution to the perceived problem of long and unwieldy content, for example a long description in a table cell. However following good discussions, as a wider team we’re now leaning towards avoiding truncation as an approach. Truncation can present accessibility issues and as Karen McGrane says truncation is not a good content strategy. I reckon we should just let long content wrap, and design for that to look OK.

And when natural wrapping doesn’t cut it – like when you’re tackling very long words in confined spaces – reach for overflow-wrap: break-word as suggested in Ahmad Shadeed’s excellent Handling Short And Long Content In CSS.

In this video we go over the 3 pro tips from Liam Pitchford that helped transform Dan’s backhand!

My backhand is kinda shaky at the moment and I struggle with correct elbow and wrist position so this tutorial video is timely and helpful.

The :has() CSS pseudo-class represents an element if any of the selectors passed as parameters match at least one element. But, it's more than a "parent" selector. That's a nice way to market it. The not so appealing way might be the "conditional environment" selector. But that doesn't have quite the same ring to it. How about the “family” selector?

The CSS :has() pseudo-class is a game-changer and can do more than act as a parent selector, as Jhey illustrates.

Tetralogical are doing a great series of articles on running inclusive research. Their latest is about recruiting participants and covers whether you should recruit people with disabilities as part of your testing and if so who, and how many, and how to recruit them.

Previous articles addressed moderating usability testing sessions with people with disabilities, and analysing findings from inclusive user research.

Just had a memorable experience with Jason and Tom catching Herbie Hancock at the Edinburgh Festival. At 82 years old he still has amazing energy and capped his performance with a tour of the stage playing his keytar followed by a scissor jump!

Herbie’s piano playing was mesmerising – the solos really took me to another place and if this is how he plays in his eighties I can only imagine how good his gigs were in his prime. I also loved his warm anecdotes, including one about his friend Wayne Shorter just before treating us to a rendition of Footprints.

Other highlights included Cantaloupe Island, the mindbending Actual Proof and hearing guitarist Lionel Louke coax sounds from a guitar that you wouldn’t think possible.

Like most folks we didn’t holiday abroad during 2020 and 2021, when COVID was at its height. Trips abroad are a luxury and privilege so this was no hardship. However I’ll admit that once restrictions were lifted and things felt safer, we were pretty excited to head for some sun and good food, and set our sights on a first trip together to the south of France.

The location

We spent seven nights at Désir de Provence, hosted by owners Sylvie and Igor.

Dining out

La Bastide Bleue restaurant, Séguret.

Hotel Montmirail in Vacqueyras.

Beautiful local wine at Domaine Mathiflo in Suzette (right in the heart of the countryside).

Les Ramparts in Venasque – incredible nighttime view over the mountains

Monsieur Tu at L’isle sur la Sorgue, where we had a lovely meal of fish and wine by the canal.

Chez Serge in Carpentras.

Other highlights

Antiques market at Carpentras.

A day walking around the towns of Gigigondas, Seguret and Vaison La Romagne.

St Remy de Provence on a Wednesday morning for a fantastic market.

Carrieres Lumieres (caves featuring art installations) which was amazing.

Aix en Provence. Vasarely Foundation for Kinetic art. Lovely shops and vibe.

Chateau du Barroux was a stunning hilltop location with a castle, cobbled streets, a chapel and incredible panoramic views of the surrounding region including Mont Ventoux.

L’isle sur la sorgue – a lovely town which had an antiques market that blew Clair’s mind!

If we had more time

Hopefully on a future stay in the area we can visit Gord, Russelet (“the Colorado of Provence”), and Nimmes.

Our Design System team has recently received “new component requests” for some custom filtering controls. These look like custom-styled <select>s however their “options” appear more like checkboxes and radio buttons. I think the inspiration was Carbon Design System’s Dropdown component and the idea is to bring consistency to filtering controls in forms. Although it’s not yet time to fully explore this and make a yay/nay decision on the request, I’ve been doing some initial thinking.

(Note: this post is kinda a journey and work-in-progress. I’ll return to complete it and tidy up. For now it serves as a handy log of my research.)

When this was first mooted without guide designs, I assumed we’d be making a custom select. Filament Group have previously shown how to style one of those, although that only affects the “trigger” part. CSS can’t yet style the options. That then led me to check in on the progress of Open UI’s selectmenu element which does support styling the options however it appears that it’s far from road-ready.

However then I saw the designs and realised that while the outside looks like a select, the options look like a group of checkboxes or (kinda) like radio buttons, rather than typical <select> options. And of course the checkboxes and radio buttons themselves are custom-styled.

This led me to reading the following resources.

• Under-engineered multi-selects
• Under-engineered select menus
• Under-engineered custom radio buttons and checkboxen
• Inclusively Hiding & Styling Checkboxes and Radio Buttons

Léonie Watson’s post Perceived affordances and the functionality mismatch is also looming large in the back of my mind.

Ana demonstrates how to achieve a range slider effect accessibly, using web standards and without needing to reach for libraries.

As Ana’s tweet explains, this offers a number of features and benefits:

• can drag thumb with JS disabled
• receives focus
• keyboard navigation
• clicking track moves thumb there and changes slider value
• seen as slider in Accessibility panel
• no library needed, so less code in total

I really enjoyed The 15 Minute City by Natalie Whittle.

It presents the idea of modern cities in which residents can reach everything they need – shopping, work, school, green space, transport, exercise, culture etc – within 15 minutes on foot or by bike.

This idea is already working (or making good progress) in cities like Amsterdam and Paris.

And during periods of restriction during the Covid-19 pandemic it’s a way of life that people around the world have been forced to try.

There are numerous potential benefits of the idea – for example for physical and mental health, the environment, gaining more family and social time from less commuting, boosting neighbourhood economies through shopping local and so on.

On the other hand the 15-minute idea arguably favours the middle-class over the working-class, leads to diminished interpersonal skills, and ignores the important role of cities (such as London) in performing a wider, globally-connected role.

I enjoyed the thoughtful exploration of what are the important factors that give somewhere a sense of place. And I loved the chapter on Glasgow – Natalie’s home of the last 3 years and mine for much longer. It considers how past planning decisions in relation to new towns and the M8 motorway have become problematic for the city. It also looks at exciting modern projects such as the bridge to better connect the Sighthill estate on the outskirts to the city centre, and initiatives to revitalise the Clyde riverside.

Since reading this book I’m noticing more and more these matters being “in the air”. Just recently The Guardian’s Big Idea feature asked Should cars be banned from cities? If that gave one perspective on traffic in cities, I recently spoke to a taxi driver who offered another. Taxi drivers are being made to change their cars to hybrid models soon, but feel that the combination of increased outlays and lack of necessary technology and infrastructure make the move prohibitive. It was a reminder that we have to consider the potential effects on lots of different people when planning change.

Léonie tackles the prickly subject of “element re-purposing” in web development. This post follows a fantastic Twitter exchange started by Lea Verou regarding whether the common visual design request for “adjacent but mututally exclusive buttons” should be built as radio buttons or using <button> elements.

Using one element or set of elements (usually because of their functionality) and styling them to look like something else is a common pattern […but…] it creates a mismatch between the actions people expect they can take and the ones they actually can.

Relatedly, Lea has also gathered her post-discussion thoughts and decisions into a blog post What is the best way to mark up an exclusive button group? and shared a new button-group web component!

Meanwhile, Léonie already has a theme-toggle web component on her personal website which demonstrates the use of buttons and aria-pressed.

Thank you so much, Lea and Léonie.

(via @LeonieWatson)

Update July 19/7/22

I just had a twitter conversation with Adrian Roselli where I suggested that the reasons for developers considering radio inputs over buttons for Lea’s use case might be more nuanced than simply misunderstanding HTML. I’m not sure we agreed on that one in the end, however Adrian shared some helpful heuristics when choosing betweeen JS-powered buttons and forms:

A checkbox, radio button, select menu are meant to gather information. The submit button sends the form (whether get, post, or an AJAX call). A button (non-submit) causes a change on the page, such as toggling a control, showing or hiding something, etc. Different context/use.

I think it would help to think of form fields as for forms. Forms that users intentionally submit (no matter if processed client- or server-side). Forms that gather info. Buttons that have states (expanded, pressed, etc) are for manipulation of the current view.

Takeaways:

• Pick the HTML solution that is generally intended for your use case.
• Use a form if you’re gathering information but if you’re not, don’t. There will be exceptions like “filter forms” but that’s an edge case and most forms are not like that.
• Forms are ideally things that users intentionally submit, via a submit button. This helps rule out “clever forms” as an option.
• Use a button to cause a change on, or manipulate, the current page.

I’ve started trialling different HTML and technologies for the “simple” responsive images (i.e. not art-directed per breakpoint) used in blog articles on this site. I’m continuing to lean on Cloudinary as my free image host, CDN and format-conversion service. But at the HTML level I’ve moved from a complicated <img srcset> based approach that includes many resized versions of the same image. I now use a simpler <picture> and <source> based pattern that keeps the number of images and breakpoints low and instead – by using the source element’s type attribute – takes advantage of the performance gains offered by the new avif and webp image formats.

My new approach is based on advice in Jake Archibald’s brilliant article Halve the size of images by optimising for high density displays. Jake explains that the majority of your traffic likely consists of users with high density screens so when we can combine optimising for that and making performance gains in a progressively enhanced way, we should!

Jake offers a “lazy but generally good enough” approach:

Here's the technique I use for most images on this blog: I take the maximum size the image can be displayed in CSS pixels, and I multiply that by two, and I encode it at a lower quality, as it'll always be displayed at a 2x density or greater. Yep. That's it. For 'large' images in blog posts like this, they're at their biggest when the viewport is 799px wide, where they take up the full viewport width. So I encode the image 1,598 pixels wide.

<picture>
  <source type="image/avif" srcset="red-panda.avif" />
  <source type="image/webp" srcset="red-panda.webp" />
  <img src="red-panda.jpg" width="1598" height="1026" alt="A red panda" />
</picture>

So, if you want your images to be as sharp as possible, you need to target images at the user's device pixels, rather than their CSS pixels. To encode a 2x image, I throw it into Squoosh.app, and zoom it out until it's the size it'll be displayed on a page. Then I just drag the quality slider as low as it'll go before it starts looking bad.

Taking Jake’s guidance and tweaking it for my Cloudinary-based context, my recent post April 2022 mixtape included its image like so:

<figure>
  <picture>
    <source type="image/avif" srcset="https://res.cloudinary.com/…/f_avif,q_auto,w_1292/v1654433393/mato_1500_squooshed_mozjpg_xjrkhl.jpg" />
    <source type="image/webp" srcset="https://res.cloudinary.com/…/f_webp,q_auto,w_1292/v1654433393/mato_1500_squooshed_mozjpg_xjrkhl.jpg" />
      <img class="u-full-parent-width" src="https://res.cloudinary.com/…/f_jpg,q_auto,w_1292/v1654433393/mato_1500_squooshed_mozjpg_xjrkhl.jpg" width="1292" height="1292" alt="Side A of the 7-inch vinyl release of Mato’s “Summer Madness" loading="lazy" decoding="async" />
  </picture>
  <figcaption>Mato’s “Summer Madness”, as featured on the mix</figcaption>
</figure>

And my process was as follows:

1. Take a photo (for me, that’ll be on my phone). Without doing anything special it’ll already be wide enough.
2. Apple use the HEIC format. To get around that, do: Share, Copy, open Files > HEIC to JPG, paste and it’ll save as JPG.
3. Drop it into Squoosh and do the following:

• rotate it if necessary
• resize it to 1300 wide (in my current layout 1292 is twice as wide (2 × 646) as the image would need to go, and I just round up to 1300)
• reduce its quality a bit (stopping before it gets noticeably bad)

1. Encode that as a mozjpg which gave the best size reduction and as far as I can tell, is a safe approach to use.
2. Upload to my Cloudinary account then copy its new Cloudinary URL.
3. Prepare the image HTML per the above snippet. The first source tells Cloudinary to use format avif, while for the second source it’s webp, and for the fallback img it’s jpg.
4. Check the rendered image in a browser to confirm that the modern formats are being used.

I’ll DRY-up that HTML into an 11ty shortcode in due course.

I’ve no doubt that I’ll be getting some of this wrong – this stuff gets pretty complicated! For example I note my image file size is still quite large so I wonder if I should be manually creating the avif and webp versions in Squoosh myself to ensure getting the savings that make this approach worthwhile, rather than handing the conversion off to Cloudinary. (However this would mean having to host more images…)

In the meantime however, I’m happy that this approach has simplified the mental overhead of handling modern, responsive blog images, and optimising it can be a work in progress.

Additional references

• Browser support for avif on caiuse.com
• Twitter thread on forthcoming Safari support for avif, and related info

Recently I’ve noticed some developers recommending using the CSS aspect-ratio property directly on images. My understanding of aspect-ratio was that it’s not so much intended for elements like img which already have an intrinsic aspect ratio, but rather for the likes of div which do not. Furthermore, when the goal is to prevent the layout shift that can occur after an image loads we should supply our images with width and height HTML attributes rather than using CSS.

In this timely post, Jake helpfully explains how width and height attributes are used by CSS as presentation hints to automatically set an aspect-ratio that will also, in cases where the attributes were set wrongly, fall back to the image’s intrinsic aspect ratio. Therefore, concentrating on HTML alone is ideal for our content images. My previous approach seems sound but I now know a little more about why.

If I'm adding an image to an article on my blog, that's content. I want the reserved space to be the aspect ratio of the content. If I get the width and height attributes wrong, I'd rather the correct values were used from the content image. Therefore, width and height attributes feel like the best fit. This means I can just author content, I don't need to dip into inline styles.

If it's a design requirement that the layout of an image is a particular aspect ratio, enforcing that with aspect-ratio in CSS can be appropriate. For example, a hero image that must be 16 / 9 – if the image isn't quite 16 / 9 I don't want it messing up my design, I want the design to take priority. Although, if the image isn't actually that aspect ratio, it'll either end up stretched (object-fit: fill), letter-boxed (object-fit: contain), or cropped (object-fit: cover). None of which are ideal.

For a while now I’ve been enjoying this series of bite-sized travel guides from The Guardian, which puts the spotlight on a European town or city and hands over to a switched-on local to share food, shopping, cultural and green space highlights.

Some are more suited to my tastes and budget than others, but overall they’ve been good. And not just for far-flung places – on a recent day-trip east I checked out a number of the stops on their Edinburgh guide and it gave me a great basis for further exploration.

At work I and our team just had an interesting realisation about a recent conversation. We had been discussing progressive enhancement for custom toggles and a colleague mentioned that the web app in question breaks at a fundamental level if the user has disabled JavaScript, displaying a message telling them to change their settings in order to continue. He used this to suggest that any efforts to provide a no-JavaScript experience would be pointless. And this fairly absolute (and on-the-surface, sensible) statement caught me off-guard and sent me and the others down a blind alley.

I remember replying “yes, but even still we should try to improve the code by introducing good practices” and that feeling a little box-ticky.

However in retrospect I realise that we had temporarily made the mistake of conflating “JavaScript enabled” with “JavaScript available” – which are separate possibilities.

When considering resilience around JavaScript, we can consider the “factors required for JavaScript to work” as layers:

1. is JavaScript enabled in the user’s browser?
2. is the JavaScript getting through firewalls? (it recently didn’t for one of our customers on the NHS’s network)
3. has the JavaScript finished loading?
4. does the user’s browser support the JavaScript features the developers have used (i.e. does the browser “cut the mustard”?)
5. is the JavaScript error-free? It’s easy for some malformed JSON to creep in and break it…

And the point my colleague made relates to Layer 1 only. And that layer – JavaScript being disabled by the user – is actually the least likely explanation for a JavaScript-dependent feature not working.

So it's really important to remember that when we build things with progressive enhancement we are not just addressing Layer 1, but Layers 2—5 too (as well as other layers I’ve probably forgotten!)

Roderick E.J.H. Gadellaa, author of the Webventures blog writes that at their June 2022 Worldwide Developers Conference (WWDC) Apple announced that it will bring Web Push (web-based push notifications) to Safari, including iOS Safari.

MacOS is going to get it first and iOS will receive it in a later iOS 16.x update, sometime in 2023.

This could be a big deal, because…

The lack of the web being able to do push notifications on iOS is probably the biggest reason why web developers see a potential project end up being built as a native app instead of a web app

…and…

Web Push on iOS will change the “we need to build a native app” decision.

I don’t like the idea that native mobile apps are superior to mobile web experiences, nor the notion that by having a native app you can ignore your small-screen web experience. PWAs and native apps can co-exist in harmony and address different use cases. But also web APIs are becoming more powerful all the time, and this announcement by Apple provides fuel for the argument that “you might not need a native app for that!”

I’ve started reading The New Breed: How to think about robots, by Kate Darling.

Keith Cirkel of Github has written about how they think about browsers and it’s interesting. In summary Github achieve:

• improved performance;
• exploiting new native technologies; and
• universal user access/inclusion

…via a progressive enhancement strategy that ensures a basic experience for all but delivers an enhanced experience to most. Their tooling gets a bit deep/exotic in places but I think the basic premise is:

1. decide on what our basic experience is, then use native HTML combined with a bare minimum of other stuff to help old browsers deliver that; and
2. exploit new JS features in our enhanced experience (the one most people will get) to make it super lean and fast

Pretty cool.

The idea of accessibility literacy (having the right vocabulary, knowing the trustworthy info sources etc) makes sense.

The section on Accessibility ignorance and ableism presents some home truths about organisational attitudes to accessibility that need addressed.

Accessibility ignorance actually goes beyond just a lack of accessibility literacy. Accessibility ignorance is a facet of ableism, since it causes people to make decisions that actively harm disabled people.

• Accessibility ignorance isn't usually malicious.
• It's assuming that accessibility is taken care of because your organization has an accessibility specialist on staff, or has accessibility "baked in" to a design system.
• It's providing accessibility training for only teams that build products and not people that work in support, legal, operations, leadership, or other parts of the organization.
• It's expecting accessibility work to happen without impacting schedules and roadmaps that didn't originally take accessibility work into account.
• It's assuming disabled people don't use your product.
• It's not hiring disabled people.
• It's hiring disabled people but only to do accessibility work.
• …

The article wraps up with some great advice on cultivating accessibility literacy, and the senior buy-in needed to support it.

Yesterday I read Eric Meyer discussing CSS Cascade Layers and commenting that the speed at which it had transitioned from first public working draft to shipping as a full public release in every major desktop and mobile browser had made his head spin. Amazing stuff and an indicator of the turbo-boosted pace at which modern CSS is now evolving.

It also made me want to properly read up on Cascade Layers, because I knew some of the theory but now wanted to consider using it in practice. I’m no great fan of “cascade-taming” CSS frameworks like BEM and SUIT (although I acknowledge why we have them) so I’m interested to know if Cascade Layers can replace them. Stephanie Eckles’ article is an excellent primer.

I liked the idea of a specifying a stack like this:

@layer reset, base, theme, components, utilities;

You can then write styles into any of those layers at any point in a stylesheet, safe in the knowledge that the original stack definition sets the order of priority rather than the sequence in which we wrote specific styles.

Stephanie also addresses the question of whether we should write every component as a layer, which is something I’ve been considering. She advises that you could… but it’s probably not going to achieve the scoping effect that you want.

layers are not intended to solve scoping or encapsulation of styles. For that, keep an eye on another spec also being authored by Miriam Suzanne for actual native CSS scoping.

Lastly, Stephanie tackles how ready Cascade Layers are to use right now. At the time she wrote the article – January 2022 – the feature wasn’t widely supported, so wasn’t an option. Additionally Cascade Layers can’t really be used as a progressive enhancement because its nature is so all-encompassing and because testing for feature support using @supports isn’t an option.

However like Eric Meyer mentions, a few months is a long time in CSS support! And as I write in June 2022 the browser support picture is currently looking quite healthy. However given that the first browsers to add support were only released a few months ago in February or March of this year, I think we might need to wait a bit longer – maybe til the percentage of users on non-supporting browsers is negligible – before using this on larger, higher-traffic sites.

Nothing to stop us experimenting on our smaller and intranet-based sites, though!

My team will soon be refactoring our modal dialogue component. Ours has a few deficiencies, needs better developer experience and documentation, is not built to our Design System component standards, and could use a resilience boost from some progressive enhancement.

For a long time the best – meaning accessible, framework-agnostic, feature-packed – modal implementations were custom. Specifically:

• Kitty Giraudel’s a11y-dialog; and
• Scott O’Hara’s Vanilla Modal Dialog

However with recent browser advances (especially from Safari), there’s an argument that the time has now come that we no longer need custom solutions and can go native. So we might reach for the native <dialog> HTML element.

However first I think we’d need to make an informed decision regarding our satisfaction with support, based on the updated advice in Scott O’Hara’s article Having an Open Dialog.

Additionally we should definitely be keeping one eye on proposals around the exciting new togglepopup and popup attributes which promise the holy grail of entirely HTML-powered modal dialogues with no JavaScript dependency.

The HTML details element continues to gain fans and get developers’ juices flowing. Scott Jehl recently tweeted:

I love the details/summary HTML elements. So versatile. My favorite part is being able to show a collapsed state from the start without worrying about potential operability issues if JavaScript fails to run (since its behavior doesn't need it).

Scott goes on to describe how creating disclosure widgets (controls that hide and show stuff) with resilience in mind is so much more difficult when not using <details> since it can require complex progressive enhancement techniques. At the very least these involve making content available by default in case JavaScript fails, then hiding it when the disclosure widget script loads successfully, ideally without a jarring flash of content in between.

Like Scott says, the <details> element is different because you can have the content collapsed (hidden) by default without worrying about JavaScript and workarounds since the hidden content can be toggled open natively. That‘s a real superpower… and also makes you wonder: how many different places and different ways might we use this super-element?

GitHub’s use of details

Back in 2019, GitHub caused a flutter by going all-in on <details> to make various interesting UI elements interactive without JS. Muan has co-created a number of components for Github where <details> is used to, for example, open menus. They also shared notes from a talk on this subject. And Chris Coyier for one was impressed and intrigued.

Zach Leatherman’s details-utils

I’ve previously noted Zach Leatherman’s details-utils – a great example of using a web component to enhance an existing HTML element, in this case <details>. The enhancements include:

• animated open/close
• a quantum aspect ideal for responsive design – closed by default on narrow screens, open by default on wide
• and more

And Zach has already used it on the navigation menus on jamstack.org and netlify.com, amongst other use cases.

Notes of caution

• The details element and in-page search by Manuel Matuzovic
• A details element as a burger menu is not accessible on Cloud Four’s blog
• The details and summary elements, again by Scott O’Hara
• Disclosure widgets by Adrian Roselli
• Details and summary are not…
• Details content showing up in find (Ctrl+F)

Alternative approaches

Using a custom disclosure widget put together with JavaScript and ARIA is not the end of the world. In fact I recently tried my hand at a disclosure widget web component and early impressions are that the combination of fast, async ES modules plus native DOM discovery (which you get with web components) might alleviate the “flicker of content” issue I mentioned at the start.

Summing up

I’d been cautious about using details for more than cases matching its intended usage but had started thinking the time was right to take it further – possibly using Zach’s web component. However based on the findings shared in the above Notes of caution section I’ve decided to stay safe to keep the user experience predictable and accessible. The behaviour when the user does an in-page search, and the current browser inconsistencies in announcing the summary as an expand/collapse button tell me that a custom JS and ARIA disclosure widget is better for the custom UI cases.

Here’s a handy tool from the smart folks at 9elements for making a value – such as a font-size, or margin – fluidly responsive. In their words the tool…

calculates the CSS clamp formula to interpolate between two values in a given viewport range.

It’s inspired by Utopia but is for situations when you only need a single clamp formula rather than one for each interval in a type or spacing scale.

Beyond that, the website for this tool just looks great and is choc-full of tricks. It uses some snazzy CSS, includes Zach Leatherman’s details-utils web component for animated disclosures and is made with Astro, Svelte and PostCSS.

I recently signed up to Vitaly from Smashing Mag’s Smart Interface Design Patterns newsletter. This latest edition regarding “date of birth” inputs was interesting, and well timed as my work colleagues and I are about to revisit our form patterns. It’s a nice explainer on why we should approach UI for dates the user knows differently from UI for dates the user will choose.

Vitaly recommends that when asking the user for a very specific date that they already know without needing to consult a calendar, drop-downs and calendar look-ups are unnecessary. And avoiding them is probably ideal, because <input type=date> and <select> based interfaces have some usability and accessibility kinks, as do many date-picker libraries.

It’s better to rely on three simple, adjacent text input fields with a label above each field. See GOV.UK’s Date input component for a great example.

Date pickers should only be required when you’re asking for a date that the user will choose (say, booking a holiday or appointment) rather than one they’ll know. Vitaly doesn’t recommend a date picker, but I reckon the date-picker web component from the clever folks behind the Duet Design System could be a good option.

Oh, and this also reminds me that I need to get the finger out and pick up a copy of Adam Silver’s Form Design Patterns.

Here’s a handy interactive tool for learning “the logic of great typography” from Erik Kennedy, the man behind the Learn UI Design course.

At work I have to think about complex HTML tables a lot. The challenge with doing tables well is that 99% of online table tutorials use fairly simple examples… whereas in reality design and product teams often want to squeeze in lots more. It’s really hard to balance those needs against accessibility, systemisation, styling and responsiveness.

Heads up: I’ve published this post early while it’s still a work in progress because it’s better for me to have it available for reference than languishing in drafts and forgotten. Apologies if you read it in a temporarily rough state.

Following a lot of work on tables I’ve recently gained additional insight into the possibilities and constraints, thanks to an accessibility review by Tetralogical and some great articles by Adrian Roselli.

Here are my new rules of thumb.

Avoid complex recreations of tables with alternate elements

In addition to developing a component wrapping the HTML table element to handle simple data tables, I recently created an alternate component for “tables with bells and whistles”. It used a combination of the HTML description list element plus CSS Grid plus some display: contents in lieu of the currently poorly supported subgrid. This approach allowed recreating a table-like appearance but facilitating much more responsive layout flexibility, amongst other benefits.

Unfortunately this resulted in an accessibiliy fail around using the description list in this way. Popular combinations of browsers and assistive technologies do not support description lists sufficiently to convey the intended crucial relationships between the faux table headers and faux table cells.

Note: I think it’s OK to use the description list element in general – just not for such an unconventional and complex use case.

ARIA Grid role: an alternative in theory (if not in practice)

I noted that Github handle their “repository directory indexes” using the ARIA grid role. Their HTML is like this (I’ve abbreviated it a touch):

<div role="grid" aria-labelledby="files" class="…">
  <div class="sr-only" role="row">
    <div role="columnheader">Type</div>
    <div role="columnheader">Name</div>
    <div role="columnheader" class="d-none d-md-block">Latest commit message</div>
    <div role="columnheader">Commit time</div>
  </div>
  <!-- interesting 'fake' row here -->
  <div role="row" class="…">
    <div role="rowheader" class="…">
      <a rel="nofollow" title="Go to parent directory" class="…" href="…"><span class="…" style="…">.&hairsp;.</span></a>
    </div>
    <div role="gridcell" class="…"></div>
    <div role="gridcell"></div>
  </div>
  <!-- first real row -->
  <div role="row" class="Box-row Box-row--focus-gray py-2 d-flex position-relative js-navigation-item navigation-focus">
    <div role="gridcell" class="…"><svg …></svg></div>
    <div role="rowheader" class="…">
      <span class="…"><a class="…" href="…">my-file-name.md</a></span>
    </div>
    <div role="gridcell" class="…">
      <span class="…"><a href="…">The commit message</a></span>
    </div>
    <div role="gridcell" class="…">
      <time-ago datetime="2021-06-17T16:45:42Z">11 months ago</time-ago>
    </div>
  </div>
  <!-- more rows go here -->
</div>

I like the idea of looking at alternatives to tables but don’t think I’d take this approach right now. Where there are lots of focusable elements it turns those multiple tab-stops into one (the grid is a single widget) which is perhaps useful for some cases, but I’ve yet to encounter them. It’d also require you to do manual focus management within the widget.

It’s an interesting approach though, and one I’ll keep in the back of my mind.

You can achieve “bells and whistles” within a table accessibly

Here are some handy techniques – done accesibly – courtesy of Adrian Roselli:

• Accessibly including inputs in tables
• Under-engineered responsive tables
• Responsive accessible tables – this more complex approach employs JavaScript to i) apply appropriate ARIA roles to existing table HTML, and ii) create clever alternate labelling using pseudo elements. It uses CSS to change the display of the table and its children to create a small-screen-friendly layout. The JS-applied roles serve to maintain the necessary semantics that would otherwise be lost when applying the radical CSS changes.
• Charlie Cathcart’s responsive table is similar to the above although perhaps less comprehensive. However it might have other interesting aspects.
• Clip long, overflowing content
• Expandable rows
• Fixed headers

References

• Grids pt1: To grid or not to grid by Sarah Higley
• ARIA Grid as an anti-pattern by Adrian Roselli

A while back I bookmarked Michelle Barker’s CSS Grid based overlay technique which neatly allows layering one element atop another using CSS Grid rather than absolute positioning. Now, Stephanie Eckles has taken the idea a step further with her Smol Stack Layout which offers a more flexible markup structure, some intuitive grid area naming and a neat aspect-ratio API.

Stephanie’s component is feature-packed and opinionated to the extent that it took me a while to understand all the moving parts. So for simplicity I’ve created a pared-back version on CodePen: see Layering utility with CSS Grid.

While Michelle’s utility kept the markup really simple with the container doubling-up as the first visual “layer in the cake”, I think for flexibility and robustness I prefer Stephanie’s approach where the container only serves to set the aspect ratio, with the layers represented by two or more child elements.

Layering text upon images

In Smol background picture, Stephanie goes further, leaning on her layering utility to cleverly layer text upon images. This is a modern alternative to the type of effect we previously achieved with background images. It uses a content image marked up using <picture> to progressively enhance the format (heavier-weight jpg for old browsers, lightweight webp for new browsers) and is styled with object-fit: cover in order to perfectly span its container.

This modern approach is great because often from an accessibility perspective our background images should really be content, described properly with alt, to provide equivalent visual and non-visual experiences. Furthermore using a content image tends to be better for performance with there now being so many new image techniques and attributes at our disposal when compared to background images. Lastly, handling the image as content makes it more flexible for styling.

Using Grid for a “Hero” Banner

Another noteworthy member of this family of techniques from Stephanie is her Hero with CSS Grid. Here she uses the same idea of a single grid-template-area with child content and image stacked up in layers, alongside some nifty use of grid positioning properties to align elements within that. This one is very flexible, very responsive, and super-useful.

Summing up

I really like this move away from absolute positioning because it always felt brittle. It doesn’t play well with responsive layouts, and isn’t resilient to cases where adjacent elements could overlap. Furthermore you often see absolute positioning used in conjunction with pseudo elements and while I’ve occasionally taken this approach (and appreciate the creativity behind these techniques) I’ll admit I find it much easier to read and maintain CSS that relates to actual structural elements rather than “magical” CSS elements. I much prefer these simple, modern and fit-for-purpose CSS Grid based approaches.

GitHub have recently done some good work on improving keyboard navigation for (and general usability of) their focusable elements such as links, buttons and form controls by improving focus indication. And then they wrote a short-but-sweet article about it, then tweeted to share that and their work is getting lots of positive recognition from all the right people. Nice job all round, GitHub!

Incidentally, that article they wrote really is very short. Maybe they’ll add to it later. The animated gif they include is very descriptive, mind you. And I noticed that they added the following alt text to it:

Animated gif of a customer using their keyboard to navigate a pull request, interactive UI elements receive a blue focus outline to show current location on the page. Key presses are shown in the bottom center of the image.

That feels like a good non-visual alternative description to me.

By enhancing native HTML instead of replacing it, we can provide a solid baseline experience, and add progressive enhancement as the cherry on top.

Great article by Paul Herbert of Oregon’s Cloud Four. Using a web component to enhance an existing HTML element such as <textarea> (rather than always creating a custom element from scratch) feels very lean, resilient and maintainable.

Off the top of my head I could see this being a nice approach for other custom form controls.

Zach Leatherman also took this approach with the <details> element in quite exciting ways and is using it in production on Netlify’s marketing websites. I’m a bit cautious of jumping on that one just yet, though, because it’s plays more fast-and-loose with the intended purpose of the element and in so doing probably might present some accessibility issues. Still really interesting though.

Thanks to @adactio for sharing.

Recently I’ve been reflecting on what we front-end developers do in the modern era. Working on a design system in 2022, I feel now more than ever that my job represents a convergence of a range of interesting disciplines, goals, skills and experiences. These include UX knowledge and usability testing, a degree of design savvy, systems and atomic thinking, accessibility knowledge and strong skills with the core web standards. That’s my understanding of front-end development.

Yet not long ago a colleague recalled the time a teammate teased him that front-end developers “put the froth on the cappuccino”. While this gave us all a laugh, I imagine it also reflects one common misunderstanding and undervaluing of our role.

Meanwhile there’s another image of front-end development that’s very engineering rather than user experience oriented. This focuses on JavaScript and tooling and arose in the era of NPM and JavaScript frameworks. In this definition, front-end developers spend their time wrangling JavaScript, configuring build tools and manipulating API data.

I’m conscious of the great divide and while my career has straddled that divide, I’ll freely admit that at heart I’m a front of the front-ender.

Here’s a description of a “Design System engineer” that I recently compiled during while my team were recruiting for a software engineer:

• Very strong knowledge and understanding of the core web standards: HTML, CSS and JavaScript
• Strong appreciation of the need for appropriate HTML semantics to achieve resilience and accessibility
• Understands component-based architecture and delivery including concepts like atomic design, composition, variants and versioning
• Advanced understanding of web accessibility including how to create accessible interactive components
• Excellent attention to detail in implementing designs in code
• Strong appreciation of responsive / multi-device considerations
• Comfortable in modern CSS including BEM-like methodologies, ITCSS architecture, and modern approaches such as Flexbox, CSS Grid, custom properties
• Some experience in testing JavaScript and/or server-side components - Comfortable with Git
• Committed to constantly learning and improving technical knowledge and skills

Something else I remember noting down was that:

User interfaces should be user-centric, purpose-driven, appropriate, accessible and consistent (not arbitrary).

I guess my point there was that good front-end developers build user interfaces in a very considered manner.

Areas of interest

Here are some of the key areas I find myself thinking about or working on regularly.

Accessibility

I list this first not due to alphabetical order, but because it’s arguably the cornerstone of our job. That’s for two reasons. Firstly, because the web was designed to be accessible to all therefore it’s incumbent on us to uphold that. (Of course it’s not just our job, however we tend to be both the primary evangelists and last line of defence). Secondly, so many other aspects of front-end development can only be done well when you start from an accessible foundation. This is something that becomes clearer and clearer the longer you do this job.

Resilience

I might add more about this later.

Performance

I might add more about this later.

UX

I might add more about this later.

Documentation

I might add more about this later.

Adaptability

I might add more about this later.

Design System considerations

• Componentization
• Creating component APIs
• Composition
• Documentation

Scalability

At scale, you can’t just write new code for everything. You have to focus on creating reusable things.

Maintainability and sustainability

I might add more about this later.

Integration into the company’s language framework

This can be challenging. I might add more about this later.

Adding interactivity

I might add more about this later.

Adherence to designs, and making things look good.

I might add more about this later.

I put together a fairly spacey and mellow selection of laidback electronic sounds with a little nod to summer.

Download my April 2022 mixtape.

Here’s the tracklist:

• Nale Sinephro - Space 1
• Culross Close - To Belong
• Other Lands - Matter (Reshaped)
• Mato – Summer Madness
• Desmond Chambers – Haly Gully
• Tom Churchill – Cast adrift
• Bright & Findlay — Slow Dance
• Quiet Force — Listen To The Music (Apiento & Tepper Mix)
• Fuga Ronto – Columbo De Domingo
• dreamcastmoe — l foot right
• Lord of the isles — Novwo
• Kofi B - Mmobrowa (Hagan Edit)
• State of grace — That’s when we’ll be free

This was a nice opportunity to get back into the rhythm of programming music of varying styles and tempos. Kit-wise, I used two Technics 1210s, a Pioneer XDJ-700, an Isonoe 420 mixer and an Eventide Timefactor delay.

I’ve started reading The 15 Minute City, by Natalie Whittle.

Some colleagues at work have recently been asking interesting questions about “good/appropriate alternative text for images”. I definitely reckon it’s a topic worth revisiting because it feels like the landscape has changed a bit on this front over the years.

I think the web design industry has traditionally been:

1. lacking knowledge of how to write good alternative text.
2. too quick to decide which images are “purely decorative”, or accurately described by a matter-of-fact short label when maybe they actually should convey their inherent tone and emotion to all users rather than only those with no visual impairments.

But as inclusion-centric practioners we can probably do better. In his blog post Writing great alt text Jake Archibald breaks down the considerations. I reckon it’d be useful for us to dissect this post and try to boil it down to some practical rules-of-thumb for our teams.

But also, I’ve just noticed a couple of interesting developments at the big players. Firstly, Twitter have upped their image alt game and are encouraging their users to try doing so, too.

And hot on the heels of Twitter’s announcement, I now see in Slack an Edit file details option for adding image descriptions. It’s great that Twitter and Slack are doing this… and also serves as a reminder that tools such as Slack and Twitter are consumed on the web and so accessible best practices apply when you’re writing content on them, too!

SVG is an amazing technology which I regularly use for icons and occasionally for logos and illustrations. I’ve also dipped my toe into animated SVG. But if I’m honest I still find some SVG concepts confusing so I’ve gathered some useful tips here for future reference. Note: this is a living document which I’ll expand over time.

Table of contents

• Introduction to SVG
• Canvas, viewport and viewbox
• Arranging elements on a grid
• Inline SVG for icons
• Choose an SVG embedding technique that suits the task
• Choose the best-performing format
• Exporting and optimising SVG in design tools

Introduction to SVG

It’s an image format (like jpg and png) but also an XML-based markup language. So it’s a bit like HTML in that you can “compose a whole from a bunch of parts” – but it is focused on graphics. As a web graphics technology it has many benefits, for example:

• scalable,
• manipulable by CSS and JS,
• has a small file-size if well-optimised, and
• can be made accessible.
• It’s built for drawing in a way HTML and CSS are not.
• It can guide users, reduce their cognitive load, and provide personality and moments of fun.

Here’s a classic example: Log-in Avatar

Canvas, viewport and viewBox

Let’s break down the key elements of the SVG coordinate system.

Canvas

The canvas is the area where the SVG content is drawn. It’s infinite in both dimensions therefore the SVG can be any size.

Viewport

Although the canvas is infinite, the SVG is rendered on the screen relative to a finite region known as the viewport. Areas of the SVG that lie beyond the boundaries of the viewport are not visible. This is similar to a browser viewport. On a long page you don’t see all the content; just a portion of it.

Specify the viewport size by giving your <svg> element a width and height, e.g.:

<svg width="600" height="400">
  <!-- svg content -->
</svg>

We could specify units (such as em or px) but don’t need to. Unitless values are regarded as being set in user space using user units which effectively equate to pixels so our example above renders a 600px by 400px viewport.

The width of the viewport can also be set in CSS. Setting width:100% makes the SVG viewport fluid in a given container.

Viewbox

The viewport coordinate system starts at the top left (0, 0) corner of the SVG viewport. The user coordinate system is by default identical to that of the viewport, starting in the same place and with equal dimensions and units, however it can be modified using the viewBox attribute.

viewBox takes a value in the format: x y width height. The first two values set the upper-left corner of the viewbox and the second two its dimensions.

You can set the aspect ratio of the viewbox to the same as for the SVG viewport, or differently.

You might (optionally) use the viewBox attribute to transform the SVG graphic by scaling or translating it, or to crop it.

Specifying a smaller viewbox than viewport results in cropping the graphic to those dimensions and then zooming it in i.e. scaling it up so that it fills the entire viewport area.

Arranging elements on a grid

Cassie Evans recommends that when planning an arrangement of elements it’s nice to start with a simple grid using nice round numbers such as 100×100 – per the following <svg> – making it easy to then plot elements on top. You might even start by sketching with paper and pencil.

<svg viewBox="0 0 100 100">
  <!-- svg content, perhaps <rect>s -->
</svg>

Inline SVG for icons

Having tried various icon systems including using <symbol> and <use>, Chris Coyier advocates that it’s perhaps simpler and better to just include the icons inline. Perhaps use the appropriate include technique for your stack to keep the code maintainable.

Choose an SVG embedding technique that suits the task

There are a variety of flavours and uses of SVG, including:

• icons
• infographics
• illustrations
• SVG that include text
• SVG that include animation.

As Sara Souidean covers in her talk “A Smashing Case Study”, your choice of SVG embedding technique depends on the nature of the project and the specific use case.

To do: summarise Sara’s technique for SVG with illustration and accessible text.

Choose the best-performing format

When you’re tasked with coding an illustration-based image, it’s tempying to automatically see that as a job for SVG. However keep in mind that for some images the SVG file size will be massive and PNG will perform much better, so compare the two options.

Exporting and optimising SVG in design tools

To export an SVG in Figma, right-click it (or select it on the left hand side) then select “copy as SVG”. There’s also an “export as SVG” option on the right.

References

• Understanding SVG Coordinate Systems by Sara Soueidan
• Swipey image grids by Cassie Evans
• A pretty good icon system by Chris Coyier
• A Smashing Case Study recorded presentation by Sara Souidean

Here’s a new development in the Web Components story, and one that may have positive implications for resilience, performance and progressive enhancement.

Declarative Shadow DOM is a new way to implement and use Shadow DOM directly in HTML rather than by constructing a shadow root in JavaScript.

But some people including Chris Coyier and Brad Frost) reckon that writing that looks horrible. Brad said:

Declarative Shadow DOM always looked gross to me and I felt it almost defeats the purpose of web components.

And Chris added:

the server-side rendering story for Web Components, Declarative Shadow DOM, doesn’t feel very nice to me if you have to do it manually.

However Lit, a library which makes working with Web Components easier, are now providing ways to make this easier when Lit is used with Eleventy.

Brad likes this:

With tools like this (especially this @lit-labs/ssr project), we can have our cake and eat it too: use web components in a dev-friendly way, and then have the machines do the heavy lifting to convert that into a grosser-yet-progressive-enhancement-enabled syntax that ships to the user.

As does Chris:

using JavaScript frameworks in an entirely-client-side rendered way isn’t nearly as good for anything (users, SEO, performance, accessibility, etc) as server-side rendering (the effects of hydration are still debatable, but I view as largely worth it) … [but] the server-side rendering story for Web Components, Declarative Shadow DOM, doesn’t feel very nice to me if you have to do it manually. So… don’t do it manually! Let Eleventy do it!

As an additional footnote, perhaps we can make frameworks other than Eleventy (such as Rails) create server-rendered custom elements with Declarative Shadow DOM in a similar way. One to explore.

Zach tweeted last year to share a codepen which illustrates the very simple boilerplate needed for a minimum viable web component. Note: his example is so simple that in this case the JavaScript isn’t actually needed for the custom element to work, however the provided JS is a starting point for when you do actually intend to add JS-driven features.

The HTML:

<foo-component>Hello, world</foo-component>

foo-component {
  font-size: 4em;
}

customElements.define("foo-component", class extends HTMLElement {
  constructor() {
    super();
    // Add your custom functionality.
  }
});

When Mastermind comes on TV, Clair and I always enjoy competing against each other to see who’s most intelligent / least stupid and always jokingly say we’d fancy our chances in real life (although we really wouldn’t). So I enjoyed Sirin Kale’s amusing memoir on what it’s really like to get in the famous black chair!

It is spotlit, well worn, imposing. Its leather has been burnished by the arses of minds far greater than mine, minds capable of retaining all manner of trivia while staying cool under pressure and not panic-sweating profusely via their bum cheeks on to the seat; cellulite-free grey matter, crammed full of general knowledge like a suitcase you have to sit on to close. My mind, by comparison, is a duffel bag containing a single pair of socks.

Thanks once again to Matt Hobbs and GOV.UK for sharing their website visitor stats publicly so that we can learn from them. As ever, lots of juicy detail in Matt’s thread.

GOV.UK stats for January (1-31):

- Chrome - 45.08%

- Safari - 36.82%

- Edge - 7.38%

- Samsung Internet - 7.08%

- Firefox - 1.35%

- Android Webview - 0.72%

- Safari (in-app) - 0.61%

- Internet Explorer - 0.5%

100% = 187,969,863

#browserstats

—Matt Hobbs, @TheRealNooshu

In particular, their “usage by device type” stats see mobile at ~67%, Desktop at ~30.5%, Tablet at ~2.5%.

In terms of comparative traffic, according to Simliar Web’s Top 10 most visited UK websites list they’re hovering around #10.

Here’s a lovely, short (13 min) interview from an accessibility expert with a really positive outlook—highly recommended.

Q: What’s just one thing that every single person can do in the progression toward an accessible internet?

A: When you’re talking to colleagues, peers… promote the notion that accessibility is just part of what we do because we’re good at our job. It’s not extraordinary, it’s not unusual, it’s not something you can drop because you’re pushing for launch.

Over the last couple of days I’ve been watching an interview with Brad Frost on Storybook’s channel. I’m still only halfway through but it’s great so far.

One part I’m loving is, from about 25 mins in, when Brad talks abut how Atomic Design crucially includes the notion of not only “breaking interfaces down” (like every DS does) but also “building them back up”. It’s not just the atoms and molecules that are important, but also combining them into (in Atomic Design parlance) organisms and templates, too. For example when using Storybook as an internal workshop (in my team our equivalent is LookBook), he makes a point of it not just including components but also templates, so that:

we can internally test with a high degree of confidence before handing over to our user-consumers that when our components are assembled together, they work”.

I like the idea of our workshop containing not just components but also multicomponent arrangements, or even full page templates. It’d mean less need to go arrange this stuff in the consuming application all the time. Brad’s chat also chimes with some recent thoughts I’ve been having about Patterns and also a tweet from Heydon Pickering regarding a catalogue vs a system.

Essentially, I think that in component libraries, notions of hierarchy and composition are really important. Simply having “a catalogue of components” (including lots that are common to all Design Systems) might not hugely separate your library from Bootstrap or Material. However it’s our ability to combine our custom legos into specific higher order arrangements, and our care for making sure they combine together harmoniously that creates our own special sauce.

I recorded a talk on “Hiding elements on the web” for @freeagent’s tech blog. It’s a tricky #FrontEnd & #a11y topic so I try to cover some good practices and responsible choices. Hope it helps someone. (Also it’s my first video. Lots of room to improve!)

Alex Page, a Design System engineer at Spotify, has just asked:

What open-source design systems are built with web components? Anyone exploring this space? Curious to learn what is working and what is challenging. #designsystems #webcomponents

And there are lots of interesting examples in the replies.

I plan to read up on some of the stories behind these systems.

I really like Web Components but given that I don’t take a “JavaScript all the things” approach to development and design system components, I’ve been reluctant to consider that web components should be used for every component in a system. They would certainly offer a lovely, HTML-based interface for component consumers and offer interoperability benefits such as Figma integration. But if we shift all the business logic that we currently manage on the server to client-side JavaScript then:

• the user pays the price of downloading that additional code;
• you’re writing client-side JavaScript even for those of your components that aren’t interactive; and
• you’re making everything a custom element (which as Jim Neilsen has previously written brings HTML semantics and accessibility challenges).

However maybe we can keep the JavaScript for our Web Component-based components really lightweight? I don’t know. For now I’m interested to just watch and learn.

After a couple of years of reading about web components (and a lot of head-scratching), I’ve finally got around to properly creating one… or at least a rough first draft!

Check out disclosure-widget on codepen.

See also my pen which imports and consumes the component.

Caveats and to-dos:

• I haven’t yet tried writing tests for a web component
• I should find out how to refer to the custom element name in JavaScript without repeating it
• I should look into whether observedAttributes and attributeChangedCallback are more appropriate than the more typical event listeners I used

References

I found Eric Bidelman’s article Custom Elements v1: Reusable Web Components pretty handy. In particular it taught me how to create a <template> including a <slot> to automatically ringfence the Light DOM content, and then to attach that template to the Shadow DOM to achieve my enhanced component.

Scott Jehl recently tweeted:

Browser devtools have made redesigning a site such a pleasure. I love writing and adjusting a CSS file right in the sources panel and seeing design changes happen as I type, and saving it back to the file. (…) Designing against live HTML allows happy accidents and discoveries to happen that I wouldn't think of in an unconstrained design mockup

I feel very late to the party here. I tend to tinker in the DevTools Element Styles panel rather than save changes. So, inspired by Scott, I’ve just tried this out on my personal website. Here’s what I did.

1. started up my 11ty-based site locally which launches a localhost URL for viewing it in the browser;
2. opened Chrome’s DevTools at Sources;
3. checked the box “Enable local overrides” then followed the prompts to allow access to the folder containing my SCSS files;
4. opened an SCSS file in the Sources tab for editing side-by-side with my site in the browser;
5. made a change, hit Cmd-S to save and marvelled at the fact that this updated that file, as confirmed by a quick git status check.
6. switched to the Elements panel, opened its Styles subpanel, made an element style change there too, then confirmed that this alternative approach also saves changes to a file.

This is a really interesting and efficient way of working in the browser and I can see me using it.

There are also a couple of challenges which I’ll probably want to consider. Right now when I make a change to a Sass file, the browser takes a while to reflect that change, which diminishes the benefit of this approach. My site is set up such that Eleventy watches for changes to the sass folder as a trigger for rebuilding the static site. This is because for optimal performance I’m purging the compiled and combined CSS and inlining that into the <head> of every file… which unfortunately means that when the CSS is changed, every file needs rebuilt. So I need to wait for Eleventy to do its build thing until the page I’m viewing shows my CSS change.

To allow my SCSS changes to be built and reflected faster I might consider no longer inlining CSS, or only inlining a small amount of critical stuff… or maybe (as best of all worlds) only do the inlining for production builds but not in development. Yeah, I like that latter idea. Food for thought!

At work in our Design System team, we’ve been doing a lot of content and documentation writing for a new reference website. So it was really timely to read Jeremy Keith of Clearleft’s new post on the process of writing Learn Responsive Design for Google’s web.dev resource. The course is great, very digestible and I highly recommend it to all. But I also love this new post’s insight into how Google provided assistance, provided a Content handbook as “house style” for writing on web.dev and managed the process from docs and spreadsheets to Github. I’m sure there will be things my team can learn from that Content Handbook as we go forward with our technical writing.

“Dark mode” has been a buzz-phrase in web development since around 2019. It refers to the ability provided by modern operating systems to set the user interface’s appearance to either light or dark. Web browsers and technologies support this by allowing developers to detect whether or not the OS provides such settings, and if so which mode the user prefers. Developers can create alternate light and dark themes for their websites and switch between these intelligently (responsively?) to fit with the user’s system preference.

I’ve been meaning to do some work on this front for a while and finally got around to it. (You might even be reading this post with your computer’s dark colour scheme enabled and seeing the fruits of my labour.) Here’s how I set things up and the lessons I learned along the way.

Switching your computer’s appearance

On a Mac:

System Preferences > General > Appearance

On Windows:

Colors > Choose your color

On iOS:

Settings > Display & Brightness > Appearance

On Android:

Settings > Dark Theme

Emulating this in browser DevTools

In Chromium-based browsers you can open DevTools, then open the Rendering tool (which might be hidden behind More Tools). In the Emulate CSS media feature prefers-color-scheme dropdown, select prefers-color-scheme: dark or prefers-color-scheme: light.

The theme-color HTML meta tag

You can use the theme-color HTML meta tag to indicate to the browser a colour it can use to customise the display of the page and surrounding elements such as the address bar. The reason we have a meta tag solution to this rather than leaving it to CSS is performance; it allows the browser to make the relevant updates immediately.

In practice you might specify your “highlight colour”—Clearleft currently use their signature green. Alternatively you could specify both your light theme and dark theme background colours, using the media attribute to associate each with the user colour scheme preference it is optimised for. This is the approach I chose.

<!-- Set theme color to white when user prefers light mode -->
<meta name="theme-color" content="rgb(255,255,255)" media="(prefers-color-scheme: light)">
<!-- Set theme color to a custom black when user prefers dark mode -->
<meta name="theme-color" content="rgb(38,38,38)" media="(prefers-color-scheme: dark)">

The theme-color meta tag has mixed support. It works well in Safari and iOS Safari. Meanwhile Chrome only applies the colour on installed progressive web apps (PWAs).

This had me considering PWA matters again for the first time in a while. I previously definined a PWA “theme colour” for my website in my manifest.manifest file. However unlike in the theme-color meta tag approach, the manifest allows defining one theme colour only. While I don’t think there’d be any issue in having both the meta tag and manifest value in play simultaneously (my understanding is that the HTML would take priority over the manifest), I decided to keep things simple and removed theme_color from my manifest file for now.

Note: the w3c manifest spec may support multiple theme colours in future.

The color-scheme meta tag

The color-scheme meta tag is used to specify one or more color schemes/modes with which the page is compatible. Unlike theme-color you don’t provide an arbitrary colour value, but rather one of light or dark or both in combination. This tells the browser whether it can change default background, foreground and text colours to match the current system appearance. As Jim Nielsen notes in Don’t forget the color-scheme property, it gives the browser permission to automatically change standard form controls, scroll bars, and other named system colors.

I include this meta tag on each page (just after my theme-color meta tags). I indicate that my styles have been prepped to handle the browser applying either light or dark colour schemes and—via the order of values in the content attribute—that I prefer light.

<meta name="color-scheme" content="light dark">

Notes:

1. I’ve also seen <meta name="supported-color-schemes"> however Thomas Steiner explained that this is an old syntax and has since been standardised as <meta name="color-scheme">;
2. There is also a color-scheme CSS property, which I’ll come to later. Once again though, having an HTML meta tag helps browsers to apply things faster;
3. although I’m currently intimating that I prefer light, in future I might update this to dark first (assuming I don’t hear of any reasons against it). The dark colour palette is really growing on me!

Ensuring colours are accessible

While working on a new dark colour palette and tweaking my light palette I made sure to check that colour contrast met accessibility requirements.

Useful tools on this front include:

• Activating Chrome’s element inspector (the “box with arrow at bottom-right” icon) enables hovering an element to check the contrast of text against background;
• Erik Kennedy’s Accessible Color Generator provides slightly modified colour alternatives when contrast is insufficient—really handy and I used this a couple of times;
• Are my colors accessible? is another great “check contrast, digest results, then tweak” tool which provides more detailed information than the Chrome inspector, especially regarding the impact of small text on contrast.

Design Tokens

It quickly became clear that I’d need global colour settings that I could use across multiple technologies and multiple files. For example, I’d want to reuse the same custom background colour value in an HTML theme-color meta tag, in CSS, and perhaps also in a JSON-based manifest file.

I’d previously bookmarked Heydon Pickering’s article on design tokens in Eleventy and now was the time to give it a spin.

I created _data/tokens.json in which I defined raw tokens such as colorDark, colorDarker and colorLight.

Then in my Nunjucks-based HTML templates I could access that token data to define meta tag values using {{ tokens.colorLight }}. These values would be interpolated to the real CSS colour values during build.

I also created a new Nunjucks file, theme_css.njk, adding permalink: "css/theme.css" in its frontmatter so that it’d generate a CSS file. This file maps my design tokens to custom properties set on the root element, something like this:

:root {
  --color-dark: {{ tokens.colorDark }};
  --color-darker: {{ tokens.colorDarker }};
  --color-light: {{ tokens.colorLight }};
  --color-grey: {{ tokens.colorGrey }};
  --color-highlight: {{ tokens.colorHighlight }};
  --color-highlight-dark: {{ tokens.colorHighlightDark }};
  --color-highlight-darker: {{ tokens.colorHighlightDarker }};
  --color-text: {{ tokens.colorText }};
}

Custom properties FTW

Using custom properties allowed me to do the hard work of preparing my light and dark themes upfront and removed the need to constantly duplicate values and write code forks throughout my CSS.

Having previously created a base layer of reusable custom property representations of my design tokens, I began creating more specific custom properties to serve different contexts.

:root {
  --color-page-bg-light: var(--color-light);
  --color-page-bg-dark: var(--color-dark);
  --color-ink-dark: var(--color-text);
  --color-ink-light: var(--color-light);
}

CSS for default and dark-mode contexts

Now to set my light-mode defaults and fork these when the user prefers dark-mode.

Here’s my CSS:

:root {
  color-scheme: light;

  --color-highlight: var(--color-highlight-darker);
  --color-page-bg: var(--color-page-bg-light);
  --color-band: var(--color-darker);
  --color-ink: var(--color-ink-dark);
  --color-ink-offset: var(--color-grey);

  @media (prefers-color-scheme: dark) {
    color-scheme: dark;

    --color-highlight: var(--color-highlight-dark);
    --color-page-bg: var(--color-page-bg-dark);
    --color-band: var(--color-darker);
    --color-ink: var(--color-ink-light);
    --color-ink-offset: var(--color-grey);
  }

  accent-color: var(--color-highlight);
}

body {
  background-color: var(--color-page-bg);
  color: var(--color-ink);
}

Let’s break that down.

The color-scheme property allows us to specify one or more colour schemes/modes with which an element is compatible. I’m defining it on the root element i.e. for the whole page. My approach was to start by specifying support for a light colour scheme only, then define background and text colour custom properties with values optimised for light colour scheme.

Using @media (prefers-color-scheme: dark) {…} we can check the user’s colour scheme preference. When the user prefers dark, I change color-scheme to dark to let the browser do its “set sensible defaults” thing, and I update the custom property values to those optimised to blend with a dark appearance.

The reusable, theme-sensitive custom properties I’ve plumped for are:

• highlight colour: really just my brand colour, although lightened a touch in dark mode for better contrast;
• page background colour;
• “band” background colour: something I’d use as a band of alternative background colour to distinguish special sections like the header or footer;
• ink colour: my default text colour;
• “offset” ink colour: a grey for little bits of meta text like dates and categories.

I’m sure I’ll evolve these over time.

Lastly, the accent-colour CSS property is used by some form controls e.g. radios and checkboxes. I set that to my highlight colour with the intention of creating a more branded experience.

SVG considerations

My SVG-based logo didn’t look right in dark mode, however the fix was pretty simple. I applied BEM-style element classes to any problematic path elements of the SVG then wrote CSS for those. The CSS tests for prefers-color-scheme: dark and updates the path’s fill or stroke colour as necessary.

What about leaving everything to the browser?

Having read Jim Nielsen’s brilliant article on CSS System Colors I tried feeding the browser color-scheme: light dark, removing my arbitrary dark theme colours, and leaving the colour palette entirely up to the browser. Along the way I learned some interesting lessons on system colours—which we can also choose to use as valid CSS colours in our custom components—such as Canvas and CanvasText.

I love this idea in principle! However in practice:

• only Safari’s colour palette looks consistent with the rest of the Mac OS. The palette applied by Chrome doesn’t; it has its own, different “black”. So for the control you’ve given away, you don’t necessarily achieve that nice “consistency with the OS” reward in return;
• as far as I know you can’t lighten or darken the system colours so it’s hard to create a multi-tone, complimentary palette, and also be confident in achieving sufficient colour contrast. That’s fine if you only need a single background colour for the entire page with no alternate bands of colour (like on Jim’s blog) however I think that’s a little restrictive. (Maybe I’m getting too hung up on control here though, and introducing additional arbitrary colours would work fine alongside a variable “system black”);
• Firefox and iOS Safari are a little problematic in their support for the technologies involved, leading to writing a few hacky workarounds.

For the combined reasons above I’m sticking with manually defined colours for now (however I have a pull request I can revisit later if the mood takes).

What could I do better?

With extra time, I might:

• think more deeply about dark theme design, perhaps following some of the tips regarding shadows, depth and colour contrast in CSS Tricks’ A complete guide to dark mode on the web;
• consider providing a theme switcher control to allow the user to choose the website theme they want regardless of the current OS appearance. (But I probably won’t; I’m not sure it’s necessary)

References

• Theming, from Jeremy Keith’s excellent Learn Responsive Design
• Design Tokens in Eleventy by Heydon Pickering
• CSS System Colors by Jim Nielsen

Great tutorial (with accompanying video) from Adam Argyle which starts with a useful definition of what a Toast is and is not:

Toasts are non-interactive, passive, and asynchronous short messages for users. Generally they are used as an interface feedback pattern for informing the user about the results of an action. Toasts are unlike notifications, alerts and prompts because they're not interactive; they're not meant to be dismissed or persist. Notifications are for more important information, synchronous messaging that requires interaction, or system level messages (as opposed to page level). Toasts are more passive than other notice strategies.

There are some important distinctions between toasts and notifications in that definition: toasts are for less important information and are non-interactive. I remember in a previous work planning exercise regarding a toast component a few of us got temporarily bogged down in working out the best JavaScript templating solution for SVG icon-based “Dismiss” buttons… however we were probably barking up the wrong tree with the idea that toasts should be manually dismissable.

There are lots of interesting ideas and considerations in Adam’s tutorial, such as:

• using the <output> element for each toast
• some crafty use of CSS Grid and logical properties for layout
• combining hsl and percentages in custom properties to proportionately modify rather than redefine colours for dark mode
• animation using keyframes and animation
• native JavaScript modules
• inserting an element before the <body> element (TIL that this is a viable option)

Thanks for this, Adam!

(via Adam’s tweet)

There’s some nice code in here but the demo page minifies and obfuscates everything. However the toast component source is available on GitHub.

Related links

• A toast to accessible toasts by Scott O’Hara

Warning: this entry is a work-in-progress and incomplete. That said, it's still a useful reference to me which is why I've published it. I’ll flesh it out soon!

There are lots of different strands of web development. You try your best to be good at all of them, but there’s only so much time in the day! Animation is an area where I know a little but would love to know more, and from a practical perspective I’d certainly benefit from having some road-ready solutions to common challenges. As ever I want to favour web standards over libraries where possible, and take an approach that’s lean, accessible, progressively-enhanced and performance-optimised.

Here’s my attempt to break down web animation into bite-sized chunks for ocassional users like myself.

Defining animation

Animation lets us make something visually move between different states over a given period of time.

Benefits of animation

Animation is a good way of providing visual feedback, teaching users how to use a part of the interface, or adding life to a website and making it feel more “real”.

Simple animation with transition properties

CSS transition is great for simple animations triggered by an event.

We start by defining two different states for an element—for example opacity:1 and opacity:0—and then transition between those states.

The first state would be in the element’s default styles (either as explicitly-defined property values or existing implicitly based on property defaults) and the other in either its :hover or :focus styles or in a class applied by JavaScript following an event.

Without the transition the state change would still happen but would be instantaneous.

You’re not limited to only one property being animated and might, for example, transition between different opacity and transform states simultaneously.

Here’s an example “rise on hover” effect, adapted from Stephanie Eckles’s Smol CSS.

<div class="u-animate u-animate--rise">
  <span>rise</span>
</div>

.u-animate > * {
  --transition-property: transform;
  --transition-duration: 180ms;
  transition: var(--transition-property) var(--transition-duration) ease-in-out;
}

.u-animate--rise:hover > * {
  transform: translateY(-25%);
}

Note that:

1. using custom properties makes it really easy to transition a different property than transform without writing repetitious CSS.
2. we have a parent and child (<div> and <span> respectively in this example) allowing us to avoid the accidental flicker which can occur when the mouse is close to an animatable element’s border by having the child be the effect which animates when the trigger (the parent) is hovered.

Complex animations with animation properties

If an element needs to animate automatically (perhaps on page load or when added to the DOM), or is more complex than a simple A to B state change, then a CSS animation may be more appropriate than transition. Using this approach, animations can:

• run automatically (you don’t need an event to trigger a state change)
• go from an initial state through multiple intermediate steps to a final state rather than just from state A to state B
• run forwards, in reverse, or alternate directions
• loop infinitely

The required approach is:

1. use @keyframes to define a reusable “template” set of animation states (or frames); then
2. apply animation properties to an element we want to animate, including one or more @keyframes to be used.

Here’s how you do it:

@keyframes flash {
  0%    { opacity: 0; }
  20%   { opacity: 1; }
  80%   { opacity: 0; }
  100%  { opacity: 1; }
}

.animate-me {
  animation: flash 5s infinite;
}

Note that you can also opt to include just one state in your @keyframes rule, usually the initial state (written as either from or 0%) or final state (written as either to or 100%). You’d tend to do that for a two-state animation where the other “state” is in the element’s default styles, and you’d either be starting from the default styles (if your single @keyframes state is to) or finishing on them (if your single @keyframes state is from).

Should I use transition or animation?

As far as I can tell there’s no major performance benefit of one over the other, so that’s not an issue.

When the animation will be triggered by pseudo-class-based events like :hover or :focus and is simple i.e. based on just two states, transition feels like the right choice.

Beyond that, the choice gets a bit less binary and seems to come down to developer preference. But here are a couple of notes that might help in making a decision.

For elements that need to “animate in” on page load such as an alert, or when newly added to the DOM such as items in a to-do list, an animation with keyframes feels the better choice. This is because transition requires the presence of two CSS rules, leading to dedicated JavaScript to grab the element and apply a class, whereas animation requires only one and can move between initial and final states automatically including inserting a delay before starting.

For animations that involve many frames; control over the number of iterations; or looping… use @keyframes and animation.

For utility classes and classes that get added by JS to existing, visible elements following an event, either approach could be used. Arguably transition is the slightly simpler and more elegant CSS to write if it covers your needs. Then again, you might want to reuse the animations applied by those classes for both existing, visible elements and new, animated-in elements, in which case you might feel that instead using @keyframes and animation covers more situations.

Performance

A smooth animation should run at 60fps (frames per second). Animations that are too computationally expensive result in frames being dropped, i.e. a reduced fps rate, making the animation appear janky.

Cheap and slick properties

The CSS properties transform and opacity are very cheap to animate. Also, browsers often optimise these types of animation using hardware acceleration. To hint to the browser that it should optimise an animation property (and to ensure it is handled by the GPU rather than passed from CPU to GPU causing a noticeable glitch) we should use the CSS will-change property.

.my-element {
  will-change: transform;
}

Expensive properties

CSS properties which affect layout such as height are very expensive to animate. Animating height causes a chain reaction where sibling elements have to move too. Use transform over layout-affecting properties such as width or left if you can.

Some other CSS properties are less expensive but still not ideal, for example background-color. It doesn't affect layout but requires a repaint per frame.

Test your animations on a popular low-end device.

Timing functions

• linear goes at the same rate from start to finish. It’s not like most motion in the real world.
• ease-out starts fast then gets really slow. Good for things that come in from off-screen, like a modal dialogue.
• ease-in starts slow then gets really fast. Good for moving somethng off-screen.
• ease-in-out is the combination of the previous two. It‘s symmetrical, having an equal amount of acceleration and deceleration. Good for things that happen in a loop such as element fading in and out.
• ease is the default value and features a brief ramp-up, then a lot of deceleration. It’s a good option for most general case motion that doesn’t enter or exit the viewport.

Practical examples

You can find lots of animation inspiration in libraries such as animate.css (and be sure to check animate.css on github where you can search their source for specific @keyframe animation styles).

But here are a few specific examples of animations I or teams I’ve worked on have had to implement.

Skip to content

The anchor’s State A sees its position fixed—i.e. positioned relative to the viewport—but then moved out of sight above it via transform: translateY(-10em). However its :focus styles define a State B where the intial translate has been undone so that the link is visible (transform: translateY(0em)). If we transition the transform property then we can animate the change of state over a chosen duration, and with our preferred timing function for the acceleration curve.

HTML:

<div class="u-visually-hidden-until-focused">
  <a
    href="#skip-link-target"
    class="u-visually-hidden-until-focused__item"
  >Skip to main content</a>
</div>

<nav>
  <ul>
    <li><a href="/">Home</a></li>
    <li><a href="/">News</a></li>
    <li><a href="/">About</a></li>
    <!-- …lots more nav links… -->
    <li><a href="/">Contact</a></li>
  </ul>
</nav>

<main id="skip-link-target">
  <h1>This is the Main content</h1>
  <p>Lorem ipsum <a href="/news/">dolor sit amet</a> consectetur adipisicing elit.</p>
  <p>Lorem ipsum dolor sit amet consectetur adipisicing elit.</p>
</main>

CSS:

.u-visually-hidden-until-focused {
  left: -100vw;
  position: absolute;

  &__item {
    position: fixed;
    top: 0;
    left: 0;
    transform: translateY(-10em);
    transition: transform 0.2s ease-in-out;

    &:focus {
      transform: translateY(0em);
    }
  }
}

To see this in action, visit my pen Hiding: visually hidden until focused and press the tab key.

Animating in an existing element

For this requirement we want an element to animate from invisible to visible on page load. I can imagine doing this with an image or an alert, for example. This is pretty straightforward with CSS only using @keyframes, opacity and animation.

Check out my fade in and out on page load with CSS codepen.

Animating in a newly added element

Stephanie Eckles shared a great CSS-only solution for animating in a newly added element which handily includes a Codepen demo. She mentions “CSS-only” because it’s common for developers to achieve the fancy animation via transition but that means needing to “make a fake event” via a JavaScript setTimeout() so that you can transition from the newly-added, invisible and class-free element state to adding a CSS class (perhaps called show) that contains the opacity:1, fancy transforms and a transition. However Stephanie’s alternative approach combines i) hiding the element in its default styles; with ii) an automatically-running animation that includes the necessary delay and also finishes in the keyframe’s single 100% state… to get the same effect minus the JavaScript.

Avoiding reliance on JS and finding a solution lower down the stack is always good.

<button>Add List Item</button>
<ul>
  <li>Lorem ipsum dolor sit amet consectetur adipisicing elit. Nostrum facilis perspiciatis dignissimos, et dolores pariatur.</li>
</ul>

li {
  animation: show 600ms 100ms cubic-bezier(0.38, 0.97, 0.56, 0.76) forwards;

  // Prestate
  opacity: 0;
  // remove transform for just a fade-in
  transform: rotateX(-90deg);
  transform-origin: top center;
}

@keyframes show {
  100% {
    opacity: 1;
    transform: none;
  }
}

Jhey Tompkins shared another CSS-only technique for adding elements to the DOM with snazzy entrance animations. He also uses just a single @keyframes state but in his case the from state which he uses to set the element’s initial opacity:0, then in his animation he uses an animation-fill-mode of both (rather than forwards as Stephanie used).

I can’t profess to fully understand both however if you change Jhey’s example to use forwards instead, then the element being animated in will temporarily appear before the animation starts (which ain’t good) rather than being initially invisible. Changing it to backwards gets us back on track, so I guess the necessary value relates to whether you’re going for from/0% or to/100%… and both just covers you for both cases. I’d probably try to use the appropriate one rather than both just in case there’s a performance implication.

Animated disclosure

Here’s an interesting conundrum.

For disclosure (i.e. collapse and expand) widgets, I tend to either use the native HTML <details> element if possible or else a simple, accessible DIY disclosure in which activating a trigger toggles a nearby content element’s visibility. In both cases, there’s no animation; the change from hidden to revealed and back again is immediate.

To my mind it’s generally preferable to keep it simple and avoid animating a disclosure widget. For a start, it’s tricky! The <details> element can’t be (easily) animated. And if using a DIY widget it’ll likely involve animating one of the expensive properties. Animating height or max-height is also gnarly when working with variable (auto) length content and often requires developers to go beyond CSS and reach for JavaScript to calculate computed element heights. Lastly, forgetting the technical challenges, there’s often no real need to animate disclosure; it might only hinder rather than help the user experience.

But let’s just say you have to do it, perhaps because the design spec requires it (like in BBC Sounds’ expanding and collapsing tracklists when viewed on narrow screens).

Options:

• Animate the <details> element. This is a nice, standards-oriented approach. But it might only be viable for when you don’t need to mess with <details> appearance too much. We’d struggle to apply very custom styles, or to handle a “show the first few list items but not all” requirement like in the BBC Sounds example;
• Animate CSS Grid. This is a nice idea but for now the animation only works in Firefox^*. It’d be great to just consider it a progressive enhancement so it just depends on whether the animation is deemed core to the experience;
• Animate from a max-height of 0 to “something sufficient” (my pen is inspired by Scott O’Hara’s disclosure example). This is workable but not ideal; you kinda need to set a max-height sweetspot otherwise your animation will be delayed and too long. You could of course add some JavaScript to get the exact necessary height then set it. BBC use max-height for their tracklist animation and those tracklists likely vary in length so I expect they use some JavaScript for height calculation.

* Update 20/2/23: the “animate CSS Grid” option now has wide browser support and is probably my preferred approach. I made a codepen that demonstrates a disclosure widget with animation of grid-template-rows.

Ringing bell icon

To be written.

Pulsing “radar” effect

To be written.

Accessibility

Accessibility and animation can co-exist, as Cassie Evans explains in her CSS-Tricks article Empathetic Animation. We should consider which parts of our website are suited to animation (for example perhaps not on serious, time-sensitive tasks) and we can also respect reduced motion preferences at a global level or in a more finer-grained way per component.

Notes

• transition-delay can be useful for avoiding common annoyances, such as when a dropdown menu that appears on hover disappears when you try to move the cursor to it.

References

• Inspiration: the animate.css library
• animate.css on github (good for searching for keyframe CSS)
• CSS transitions and transforms on Thoughtbot
• CSS Transitions by Josh Comeau
• Keyframe Animations by Josh Comeau
• Transition vs animation on CSS Animation
• Keyframe animation syntax on CSS-Tricks
• CSS animation for beginners on Thoughtbot
• Using CSS Transions on auto dimensions on CSS-Tricks
• Jhey Tompkins’s Image fade with interest codepen

Enjoyed this funny and touching film about a Syrian asylum seeker searching for happiness on a remote Scottish island.

I’ve started reading Station Eleven, by Emily St. John Mandel.

Here’s an interesting development in the block link saga: GOV.UK have introduced one (named .chevron-card) on their Homepage, citing how it’ll improve accessibility by increasing mobile touch targets. It’s not yet been added to their Design System while they’re monitoring it to see if it is successful. They’ve chosen the approach which starts with a standard, single, non-wrapping anchor then “stretches” it across the whole card via some pseudo elements and absolute positioning magic. I’m slightly surprised at this choice because it breaks the user’s ability to select text within the link. Really interested to see how it pans out!

Just taking a moment for some musings on which way the front-end wind is blowing (from my perspective at least) and how that might practically impact my approach on the next small-ish website that I code.

I might lean into HTTP2

Breaking CSS into small modules then concatenating everything into a single file has traditionally been one of the key reasons for using Sass, but in the HTTP2 era where multiple requests are less of a performance issue it might be acceptable to simply include a number of modular CSS files in the <head>, as follows:

<link href="/css/base.css" rel="stylesheet">
<link href="/css/component_1.css" rel="stylesheet">
<link href="/css/component_2.css" rel="stylesheet">
<link href="/css/component_3.css" rel="stylesheet">

The same goes for browser-native JavaScript modules.

This isn’t something I’ve tried yet and it’d feel like a pretty radical departure from the conventions of recent years… but it‘s an option!

I’ll combine ES modules and classes

It’s great that JavaScript modules are natively supported in modern browsers. They allow me to remove build tools, work with web standards, and they perform well. They can also serve as a mustard cut that allows me to use other syntax and features such as async/await, arrow functions, template literals, the spread operator etc with confidence and without transpilation or polyfilling.

In the <head>:

<script type="module" src="/js/main.js"></script>

In main.js

import { Modal } from '/components/modal.js';

const Modal = new Modal();
modal.init();

In modal.js

export class Modal {
  init() {
    // modal functionality here
  }
}

I’ll create Web Components

I’ve done a lot of preparatory reading and learning about web components in the last year. I’ll admit that I’ve found the concepts (including Shadow DOM) occasionally tough to wrap my head around, and I’ve also found it confusing that everyone seems to implement web components in different ways. However Dave Rupert’s HTML with Superpowers presentation really helped make things click.

I’m now keen to create my own custom elements for javascript-enhanced UI elements; to give LitElement a spin; to progressively enhance a Light DOM baseline into Shadow DOM fanciness; and to check out how well the lifecycle callbacks perform.

I’ll go deeper with custom properties

I’ve been using custom properties for a few years now, but at first it was just as a native replacement for Sass variables, which isn’t really exploiting their full potential. However at work we’ve recently been using them as the special sauce powering component variations (--gap, --mode etc).

In our server-rendered components we’ve been using inline style attributes to apply variations via those properties, and this brings the advantage of no longer needing to create a CSS class per variation (e.g. one CSS class for each padding variation based on a spacing scale), which in turn keeps code and specificity simpler. However as I start using web components, custom properties will prove really handy here too. Not only can they be updated by JavaScript, but furthermore they provide a bridge between your global CSS and your web component because they can “pierce the Shadow Boundary”, make styling Shadow DOM HTML in custom elements easier.

I’ll use BEM, but loosely

Naming and structuring CSS can be hard, and is a topic which really divides opinion. Historically I liked to keep it simple using the cascade, element and contextual selectors, plus a handful of custom classes. I avoided “object-oriented” CSS methodologies because I found them verbose and, if I’m honest, slightly “anti-CSS”. However it’s fair to say that in larger applications and on projects with many developers, this approach lacked a degree of structure, modularisation and predictability, so I gravitated toward BEM.

BEM’s approach is a pretty sensible one and, compared to the likes of SUIT, provides flexibility and good documentation. And while I’ve been keeping a watchful eye on new methodologies like CUBE CSS and can see that they’re choc-full of ideas, my feeling is that BEM remains the more robust choice.

It’s also important to me that BEM has the concept of a mix because this allows you to place multiple block classes on the same element so as to (for example) apply an abstract layout in combination with a more implementation-specific component class.

<div class="l-stack c-news-feed">

Where I’ll happily deviate from BEM is to favour use of certain ARIA attributes as selectors (for example [aria-current=page] or [aria-expanded=true] because this enforces good accessibility practice and helps create equivalence between the visual and non-visual experience. I’m also happy to use the universal selector (*) which is great for owl selectors and I’m fine with adjacent sibling (and related) selectors.

Essentially I’m glad of the structure and maintainability that BEM provides but I don’t want a straitjacket that stops me from using my brain and applying CSS properly.

A classic talk by Jeremy Keith on progressive enhancement and the nature of the web and its technologies.

Jeremy Keith’s new course for Google’s web.dev learning platform is fantastic and covers a variety of aspects of responsive design including layout (macro and micro), images, icons and typography.

Recently, during a period when pandemic woes were taking their toll and likely making me a little cranky at home, I found some funny and helpful words of wisdom on Adam Buxton’s podcast and when re-watching Ricky Gervais’s interview with Larry David.

On sustaining a happy marriage, Buxton said:

Every now and then you think “they’re not doing what I want them to do and I think it’s important that they do do this thing that I want them to do! (But) you have to think really hard: is this thing actually important? Is it worth getting bent out of shape about?

It’s good advice. He mentioned that he’s slowly getting better at that, and I’m trying my best to, too.

Meanwhile, on the reasons why he got into acting, Larry David said:

it gets you out of the house!

So simple but true—it’s good to get out of the house! We’re now emerging from a period of sustained isolation and I should probably avoid being completely remote (and going stir crazy) and get back into the office occasionally.

A designer colleague recently asked me what course or resources I would recommend for learning front-end web development. She mentioned React at the beginning but I suggested that it’d be better to start by learning HTML, CSS, and JavaScript. As for React: it’s a subset or offshoot of JavaScript so it makes sense to understand vanilla JS first.

For future reference, here are my tips.

Everything in one place

Google’s web.dev training resource have also been adding some excellent guides, such as:

• Learn HTML
• Learn Accessibility
• Learn CSS
• Learn Responsive Design

Another great one-stop shop is MDN Web Docs. Not only is MDN an amazing general quick reference for all HTML elements, CSS properties, JavaScript APIs etc but for more immersive learning there are also MDN’s guides.

Pay attention to HTML

One general piece of advice is that when people look at lists of courses (whether or not they are new to web development) they ensure to learn HTML. People tend to underestimate how complicated, fast-moving and important HTML is.

Also, everything else – accessibility, CSS, JavaScript, performance, resilience – requires a foundation of good HTML. Think HTML first!

Learning CSS, specifically

CSS is as much about concepts and features – e.g. the cascade and specificity, layout, responsive design, typography, custom properties – as it is about syntax. In fact probably more so.

Most tutorials will focus on the concepts but not necessarily so much on practicalities like writing-style or file organisation.

Google’s Learn CSS course should be pretty good for the modern concepts.

Google also have Learn Responsive Design.

If you’re coming from a kinda non-CSS-oriented perspective, Josh W Comeau’s CSS for JavaScript Developers (paid course) could be worth a look.

If you prefer videos, you could check out Steve Griffith’s video series Learning CSS. Steve’s videos are comprehensive and well-paced. It contains a whole range of topics (over 100!), starting from the basics like CSS Box Model.

In terms of HTML and CSS writing style (BEM etc) and file organisation (ITCSS etc), here’s a (version of a) “style guide” that my team came up with for one of our documentation websites. I think it’s pretty good!

CSS and HTML Style Guide (to do: add link here)

For more on ITCSS and Harry Roberts’s thoughts on CSS best practices, see:

• Manage large projects with ITCSS
• Harry’s Skillshare course on ITCSS
• Harry’s CSS Guidelines rulebook
• Harry’s Discovr demo project
  • Discovr CSS directory
  • Discovr demo site

Learning JavaScript

I recommended choosing a course or courses from CSS-Tricks’ post Beginner JavaScript notes, especially as it includes Wes Bos’s Beginner JavaScript Notes + Reference.

If you like learning by video, check out Steve Griffith’s JavaScript playlist.

Once you start using JS in anger, I definitely recommend bookmarking Chris Ferdinandi’s Methods and APIs reference guide.

If you’re then looking for a lightweight library for applying sprinkles of JavaScript, you could try Stimulus.

Learning Responsive Design

I recommend Jeremy Keith’s Learn Responsive Design course on web.dev.

Lists of courses

You might choose a course or courses from CSS-Tricks’ post Where do you learn HTML and CSS in 2020?

Recommended books

• Resilient Web Design by Jeremy Keith. A fantastic wide-screen perspective on what we’re doing, who we’re doing it for, and how to go about it. Read online or listen as an audiobook.
• Inclusive Components by Heydon Pickering. A unique, accessible approach to building interactive components, from someone who’s done this for BBC, Bulb, Spotify.
• Every Layout by Heydon Pickering & Andy Bell. Introducing layout primitives, for handling responsive design in Design Systems at scale (plus so many insights about the front-end)
• Atomic Design by Brad Frost. A classic primer on Design Systems and component-composition oriented thinking.
• Practical SVG by Chris Coyier. Learn why and how to use SVG to make websites more aesthetically sharp, performant, accessible and flexible.
• Web Typography by Richard Rutter. Elevate the web by applying the principles of typography via modern web typography techniques.

At work, I’m sometimes asked accessibility questions or to provide guidelines. I’m with Anna Cook in considering myself an accessibility advocate rather than an expert however I have picked up lots of tips and knowledge over many years of developing websites. So I thought it’d be useful to gather some general web accessibility tips and tests in one place as a useful reference.

Caveats and notes:

1. this is a living document which I’ll expand over time;
2. I’m standing on the shoulders of real experts and I list my references at the foot of the article; and
3. if I’ve got anything wrong, please let me know!

Table of contents

• If you only had 5 minutes
• Content structure
• Semantic HTML and ARIA
• Favour native over custom components except where they have known issues
• Make custom components convey state accessibly
• Forms
• Links and buttons
• Ensure keyboard support
• Content resizing
• Better link text
• Supporting high contrast mode
• Skip links
• Navigation and menus
• Modal dialogues

If you only had 5 minutes

If someone had a web page and only had 5 minutes to find and tackle the lowest hanging fruit accessibility-wise, I’d probably echo Jeremy Keith’s advice to ensure that the page covers the following:

• uses heading elements sensibly
• uses landmarks (representing roles like banner, navigation, main, contentinfo)
• marks up forms sensibly (for example using labels and appropriate buttons)
• provides images with decent text alternatives

(Note: headings and landmarks are used by screen reader users to get a feel for the page then jump to areas of interest.)

Spending just 5 minutes would be bad, of course, and you shouldn’t do that. The point is that if pushed, the above give good bang-for-your-buck.

Content structure

The page’s content should be well structured as this makes it easier to understand for all, especially people with reading and cognitive disabilities.

It should consist of short sections of content preceded by clear headings. Use the appropriate heading level for the place in the page. Don’t use an inappropriate heading level to achieve a given appearance such as a smaller size. Instead use the appropriate heading element then use CSS to achieve your desired style.

It should employ lists where appropriate. It should place the most important content at the beginning of the page or section to give it prominence.

Check your page for any long passages of text with no structure. Ensure that sufficient prominence is given to the most important information and calls to action.

Semantic HTML and ARIA

While there are generic HTML elements like div and span, there are many more HTML elements that perform a specific role and convey that role to browers and other technologies. Choosing and using semantic HTML elements appropriately is a very good practice.

Also, using semantic HTML elements is preferable to bolting on semantics via attributes since the semantics are conveyed natively avoiding redundancy and duplication. As Bruce Lawson says, “Built-in beats bolt-on, bigly”.

Apply ARIA carefully. No ARIA is better than bad ARIA.

Landmarks

Create a small number of landmarks using the appropriate HTML elements.

For some landmark-generating elements it’s appropriate to bolster them with a label or accessible name. For example with nav and aside, i) there’s a decent chance there might be multiple on the page; and ii) each instance creates a landmark even when it’s nested within a deeper HTML element. So it’s helpful to distinguish each different landmark of the same type by using sensible accessible names otherwise you’d get multiple navigation menus all represented by the same “navigation” in the Landmarks menu. In the case of the section element it needs an acessible name in order for it to act as a region landmark. For all of these you can use aria-labelledby set to the id of an inner heading, or use aria-label.

Note that when using multiple <header> (or footer) elements on a page, where one and one only is a direct child of body while the others are used within article or similar elements, there’s perhaps less need to add custom accessible names. That’s because only a direct child of body will be treated as a landmark and the others won’t, therefore they won’t be butting against each other in a screen reader’s Landmarks menu and need distinguished.

Correct use of aria-label and aria-labelledby

Use the aria-label or aria-labelledby attributes (only when necessary) on interactive elements – buttons, links, form controls – and on landmark regions. Don’t use them on <div>s, <span>s, or other elements representing static/noninteractive text-level semantics, such as <p>, <strong>, <em>, and so forth, unless those elements’ roles have been overridden with roles that expect accessible names.

Favour native over custom components except where they have known issues

Native components require very little work, are familiar to users, and are generally accessible by default. Custom components can be built to appear and behave as designers want, but require much more effort to build and are challenging to make accessible.

There are exceptions. Since the native options are flawed across browsers, accessibility experts recommend using custom solutions for:

• form error field messages
• focus indicator styles

Make custom components convey state accessibly

Now that you’re building a custom component you don’t get accessibility out of the box. Whether it’s a Like button or a disclosure widget, you can’t rely on a visual change alone to convey a UI change to all users. You’ll need to use the right element (note – it often starts with a button) and then use ARIA to convey states such as pressed or expanded to screen reader users.

Forms

Because in the industry form fields are often handled with JavaScript and not submitted, people sometimes question whether form fields should live inside a form (<form>). My answer is yes, and here’s why.

Using the form element improves usability and accessibility

Using a <form> provides additional semantics allowing additional accessibility. It helps assistive devices like screen readers better understand the content of the page and gives the person using them more meaningful information.

By putting form fields inside a form we also ensure we match user expectations. We support the functionality (such as the different ways of submitting a form) that users expect when presented with form fields.

If you’re thinking “but what about form fields that don’t look like form fields?” then you’ve entered the problem territory of “deceptive user interfaces” – the situation where perceived affordances don’t match actual functionality, which causes confusion for some people. This is to be avoided. We shouldn’t use form fields (nor a <form>) when they are not appropriate. A checkbox, radio button, or select menu is meant to gather information. So if your goal is instead to let the user manipulate the current view, use a button rather than checkboxes or radio buttons.

References:

• Why use a form element when submitting fields with JavaScript
• Lea Verou and Leonie Watson’s discussion regarding Toggles
• My conversation about forms with accessibility expert Adrian Roselli

Using the form element simplifies your JavaScript for event handling

Using the form element can also make it easier for you to meet user expectations in your JS-powered experience. This is because it gives you a single element (form) and event combination that allows listening to multiple interactions. With a form element you can add a listener for the submit() event. This event fires automatically in response to the various ways users expect to submit a form, including pressing enter inside a field.

Anchors and buttons

To let the user navigate to a page or page section, or download a file, use an anchor element.

To let the user trigger an action such as copying to clipboard, launching a modal or submitting a form, use a button element.

Anchors should include an href attribute otherwise the browser will treat it like a non-interactive element. This means the link will not be included in the expected focus order and will not present a pointer to mouse users like it should. These days there is no remaining use case for an anchor without an href. We no longer need named anchors to create link-target locations within the page because we can use the id attribute (on any element) for that. And if you want an interactive element that does not link somewhere, you should use button.

Do not remove the focus outline from links and buttons in CSS, unless it’s to provide a better version.

Ensure you always give links and buttons an accessible name, even when they use icons rather than text. This might be through visually hidden text or perhaps using an ARIA-related attribute.

Ensure keyboard support

Web pages need to support those who navigate the page by keyboard.

Use the tab key to navigate your page and ensure that you can reach all actionable controls such as links, buttons and form controls. Press the enter key or space bar to activate each control.

If during your test any actionable control is skipped, receives focus in an illogical order, or you cannot see where the focus is at any time, then keyboard support is not properly implemented.

Content resizing

Try zooming your page up to 400%. In Chrome, Zoom is available from the kebab menu at the top-right, or by holding down command with plus or minus.

Content must resize and be available and legible. Everything should reflow.

Relative font settings and responsive design techniques are helpful in effectively handling this requirement.

Relatedly, setting font-sizes in px should be avoided because although a user can override the “fixed-ness” with zoom, it breaks the user’s ability to choose a larger or smaller default font size (which users often prefer over having to zoom every single page).

Better link text

Blind and visually impaired users use a screen reader to browse web pages, and screen readers provide user-friendly access to all the links on the page via a Links menu. When links are encountered in that context, link text like “Click here” and “Read more” are useless.

Check your web page to ensure that links clearly describe the content they link to when read out of context.

Better link text also improves the flow and clarity of your content and so improves the experience for everyone.

Supporting high contrast mode

Some people find it easier to read content when it’s in a particular colour against a specific background colour. Operating systems provide options to allow users to configure this to their preference. Websites must support support the user’s ability to apply this.

On a Windows computer go to Settings > Ease of access and turn on High contrast mode. On macOS go to System preferences > Accessibility settings > Display and select “Invert colours”.

Having changed the contrast, check that your web page’s content is fully visible and understandable, that images are still visible and that buttons are still discernible.

Skip links

Websites should provide a “Skip to content” link because this provides an important accessibility aid to keyboard users and those who use specialised input devices. For these users, having to step through (typically via the tab key) all of the navigation links on every page would be tiring and frustrating. Providing a skip link allows them to bypass the navigation and skip to the page’s main content.

To test that a website contains a skip link, visit a page then press the tab key and the skip link should appear. Then activate it using the enter key and check that focus moves to the main content area. Press tab again to ensure that focus moves to the first actionable element in the main content.

Navigation and menus

When developing a collapsible menu, place your menu <button> within your <nav> element and hide the inner list rather than hiding the <nav> element itself. That way, we are not obscuring from Assistive Technologies the fact that a navigation still exists. ATs can still access the nav via landmark navigation. This is important because landmark discovery is one of the fundamental ways AT users scan, determine and navigate a site’s structure.

Modal dialogues

You probably don’t want to set the modal’s heading as an <h1>. It likely displays content that exists on the page (which already has an <h1>) at a lower level of the document hierarchy.

References

• Using HTML landmark roles to improve accessibility MDN article. And Adrian R’s suggestions for additions
• Navigation (landmark) role, on MDN
• Tetralogical’s Quick Accessibility Tests YouTube playlist
• Basic accessibility mistakes I often see in audits by Chris Ferdinandi
• Sara Soueidan’s video tutorial Practical tips for building more accessible front-ends
• Adrian Roselli’s Responsive type and zoom
• Heydon Pickering’s tweet about buttons in navs and Scott O’Hara’s follow up article Landmark Discoverability
• Tetralogical’s Foundations: native versus custom components
• Ben Myers on where to use aria labelling attributes

It’s a few years old now, but this tutorial from Heydon Pickering on how to create an accessible, progressively enhanced user interface comprised of multiple collapsible and expandable sections is fantastic. It covers using the appropriate HTML elements (buttons) and ARIA attributes, how best to handle icons (minimal inline SVG), turning it into a web component and plenty more besides.

Jeremy Keith deconstructs the cheeseburger icon and—referencing Luke Wroblewski’s Obvious Always Wins mantra—argues that while icons alone look tasty they risk users failing to understand and engage.

Here’s the BBC’s Storybook UI explorer containing the components and layouts for making the front end of a BBC web experience.

A history of Design Systems by Jay Hoffman taking in (amongst other milestones) the notion of Front-end Style Guides, followed by the arrival of Bootstrap, then Brad Frost’s Atomic Design, culminating in the dawn of the Design System movement with Jina Anne’s Clarity Conference.

On the web buttons and links are fundamentally different materials. However some design and development practices have led to them becoming conceptually “bundled together” and misunderstood. Practitioners can fall into the trap of seeing the surface-level commonality that “you click the thing, then something happens” and mistakenly thinking the two elements are interchangeable. Some might even consider them as a single “button component” without considering the distinctions underneath. However this mentality causes our users problems and is harmful for effective web development. In this post I’ll address why buttons and links are different and exist separately, and when to use each.

Problematic patterns

Modern website designs commonly apply the appearance of a button to a link. For isolated calls to action this can make sense however as a design pattern it is often overused and under-cooked, which can cause confusion to developers implementing the designs.

Relatedly, it’s now common for Design Systems to have a Button component which includes button-styled links that are referred to simply as buttons. Unless documented carefully this can lead to internal language and comprehension issues.

Meanwhile developers have historically used faux links (<a href="#">) or worse, a DIY clickable div, as a trigger for JavaScript-powered functionality where they should instead use native buttons.

These patterns in combination have given rise to a collective muddle over buttons and links. We need to get back to basics and talk about foundational HTML.

Buttons and anchors in HTML

There are two HTML elements of interest here.

Hyperlinks are created using the HTML anchor element (<a>). Buttons (by which I mean real buttons rather than links styled to appear as buttons) are implemented with the HTML button element (<button>).

Although a slight oversimplification, I think David MacDonald’s heuristic works well:

If it GOES someWHERE use a link

If it DOES someTHING use a button

A link…

• goes somewhere (i.e. navigates to another place)
• normally links to another document (i.e. page) on the current website or on another website
• can alternatively link to a different section of the same page
• historically and by default appears underlined
• when hovered or focused offers visual feedback from the browser’s status bar
• uses the “pointing hand” mouse pointer
• results in browser making an HTTP GET request by default. It’s intended to get a page or resource rather than to change something
• offers specific right-click options to mouse users (open in new tab, copy URL, etc)
• typically results in an address which can be bookmarked
• can be activated by pressing the return key
• is announced by screen readers as “Link”
• is available to screen reader users within an overall Links list

A button…

• does something (i.e. performs an action, such as “Add”, “Update” or "Show")
• can be used as <button type=submit> within a form to submit the form. This is a modern replacement for <input type=submit /> and much better as it’s easier to style, allows nested HTML and supports CSS pseudo-elements
• can be used as <button type=button> to trigger JavaScript. This type of button is different to the one used for submitting a <form>. It can be used for any type of functionality that happens in-place rather than taking the user somewhere, such as expanding and collapsing content, or performing a calculation.
• historically and by default appears in a pill or rounded rectangle
• uses the normal mouse pointer arrow
• can be activated by pressing return or space.
• implictly gets the ARIA button role.
• can be extended with further ARIA button-related states like aria-pressed
• is announced by screen readers as “Button”
• unlike a link is not available to screen reader users within a dedicated list

Our responsibilities

It’s our job as designers and developers to use the appropriate purpose-built element for each situation, to present it in a way that respects conventions so that users know what it is, and to then meet their expectations of it.

Tips

• Visually distinguish button-styled call-to-action links from regular buttons, perhaps with a more pill-like appearance and a right-pointing arrow
• Avoid a proliferation of call-to-action links by linking content itself (for example a news teaser’s headline). Not only does this reduce “link or button?” confusion but it also saves space, and provides more accessible link text.
• Consider having separate Design System components for Button and ButtonLink to reinforce important differences.
• For triggering JavaScript-powered interactions I’ll typically use a button. However in disclosure patterns where the trigger and target element are far apart in the DOM it can make sense to use a link as the trigger.
• For buttons which are reliant on JavaScript, it’s best to use them within a strategy of progressive enhancement and not render them on the server but rather with client-side JavaScript. That way, if the client-side JavaScript is unsupported or fails, the user won’t be presented with a broken button.

Update: 23 November 2024

Perhaps a better heuristic than David MacDonald’s mentioned above, is:

Links are for a simple connection to a resource; buttons are for actions.

What I prefer about including a resource is that the “goes somewhere” definition of a link breaks down for anchors that instruct the linked resource to download (via the download attribute) rather than render in the browser, but this doesn’t. I also like the inclusion of simple because some buttons (like the submit button of a search form) might finish by taking you to a resource (the search results page) but that’s a complex action not a simple connection; you’re searching a database using your choice of search query.

References

• Get safe, by Jeremy Keith
• Buttons vs. Links, by Eric Eggert
• The Button Cheat Sheet, by Manuel Matuzović
• A complete guide to links and buttons on CSS-Tricks
• The Links vs Buttons Showdown, by Marcy Sutton

Here’s a great new presentation by Dave Rupert (of the Shop Talk show) in which he makes a compelling case for adopting Web Components. Not only do they provide the same benefits of encapsulation and reusability as components in proprietary JavaScript frameworks, but they also bring the reliability and portability of web standards, work without build tools, are suited to progressive enhancement, and may pave the way for a better web.

Dave begins by explaining that Web Components are based on not just a set of technologies but a set of standards, namely:

• Custom Elements (for example <custom-alert>)
• Shadow DOM
• ES Modules
• the HTML <template> element

Standards have the benefit that we can rely on them to endure and work into the future in comparison to proprietary technologies in JavaScript frameworks. That’s good news for people who like to avoid the burnout-inducing churn of learning and relearning abstractions. Of course the pace of technology change with web standards tends to be slower, however that’s arguably a price worth paying for cross-platform stability and accessibility.

Some of Web Components’ historical marketing problems are now behind them, since they are supported by all major browsers and reaching maturity. Furthermore, web components have two superpowers not found in other JavaScript component approaches:

Firstly, the Shadow DOM (which is both powerful and frustrating). The Shadow DOM provides encapsulation but furthermore in progressive enhancement terms it enables the final, enhanced component output which serves as an upgrade from the baseline Light DOM HTML we provided in our custom element instance. It can be a little tricky or confusing to style, however, although there are ways.

Secondly, you can use web components standalone, i.e. natively, without any frameworks, build tools, or package managers. All that’s required to use a “standalone” is to load the <script type=module …> element for it and then use the relevant custom element HTML on your page. This gets us closer to just writing HTML rather than wrestling with tools.

Dave highlights an education gap where developers focused on HTML, CSS, and Design Systems don’t tend to use Web Components. He suggests that this is likely as a result of most web component tutorials focusing on JavaScript APIs for JavaScript developers. However we can instead frame Web Component authoring as involving a layered approach that starts with HTML, adds some CSS, then ends by applying JavaScript.

Web Components are perfectly suited to progressive enhancement. And that progressive enhancement might for example apply lots of complicated ARIA-related accessibility considerations. I really like the Tabs example where one would create a <generic-tabs> instance which starts off with simple, semantic, resilient HTML that renders headings and paragraphs…

<generic-tabs>
  <h2>About</h2>
  <div>
    <p>About content goes here. Lorem ipsum dolor sit amet…</p>
  </div>

  <h2>Contact</h2>
  <div>
    <p>Contact content goes here. Lorem ipsum dolor sit amet…</p>
  </div> 
</generic-tabs>

…but the Web Component’s JavaScript would include a template and use this to upgrade the Light DOM markup into the final interactive tab markup…

<generic-tabs>
  <h2 slot="tab" aria-selected="true" tabindex="0" role="tab" id="generic-tab-3-0" aria-controls="generic-tab-3-0" selected="">About</h2>
  <div role="tabpanel" aria-labelledby="generic-tab-3-0" slot="panel">
    <p>About content goes here. Lorem ipsum dolor sit amet…</p>
  </div>
  <h2 slot="tab" aria-selected="false" tabindex="-1" role="tab" id="generic-tab-3-1" aria-controls="generic-tab-3-1">Contact</h2>
  <div role="tabpanel" aria-labelledby="generic-tab-3-1" slot="panel" hidden>
    <p>Contact content goes here. Lorem ipsum dolor sit amet…</p>
  </div>
</generic-tabs>

The idea is that the component’s JS would handle all the complex interactivity and accessibility requirements of Tabs under the hood. I think if I were implementing something like Inclusive Components’ Tabs component these days I’d seriously consider doing this as a Web Component.

Later, Dave discusses the JavaScript required to author a Custom Element. He advises that in order to avoid repeatedly writing the same lengthy, boilerplate code on each component we might use a lightweight library such as his favourite, LitElement.

Lastly, Dave argues that by creating and using web components we are working with web standards rather than building for a proprietary library. We are creating compatible components which pave the cowpaths for these becoming future HTML standards (e.g. a <tabs> element!) And why is advancing the web important? Because an easier web lowers barriers: less complexity, less tooling and setup, less gatekeeping—a web for everyone.

On the page, right-click the element you want to debug event listeners for, then click Inspect Element. In chromium-based browsers like MS Edge and Google Chrome, click the Event Listeners tab in Developer Tools. There, you’ll see a list of all of the events being listened to on that element. If you expand the event, you can see what element they’re attached to and click a link to open up the actual event listener itself in the JavaScript.

Here’s a “media query free” CSS one-liner which lets you set an element to have no border-radius when it is the full width of the viewport, but otherwise to have a border-radius.

It uses the same 9999 multiplication technique as Every Layout do to create a toggle.

Great for Card components which need to be full-width and non-rounded only on narrow viewports.

I’ve started reading Uncanny Valley, by Anna Wiener.

Thanks for the recommendation, @mrtomchurchill.

Loved this short listen from Clearleft, on a subject close to my heart! New job titles can feel a bit “emperor’s new clothes” but with Design Engineering I think Clearleft, GitHub et al. might be onto something. It was fascinating hearing people from both design and engineering backgrounds give their perspectives, and how ultimately they’re addressing the same thing—the need to “finesse the overlaps/gaps” between design and the realisation of that design in engineering, especially in light of the complexities of the modern front-end.

(via @Stugoo)

Here’s an accessibility tip that’s new to me. When the content of a heading, anchor, or other semantic HTML element contains smaller “chunks” of span and em (etc), the VoiceOver screen reader on Mac and iOS annoyingly fails to announce the content as a single phrase and instead repeats the parent element’s role for each inner element. We can fix that by adding an inner “wrapper” element inside our parent and giving it role=text.

Make sure not to add this role directly to your parent element since it will override its original role causing it to lose its intended semantics.

The text role is not yet in the official ARIA spec but is supported by Safari.

(via @Seraphae and friends on Twitter)

A new animation library, built on the Web Animations API for the smallest filesize and the fastest performance.

This JavaScript-based animation library—which can be installed via npm—leans on an existing web API to keep its file size low and uses hardware accelerated animations where possible to achieve impressively smooth results.

For fairly basic animations, this might provide an attractive alternative to the heavier Greensock. The Motion docs do however flag the limitation that it can only animate “CSS styles”. They also say “SVG styles work fine”. I hope by this they mean SVG presentation attributes rather than inline CSS on an SVG, although it’s hard to tell. However their examples look promising.

The docs website also contains some really great background information regarding animation performance.

Here are a few troubleshooting tips to enable Jest, the JavaScript testing framework, to be able to work with ES modules without needing Babel in the mix for transpilation. Let’s get going with a basic set-up.

package.json

…,
"scripts": {
  "test": "NODE_ENV=test NODE_OPTIONS=--experimental-vm-modules jest"
},
"type": "module",
"devDependencies": {
  "jest": "^27.2.2"
}

Note: take note of the crucial "type": "module" part as it’s the least-documented bit and your most likely omission!

After that set-up, you’re free to import and export to your heart’s content.

javascript/sum.js

export const sum = (a, b) => {
  return a + b;
}

spec/sum.test.js

import { sum } from "../javascript/sum.js";
    
test('adds 1 + 2 to equal 3', () => {
  expect(sum(1, 2)).toBe(3);
});

Hopefully that’ll save you (and future me) some head-scratching.

(Reference: Jest’s EcmaScript Modules docs page)

Harry Roberts (who created ITCSS for organising CSS at scale but these days focuses on performance) has just given a presentation about the importance of getting the content, order and optimisation of the <head> element right, including lots of measurement data to back up his claims. Check out the slides: Get your Head Straight

While some of the information about asset loading best practices is not new, the stuff about ordering of head elements is pretty interesting. I’ll be keeping my eyes out for a video recording of the presentation though, as it’s tricky to piece together his line of argument from the slides alone.

However one really cool thing he’s made available is a bookmarklet for evaluating any website’s <head>:
— ct.css

Here’s something to keep in mind when designing and developing forms. GOV.UK’s accessibility team found last year that there are some accessibility issues with the “conditional reveal” pattern, i.e. when selecting a particular radio button causes more inputs to be revealed.

The full background story is really interesting but the main headline seems to be: Keep it simple.

1. Don’t reveal any more than a single input, otherwise the revealed section should not be in a show-and-hide but rather in its own form in the next step of the process.
2. Conditionally show questions only (i.e. another form input such as Email address)—do not show or hide anything that’s not a question.

Doing otherwise causes some users confusion making it difficult for them to complete the form.

See also the Conditionally revealing a related question section on the Radios component on the GDS Design System

The W3C have just published a new Design System. It was developed by British Digital Agency Studio 24, who are also working (in the open) on the redesign of the W3C website.

My initial impression is that this Design System feels pretty early-stage and work-in-progress. I’m not completely sold on all of the technical details, however it definitely contains a number of emergent best practices and lots of interesting parts.

I particularly liked the very detailed Forms section which assembles lots of good advice from Adam Silver and GOV.UK, and I also found it interesting and useful that they include a Page Templates section rather than just components and layouts.

It’s cool to see an institution like the W3C have a Design System, and I’m looking forward to seeing how it evolves.

I’ve started reading Kindred, by Octavia E. Butler.

In this journal entry, Jeremy Keith argues that when it comes to accessibility testing it’s not just about finding issues—it’s about finding the issues at the right time.

Here’s my summary:

• Accessibility Audits performed by experts and real Assistive Technology users are good!
• But try to get the most out of them by having them focus on the things that you can’t easily do yourself.
• We ourselves can handle things like colour contrast. It can be checked at the design stage before a line of code is written.
• Likewise HTML structure such as ensuring accessible form labels, ensuring images have useful alt values, using landmarks like main and nav, heading structure etc. These are not tricky to find and fix ourselves and they have a big accessibility impact.
• As well as fixing those issues ourselves we should also put in place new processes, checks and automation if possible to stop them recurring
• As for custom interactive elements (tabs, carousels, navigation, dropdowns): these are specific to our site and complicated/error-prone by nature, so those are the things we should be aiming to have professional Accessibility Audits focus on in order to get best value for money.

I’ve been really interested in the subject of Web Performance since I read Steve Souders’ book High Performance Websites back in 2007. Although some of the principles in that book are still relevant, it’s also fair to say that a lot has changed since then so I decided to pull together some current tips. Disclaimer: This is a living document which I’ll expand over time. Also: I’m a performance enthusiast but not an expert. If I have anything wrong, please let me know.

Inlining CSS and or JavaScript

The first thing to know is that both CSS and JavaScript are (by default) render-blocking, meaning that when a browser encounters a standard .css or .js file in the HTML, it waits until that file has finished downloading before rendering anything else.

The second thing to know is that there is a “magic file size” when it comes to HTTP requests. File data is transferred in small chunks of about 14 kb. So if a file is larger than 14 kb, it requires multiple roundtrips.

If you have a lean page and minimal CSS and or JavaScript to the extent that the page in combination with the (minified) CSS/JS content would weigh 14 kb or less after minifying and gzipping, you can achieve better performance by inlining your CSS and or JavaScript into the HTML. This is because there’d be only one request, thereby allowing the browser to get everything it needs to start rendering the page from that single request. So your page is gonna be fast.

If your page including CSS/JS is over 14 kb after minifying and gzipping then you’d be better off not inlining those assets. It’d be better for performance to link to external assets and let them be cached rather than having a bloated HTML file that requires multiple roundtrips and doesn’t get the benefit of static asset caching.

Avoid CSS @import

CSS @import is really slow!

JavaScript modules in the head

Native JavaScript modules are included on a page using the following:

<script type="module" src="main.js"></script>

Unlike standard <script> elements, module scripts are deferred (non render-blocking) by default. Rather than placing them before the closing </body> tag I place them in the <head> so as to allow the script to be downloaded early and in parallel with the DOM being processed. That way, the JavaScript is already available as soon as the DOM is ready.

Background images

Sometimes developers implement an image as a CSS background image rather than a “content image”, either because they feel it’ll be easier to manipulate that way—a typical example being a responsive hero banner with overlaid text—or simply because it’s decorative rather than meaningful. However it’s worth being aware of how that impacts the way that image loads.

Outgoing requests for images defined in CSS rather than HTML won’t start until the browser has created the Render Tree. The browser must first download and parse the CSS then construct the CSSOM before it knows that “Element X” should be visible and has a background image specified, in order to then decide to download that image. For important images, that might feel too late.

As Harry Roberts explains it’s worth considering whether the need might be served as well or better by a content image, since by comparison that allows the browser to discover and request the image nice and early.

By moving the images to <img> elements… the browser can discover them far sooner—as they become exposed to the browser’s preload scanner—and dispatch their requests before (or in parallel to) CSSOM completion

However if still makes sense to use a background image and performance is important Harry recommends including an accompanying hidden image inline or preloading it in the <head> via link rel=preload.

Preload

From MDN’s preload docs, preload allows:

specifying resources that your page will need very soon, which you want to start loading early in the page lifecycle, before browsers' main rendering machinery kicks in. This ensures they are available earlier and are less likely to block the page's render, improving performance.

The benefits are most clearly seen on large and late-discovered resources. For example:

• Resources that are pointed to from inside CSS, like fonts or images.
• Resources that JavaScript can request such as JSON and imported scripts.
• Larger images and videos.

I’ve recently used the following to assist performance of a large CSS background image:

<link rel="preload" href="bg-illustration.svg" as="image" media="(min-width: 60em)">

Self-host your assets

Using third-party hosting services for fonts or other assets no longer offers the previously-touted benefit of the asset potentially already being in the user’s browser cache. Cross domain caching has been disabled in all major browsers.

You can still take advantage of the benefits of CDNs for reducing network latency, but preferably as part of your own infrastructure.

Miscellaneous

Critical CSS is often a wasted effort due to CSS not being a bottleneck, so is generally not worth doing.

References

• Inlining literally everything on Go Make Things
• MDN’s guide to native JavaScript modules
• How and when browsers download images by Harry Roberts

line-height on the web is a tricky thing, but this tool offers a clever solution.

It’s relatively easy to set a sensible unit-less default ratio for body text (say 1.5), but that tends to need tweaked and tested for headings (where spacious line-height doesn’t quite work; but tight line-height is nice until the heading wraps, etc).

Even for body text it’s a not a one-size-fits-all where a line-height like 1.5 is appropriate for all fonts.

Then you’ve got different devices to consider. For confined spaces, tighter line-height works better. But this can mean you might want one line-height for narrow viewports and another for wide.

Then, factor in vertical rhythm based on your modular type and spacing scales if you really want to blow your mind.

It can quickly get really complicated!

Doppler is an interesting idea and tool that I saw in CSS-Tricks’ newsletter this morning. It lets you apply line-height using calc() based on one em-relative value (for example 1em) and one rem-relative value (for example 0.25rem).

In effect you’ll get something like:

set line-height to the font-size of the current element plus a quarter of the user’s preferred font-size

The examples look pretty promising and seem to work well across different elements. I think I’ll give it a spin.