An excellent interview!
From deleted government records to disappearing music, our digital culture can be erased overnight. The Internet Archive’s Mark Graham and Chris Freeland explain what it will take to save it.
This is beautifully written.
At The Web You Want event in Amsterdam last month, Léonie gave an absolutely fantastic talk. You can now read the whole thing: Accessibility is resistance!
She makes the very good point that generative tools are a necessary accessibility recourse when humans have failed to do their job properly.
Images without alt text? Somebody messed up. But this is damage that can be routed around with large language models.
So if you—like me—don’t like the idea of people using extractive generative tools made by the worst kind of people, pay heed:
If you want to resist AI, make accessibility part of everything you do, every decision you make, every product you design and build. Remove the need for people to use AI to compensate, and remember, accessibility is resistance.
Also last month, I wrote about enhancing images from a carousel to masonry using CSS Grid Lanes. Here’s the context:
Over on The Session, I added a little enhancement to the events and sessions listings recently. I make a call to the Google Places API to see if I can find a match for the venue, and if I do, pull in some photos.
Sidenote: right now there’s a major issue with this. None of the photos come with text descriptions. This is something I need to fix, and I’ve got some ideas on how to do that.
I was one of those people with a website that doesn’t have alt text for images. I was one of those people not doing their job.
The first fix I put in place was very much in keeping with the ethos of The Session. I added a form so that any member of the site can edit the alt text of the images in the carousel/masonry layout.
The Session is quite WikiPedia-like. Anyone can edit the track listings in the discography. Anyone can edit the details of any tune. Anyone can edit the details of any session or event. So it made sense to add one more thing that anyone can edit.
With that functionality in place, I put out the call:
If everyone were to take just one or two sessions or events and add alt text to the photos, it would really, really help make the site more accessible.
The community went to work and did a pretty good job.
But there are a lot images. I’d like to have a least some kind of alt text for all of them, even if it’s just a placeholder until someone gets around to adding something better.
I was going to have to use generative “AI”, wasn’t I?
Holding my nose, I investigated some alt-text-as-a-service APIs out there. I signed up for some trials and kicked the tyres. They were rubbish. I suspect most of them were vibe-coded.
The more I thought about it, the more I realised that I probably didn’t need the latest and greatest energy-guzzling large langauge models. Some good old-fashioned machine learning could do the trick here. I’m aiming to do a relatively straightforward transformation—image to text.
Check out the COCO project: Common Objects in Context. It’s a few years old now, but it’s basically a dataset that’s been trained on images.
Ah, but where did the training data come from?
All images in COCO were sourced from Flickr, a photo-sharing platform where users upload images under various Creative Commons licenses.
Works for me!
I found a model on Hugging Face that was created by Microsoft from the COCO data. Confusingly the model is called GIT. It’s nothing to do with version control. It stands for GenerativeImage2Text.
I downloaded the model and set to work creating a script to trawl through all those images and generate alt text if the image doesn’t already have one.
I should mention: the way that I store the alt text is not in a database, but in the file system. Every image has its own folder. Inside that folder there can also be a file called alt.txt.
So the script needed to loop through lots and lots of folders, generate alt text where needed, and save it into a text file in the same folder.
Python is the go-to language for working with models like GIT. But Python is not my strong suit, to put it mildly. And this was going to be a throwaway script that I was only going to use once. So I held my nose again and turned on Copilot in VSCode (I usually keep it switched off).
With the right instructions I was able to get a script that—crucially—I could read and understand. Then I switched off Copilot and had a shower to try to wash the shame away.
Long story short, the script worked.
The results are mostly fine. The alt text is functional. Sometimes it’s wrong, but not disastrously so. A human-generated image description will always be preferable, so any member of The Session can over-ride the placeholder alt text.
It took a few hours to loop through all those folders and generate all those text files. My laptop got hot. But doing it locally sure beats paying for tokens from the baddies.
While the utility is there, the current landscape of these frontier corporate models comes with massive ethical and environmental baggage. This is not a long term solution!
That’s exactly why my hope is that ethically trained open-weight models will eventually catch up and that in the next couple of years, we’ll have something with this level of capability that can run locally. That feels like a much better place to be with this technology.
I can’t understand how we got to this place with “app culture”! Software companies are happy to make their lives harder (and more expensive: deploying to the big app stores isn’t free!), in order to deliver HTML content to fewer people and with fewer features than if they just published directly to the Web in the first place!
So instead of asking “why not React?” we asked: Which of our actual problems would React solve? We went through the list. There were none.
Also, this is good advice when you’re about to make a web component:
Every component starts with the question “does a semantic element already exist for this?”, and remarkably often the answer is yes.
A history of front-end development that culminates here:
The frontier of 2026, the stuff the sharpest people are most excited about, is render the HTML on the server, ship almost no JavaScript, and use the web platform instead of fighting it.
Alex takes issue with my post giving kudos to Apple for concentrating on bugfixes in the latest version of Safari, and he brings receipts. He makes a very compelling case, backed up with data.
But when it comes to Chrome’s shipping of the half-baked prompt API, I’m not sure he gets just how badly it has soured the developer community’s feelings towards Google. This isn’t something to be countered with data; it’s much more visceral than that. Alex says:
So if Jeremy has a problem with specific features, I hope he’ll come to us with a critique of their qualities, rather than their optics.
In this case though, the optics are really, really, really bad.
Nothing about the current trajectory of AI development is inevitable. It was shaped by the thousands of subjective decisions of a tiny elite, and continues its march based on the active participation and tacit consent of people globally.
Put the kettle on. Marcin has another magnum opus on interaction design for you to read …and interact with.
Thursday afternoon session in Dublin
This is excellent advice and I’m glad to see this getting addressed nice and early in the era of customisable select elements:
always provide text content or accessible text attributes for your option elements.
CSS Grid Lanes has started to ship in browsers. It’s in Safari and behind a flag in Chrome and Edge.
It enables masonry layouts, where items get packed together in the most efficient way possible.
Unsurprisingly, I’m a fan of a layout tool where the browser does all the hard work. It very much aligns with the idea of declarative design; you specify the boundary conditions, and then browser does the maths and heavy lifting.
There’s a handy website called The Field Guide to Grid Lanes where you can play around with possibilities.
At the most recent CSS Day, Patrick Brosset gave a great talk showing what you could do with Grid Lanes. I immediately started playing around with it, and I spotted what I think could be a useful pattern…
Over on The Session, I added a little enhancement to the events and sessions listings recently. I make a call to the Google Places API to see if I can find a match for the venue, and if I do, pull in some photos.
Sidenote: right now there’s a major issue with this. None of the photos come with text descriptions. This is something I need to fix, and I’ve got some ideas on how to do that.
Anyway, these photos are just nice-to-haves so I’ve tucked them away into a details element with a simple summary like “Ten photos” or “Twenty photos”. If you open up that details element you get the photos in a horizontal swipable row. A carousel, if you will.
This works fine, but on larger screens I think it would be okay to show all the photos at once. That’s where Grid Lanes comes in.
Take a look at an event or a session in Safari to see what I mean.
Here’s the CSS that creates a carousel:
.gallery {
display: flex;
align-items: center;
inline-size: fit-content;
max-inline-size: 100%;
overflow-inline: auto;
scroll-snap-type: inline mandatory;
overscroll-behavior-inline: contain;
scroll-behavior: smooth;
scrollbar-gutter: stable;
}
.gallery > * {
flex-shrink: 0;
scroll-snap-align: center;
}
And here’s the media query that turns it into a masonry layout:
@supports (display: grid-lanes) {
@media all and (min-width: 56em) {
.gallery {
all: initial;
display: grid-lanes;
grid-template-columns: repeat(auto-fill, minmax(280px, 1fr));
gap: 0.5em;
}
.gallery > * {
inline-size: 100%;
}
}
}
I’m using all: initial to unset the previous styles, which is a bit of a sledgehammer but it works.
I think this could be a useful responsive design pattern. Masonry layouts are great for large screens but kind of rubbish for small screens where you end up with just a single column. Carousels aren’t much cop on large screens but maybe have their place on small screens where real estate is at a premium.
Oh, and needless to say, this is a progressive enhancement. If a browser doesn’t yet understand display: grid-lanes it continues to get the carousel layout.
I give Apple a hard time. That’s mostly due to how they treat the web on their own mobile devices.
Though iOS ostensibly supports the ability for websites to be added to the homescreen, they make it so difficult for users to do, the functionality is practically worthless. It’s dispiriting to see the web so hamstrung by that decision.
The Webkit team has come in for other criticism too. For a while there, Safari was lagging so far behind in features that people were calling it the new Internet Explorer. Ouch!
But credit where credit is due. The upcoming version 27 of Safari is looking very good.
That’s not because it’s at the cutting edge of the latest web standards. Quite the opposite. Most of the changes listed for this release are bug fixes. That’s what I want to acknowledge and applaud.
Far too often a browser will rush out an implementation of an exciting new web standard that gets plenty of attention. But that initial implementation is rarely 100% correct. Then the next release rolls around and the focus has moved on to a different new web standard. The result is an ever-growing backlog of almost-but-not-quite-supported features.
Clearly the focus for Safari 27 was on that backlog. I bet that wasn’t an easy decision. Like I said, the kudos and recognition tends to go to the browser that ships new stuff, not the browser that goes back to fix long-standing issues.
Don’t get me wrong, there’s some exciting new stuff in Safari 27 too, like styleable select, but it’s great to see the focus on maintenance and repair:
If you look through the lists of features and fixes in Safari 27, you’ll notice that, although there are 58 brand-new features and 525 fixes — the largest pile of fixes in any Safari release in recent memory — most of what is released is not about new things.
Most of this work has been about existing features behaving more correctly, handling more edge cases, and fitting together with other features the way you’d expect.
This in sharp contrast to the most recent release of Chrome that shipped support for the prompt API despite opposition from other browsers and no positive signals from developers. I hope some Googler got a nice promotion for shoving a proprietary technology into a web browser, but they should be aware of the damage they’ve done.
At this year’s CSS Day, the represenatatives from Google Chrome were once again there to talk to developers and ask what we wanted them to prioritise. Those requests rang very hollow. Why should we waste our time and energy telling a browser team what we need if they’re just going to ship whatever crap they want?
The truth is that the folks from Google who were canvassing opinions from the attendees at CSS Day are not the same people who torpedoed the browser with unwanted proprietary tech. This team has spent years doing excellent outreach, documenting web standards, and meeting with developers. They built up an impressive amount of trust, respect, and goodwill.
That stock has now plummeted.
So well done to the Webkit team for Safari 27. And shame on the Chrome team for Chrome 148.
The Session existed in a very basic form since the late 1990s. It was just me posting a different tune every week.
But The Session as it is today—a community website where everyone can add tunes—first went online on June 3rd, 2001. That’s 25 years ago today.
Considering the typical lifespan of a web page, I’m proud of having a website still online and thriving a quarter of a century after launching it.
At this point it’s fair to say that thesession.org is my life’s work. Though, really, I’m just the curator; the site would literally be nothing without all the contributions that people have made to it.
It’s been a great 25 years so far, and I’m looking forward to the next 25.
What a slap in the face of every tech conference that claims it is simply not possible to have a truly representative line-up: multiple perspectives, multiple faces, multiple experiences, rather than the same default one we’ve all been staring at for decades (that’s a white middle aged man in case you’re wondering. I do love you, white middle aged man, but we’ve heard from you, and keep hearing from you. Time to hear from others, too).
Yes, my friend. It is possible. UX London has done it. The Clearleft team has done it. Go look for yourself.
Simply put: AI thrives when our need for originality is low and our demand for mediocrity is high.
AI will fill the world with grindingly average texts, passable but derivative illustration and video, and unoriginal but functional new product designs.
What is being mechanized by AI is our tastes—our ability to discern quality (or originality) at all.
Bhí me i Londain an deireadh seachtaine seo caite mar gheall ar an Gaeltacht cois Tamaise. Cúpla lá iontach ba ea iad!
Bhí na ranganna ar siúl Dé Sathairn agus Dé Domhnaigh, ceithre huaire an chloig gach lá, i gColáiste na Rí. Bhí ceithre leibhéal ann—tosathóiri, meanleibhéal-iseal, meanleibhéal-ard, agus an ardleibhéal. Bhí gach rang lán le foghlaimeoirí.
Roghnaigh mé an rang meanleibhéal-ard agus bhí an leibhéal foirfe. D’fhreastail Jessica ar an rang tosathóirí agus dúirt sí go raibh a mhúinteor iontach deas freisin.
Bhraith sé aisteach a bheith ag labhairt Gaeilge i lár na phriomhcathair Shasana, ach bhain mé go leor sult as!
Roimh na ranganna, bhí imeachta ar siúl ar an Embasáid na hÉireann ar an tráthnóna Dé hAoine; taifeadadh beo ar an bpodchraoladh How To Gael le Louis Cantillon agus Doireann ní Ghlacáin. Éistim leis an podchraoladh, mar sin thapaigh mé an deis iad a fheiceáll beo. Mná cliste agus greanmhar is ea iad!
Bhí imeachta eile ar siúl ar an tráthnóna De Sathairn ach ní raibh mé ann. Chuaigh mé go dtí an teach tabhairne Brendan The Navigator i Highgate—i bhfad ó croílár na caithreach!—mar gheall go raibh seisiún ceoil ann. Seisiún iontach iontach deas a bhí ann le daoine fáiltiúil agus go leor poirt áille.
Beidh mé ar ais!
We’ve seen this arc before, and music is the richest analogy.
Like Bruce Sterling always says:
Whatever happens to musicians happens to everybody.
When I told you about the schedule for UX London 2026, I said:
After your afternoon workshop there’ll be one final closing talk at the end of each day before we head to the bar.
These closing talks are a way of bringing everyone back into the same space after spending the afternoon in different workshops. It feels right to start the day and end the day with a shared experience.
On day one, discovery day, the closing talk will be delivered by Michael Kibedi. It’s called Whose English gets to be default?
Ben Sauer will be giving the closing talk on day two, design day. His talk is called Story before screens.
Finally, on day three, delivery day, the closing talk will be from Lou Downe. It’s called Bad services, which also happens to be the title of their brand new book!
As you can see, each day at UX London is crafted to be a distinct one-day event, but all three days also flow together nicely.
If you haven’t got a ticket yet, grab one now before the standard pricing ends at midnight. And don’t forget that you can use the discount code JOIN_JEREMY to get a tasty 20% off.
AI writing reminds me of Tennyson’s description of the beautiful Maud in the titular poem:
Faultily faultless, icily regular, splendidly null
Dead perfection; no more