Jeremy Keith

What would HTML do? - The Cascade

Whenever I confront a design system problem, I ask myself this one question that guides the way: “What would HTML do?”

HTML is the ultimate composable language. With just a few elements shuffled together you can create wildly different interfaces. And that’s really where all the power from HTML comes up: everything has one job, does it really well (ideally), which makes the possible options almost infinite.

Design systems should hope for the same.

I mentioned that I overhauled the JavaScript on The Session recently. That wasn’t just so that I could mess about with HTML web components. I’d been meaning to consolidate some scripts for a while.

Some of the pages on the site had inline scripts. These were usually one-off bits of functionality. But their presence meant that my content security policy wasn’t as tight as it could’ve been.

Being a community website, The Session accepts input from its users. Literally. I do everything I can to sanitise that input. It would be ideal if I could make sure that any JavaScript that slipped by wouldn’t execute. But as long as I had my own inline scripts, my content security policy had to allow them to be executed with script-src: unsafe-inline.

That’s why I wanted to refactor the JavaScript on my site and move everything to external JavaScript files.

In the end I got close, but there are still one or two pages with internal scripts. But that’s okay. I found a way to have my content security policy cake and eat it.

In my content security policy header I can specifiy that inline scripts are allowed, but only if they have a one-time token specified.

This one-time token is called a nonce. No, really. Stop sniggering. Naming things is hard. And occassionally unintentionally hilarious.

On the server, every time a page is requested it gets sent back with a header like this:

content-security-policy: script-src 'self' 'nonce-Cbb4kxOXIChJ45yXBeaq/w=='

That gobbledegook string is generated randomly every time. I’m using PHP to do this:

base64_encode(openssl_random_pseudo_bytes(16))

Then in the HTML I use the same string in any inline scripts on the page:

<script nonce="Cbb4kxOXIChJ45yXBeaq/w==">
…
</script>

Yes, HTML officially has an attribute called nonce.

It’s working a treat. The security headers for The Session are looking good. I have some more stuff in my content security policy—check out the details if you’re interested.

I initially thought I’d have to make an exception for the custom offline page on The Session. After all, that’s only going to be accessed when there is no server involved so I wouldn’t be able to generate a one-time token. And I definitely needed an inline script on that page in order to generate a list of previously-visited pages stored in a cache.

But then I realised that everything would be okay. When the offline page is cached, its headers are cached too. So the one-time token in the content security policy header still matches the one-time token used in the page.

Most pages on The Session don’t have any inline scripts. For a while, every page had an inline script in the head of the document like this:

<script nonce="Cbb4kxOXIChJ45yXBeaq/w==">
document.documentElement.classList.add('hasJS');
</script>

This is something I’ve been doing for years: using JavaScript to add a class to the HTML. Then I can use the presence or absence of that class to show or hide elements that require JavaScript. I have another class called requiresJS that I put on any elements that need JavaScript to work (like buttons for copying to the clipboard, for example).

Then in my CSS I’d write:

:not(.hasJS) .requiresJS {
 display: none;
}

If the hasJS class isn’t set, hide any elements with the requiresJS class.

I decided to switch over to using a scripting media query:

@media (scripting: none) {
  .requiresJS {
   display: none;
  }
}

This isn’t bulletproof by any means. It doesn’t account for browser extensions that disable JavaScript and it won’t get executed at all in older browsers. But I’m okay with that. I’ve put the destructive action in the more modern CSS:

I feel that the more risky action (hiding content) should belong to the more complex selector.

This means that there are situations where elements that require JavaScript will be visible, even if JavaScript isn’t available. But I’d rather that than the other way around: if those elements were hidden from browsers that could execute JavaScript, that would be worse.

Curious Reading Club

I think this is a terrific idea from Bobbie—be one of 25 people to get a brand new hardcover non-fiction book in the mail for just $25 and then join in the discussion afterwards.

Alas, it’s not available in the UK but US friends, check it out.

AI is not like you and me

AI is the most anthropomorphized technology in history, starting with the name—intelligence—and plenty of other words thrown around the field: learning, neural, vision, attention, bias, hallucination. These references only make sense to us because they are hallmarks of being human.

But ascribing human qualities to AI is not serving us well. Anthropomorphizing statistical models leads to confusion about what AI does well, what it does poorly, what form it should take, and our agency over all of the above.

There is something kind of pathological going on here. One of the most exciting advances in computer science ever achieved, with so many promising uses, and we can’t think beyond the most obvious, least useful application? What, because we want to see ourselves in this technology?

Meanwhile, we are under-investing in more precise, high-value applications of LLMs that treat generative A.I. models not as people but as tools.

Anthropomorphizing AI not only misleads, but suggests we are on equal footing with, even subservient to, this technology, and there’s nothing we can do about it.

The Snowdrop: Lost In the Arctic

If you liked David Grann’s book The Wager, here’s another shipwreck tale, this time from the other side of the world.

React, Electron, and LLMs have a common purpose: the labour arbitrage theory of dev tool popularity – Baldur Bjarnason

An insightful and incisive appraisal of technology adoption. This truth hits hard:

React and the component model standardises the software developer and reduces their individual bargaining power excluding them from a proportional share in the gains. Its popularity among executives and management is entirely down to the fact that it helps them erase the various specialities – CSS, accessibility, standard JavaScript in the browser, to name a few – from the job market. Those specialities might still exist in practice – as ad hoc and informal requirements during teamwork – but, as far as employment is concerned, they’re such a small part of the overall developer job market that they might as well be extinct.

Gregory Bennett chronicles the enshittification of everything online in his piece Heat Death of the Internet. It makes for grim reading.

There’s a note of hope at the end. It’s the same note of hope that Charles Digges amplifies in his great piece, Viva la Library!:

Rebel against The Algorithm. Get a library card.

Molly White has also chronicled the decline of everything good on the web, but her piece has hope threaded throughout. We can have a different web:

Though we now face a new challenge as the dominance of the massive walled gardens has become overwhelming, we have tools in our arsenal: the memories of once was, and the creativity of far more people than ever before, who entered the digital expanse but have grown disillusioned with the business moguls controlling life within the walls.

And if anything, it is easier now to do all of this than it ever was.

Like I’ve repeatedly said, having your own website has gone being something uncontroversial to being downright transgressive.

Still, the barrier to entry remains too high for my liking. I wish more smart minds were working on making publishing on the web easier instead of just working on getting people to consume.

But even if you don’t have your own website, Andrew Stephens says you can still Save the Web by Being Nice:

The very best thing to keep the web partly alive is to maintain some content yourself - start a blog, join a forum and contribute to the conversation, even podcast if that is your thing. But that takes a lot of time and not everyone has the energy or the knowhow to create like this.

The second best thing to do is to show your support for pages you enjoy by being nice and making a slight effort.

To paraphrase Shakespeare, being nice “is twice blest; It blesseth him that gives and him that takes.” Tell someone that you liked something they put on the web. You’ll feel good. They’ll feel even better.

Terence Eden’s Blog

A blog post can be a plain text document uploaded to a server. It can be an image hosted on a social network. It can be a voice note shared with your friends.

Title, dates, comments, links, and text are all optional.

No one is policing this.

It’s OK to Say if You Went Back in Time and Killed Baby Hitler — Big Echo

Primer was a film about a start-up …and time travel. This is a short story about big tech …and time travel.

Do That After This – Terence Eden’s Blog

Good advice for documentation—always document steps in the order that they’ll be taken. Seems obvious, but it really matters at the sentence level.

Alright, so last week I gave you the low-down on each day of this year’s UX London:

1. Tuesday, June 18th focuses on UX research,
2. Wednesday, June 19th focuses on product design, and
3. Thursday, June 20th focuses on design ops and design systems

But the line-up for each day wasn’t quite complete. There was a mystery slot at the end of each day for a closing keynote.

Well, I’m very happy to unveil the trio of fantastic speakers who will be closing out each day…

Rama Gheerawo is the closing speaker on day one. Rama will show you how to frame inclusive design in the context of UX.

I’ve been trying to get Rama for UX London for the past few years but the timings never worked out. I’m absolutely delighted that I’ve finally managed to nab him! His talk is guaranteed to be the perfect inspirational ending for day one.

Matt Webb is giving the closing keynote on day two. Matt will show what it’s like to live and work with AI. You know my scepticism on this topic but even I have to hand it to Matt; he’s finding ways to use these tools to create true delight.

Honestly it feels like a bit of a cheat getting Matt to wrap up the day—his talks are always incredibly entertaining so I feel like I’m taking the easy route. If you’ve seen his appearances at dConstruct you’ll know what I mean.

Maggie Appleton is the final speaker on the final day of UX London. Maggie will show you how to explore designing with large language models. Again, even a sceptic like me has a lot to learn from Maggie’s level-headed humanistic approach to AI.

I’m so happy to have Maggie speaking at UX London. Not only am I a huge fan of her website, but I also love her presentation style. She’s going to entertain and educate in equal measure, and she’s certain to leave us with some fascinating questions to ponder.

With that, the line-up for UX London 2024 is complete …and what a stellar line-up it is!

Grab your ticket if you haven’t already, either for the full full three days or if you can’t manage that, day tickets are available too.

Use this discount code to 20% of the ticket price: JOINJEREMY. I’d love to see you there!

Generated images for non-generated text and video – Baldur Bjarnason

This!

Using extruded synthetic art will not do your writing or video any favours in the long run.

Tim Paul | Automation and the Jevons paradox

This is insightful:

AI and automation is often promoted as a way of handling complexity. But handling complexity isn’t the same as reducing it.

In fact, by getting better at handling complexity we’re increasing our tolerance for it. And if we become more tolerant of it we’re likely to see it grow, not shrink.

From that perspective, large language models are over-engineered bandaids. They might appear helpful at the surface-level but they’re never going to help tackle the underlying root causes.

Motorcycles, Cars, Websites, and Seams - Jim Nielsen’s Blog

Seams.

Intent to Ship: View Transitions Same-Origin Navigation

Finally! View transitions for multi-page apps (AKA websites) will be landing in Chrome soon—here’s hoping other browsers follow suit. Mozilla are up for it. Apple are, as usual, silent on their intentions.

Nice to see a blog post of mine referenced to show that this is a highly-requested feature. Blogging gets results, folks!

An alternative proposal for CSS masonry  |  Blog  |  Chrome for Developers

Rachel responds to Jen’s recent post with the counter-argument; why masonry should be separate from grid.

I’m not entirely convinced. We heard performance issues as a reason why we could never have container queries or :has, but here we are. And the syntax for a separate masonry spec borrows so heavily from grid that it smells of redundancy.