Jeremy Keith

Jeremy Keith

Making websites. Writing books. Hosting a podcast. Speaking at events. Living in Brighton. Working at Clearleft. Playing music. Taking photos. Answering email.

Journal 2892 sparkline Links 9575 sparkline Articles 82 sparkline Notes 6557 sparkline

Monday, August 1st, 2022

Checked in at The Park Crescent. New Monday evening session ☘️🎶 — with Jessica map

Checked in at The Park Crescent. New Monday evening session ☘️🎶 — with Jessica

Sunday, July 31st, 2022

Equality vs. Equity :: Aaron Gustafson

Though I didn’t make the connection until much later, the philosophy of progressive enhancement in web design, which I’ve been advocating for nearly two decades now, is very much the embodiment of equity. It’s concerned with building interfaces that adapt to a wide range of circumstances, both tied to an individual user’s capabilities as well as those of the devices, networks, and environment in which they are accessing our creations.

Friday, July 29th, 2022

Thursday, July 28th, 2022

There’s an interesting Venn diagram to be made of the people in my social circles mourning the passing of James Lovelock, Bernard Cribbins, and Mick Moloney today.

Wednesday, July 27th, 2022

Checked in at Jolly Brewer. Wednesday evening session 🎻🎻🎻 — with Jessica map

Checked in at Jolly Brewer. Wednesday evening session 🎻🎻🎻 — with Jessica

How Florence Nightingale Changed Data Visualization Forever - Scientific American

The design process in action in Victorian England:

Recognizing that few people actually read statistical tables, Nightingale and her team designed graphics to attract attention and engage readers in ways that other media could not. Their diagram designs evolved over two batches of publications, giving them opportunities to react to the efforts of other parties also jockeying for influence. These competitors buried stuffy graphic analysis inside thick books. In contrast, Nightingale packaged her charts in attractive slim folios, integrating diagrams with witty prose. Her charts were accessible and punchy. Instead of building complex arguments that required heavy work from the audience, she focused her narrative lens on specific claims. It was more than data visualization—it was data storytelling.

Practice the future | A Working Library

I want to posit that, in a time of great uncertainty—in an era of climate change and declining freedom, of attrition and layoffs and burnout, of a still-unfolding rearrangement of our relationship to work—we would do well to build more space for practicing the future. Not merely anticipating it or fearing it or feeding our anxiety over the possibilities—but for building the skill and strength and habits to nurture the future we need. We can’t control what comes next, of course. But we can nudge, we can push, we can guide and shape, we can have an impact. We can move closer to the future we want to live in, no matter how far away it seems to be.

Tuesday, July 26th, 2022

The line-up for dConstruct 2022 …revealed!

Alright, I’ve kept you in suspense for long enough. It’s time to reveal the magnificent line-up for dConstruct 2022.

I’ll now put names to the teasing list of descriptions I previously provided

A technologist, product designer, and writer who defies categorisation. They’ve headed up a design studio, co-founded a start-up, and now consult on super-clever machine learning stuff. Their blog is brilliant.

This is Matt Webb. Matt previously spoke at dConstruct back in 2007, when he gave a talk called The Experience Stack

An award-winning author from South Africa whose work has recently been adapted for television. Some of their work is kind of sci-fi, some of it is kind of horror, some of it is kind of magical realism, and all of it is great.

This is Lauren Beukes. Lauren previously spoke at dConstruct in 2012, when she gave a talk called Imagined Futures.

An artist and designer who has created logos and illustrations for NASA, Apple, and Intel as well as custom typefaces for British Airways and Waitrose. A lover of letterforms, they are now one of the world’s highest-profile calligraphers posting their mesmerising work on Instagram.

This is Seb Lester.

A Canadian digital designer who has previously worked in the agency world, at Silicon Valley startups, and even venture capital. But now they’re doing truly meaningful work, designing for busy healthcare workers in low-income countries.

This is Daniel Burka. Daniel previously spoke at dConstruct back in 2008, when he gave a talk called Designing for Interaction.

A multi-instrumentalist musician, producer and robotic artist who composes for film, theatre and the concert stage. They play a mean theremin.

This is Sarah Angliss. Sarah previously spoke at dConstruct in 2013, when she gave a talk called Tech and the Uncanny.

An Australian designer and entrepreneur. They work in the cultural heritage sector and they’re an expert on digital archives. Their latest challenge is working out how to make an online photography archive last for 100 years.

This is George Oates. George previously spoke at dConstruct back in 2007, where she and Denise Wilton had a conversation called Human Traffic.

A tireless defender of web standards and co-author of the Inclusive Design Principles. They’re a member of the W3C Advisory Board and of the BIMA Inclusive Design Council. Expect some thoughtful takes on the intersection of accessibility and emerging technologies.

This is Léonie Watson.

A professor of neuroscience who is also a bestselling author. They conduct experiments on people’s brains and then talk about it afterwards. Their talks have been known to be mind-altering.

This is Anil Seth.

That’s quite a line-up, isn’t it?

Deducing the full line-up just from those descriptions wasn’t easy, but Hidde de Vries managed it. So Hidde gets a free ticket to dConstruct 2022 …or, at least, he would if it weren’t for the fact that he already has a ticket (because Hidde is smart; be like Hidde). So a friend of Hidde’s is getting a free ticket instead (because Hidde is generous; be like Hidde).

If you’ve been putting off getting a ticket for dConstruct 2022 until you knew what the line-up would be, well, put off no longer.

You’ll want to be at the Duke of York’s in Brighton on Friday, September 9th. With this line-up of eight supersmart speakers, you know it’s going to be a fantastic day!

A good reset | Trys Mudford

Prompted by my recent post about using native button elements, Trys puts forward a simple explanation for why someone would choose to use a div instead.

The one common feature between every codebase I’ve encountered on that doesn’t use buttons well, is a bad CSS reset. Developers try to use a button, and find that it still looks like a native browser button, so they grab a plain old, blank canvas div, and build from there.

Occam’s Razor makes Trys’s explanation the most likely one.

Monday, July 25th, 2022


In two of my recent talks—In And Out Of Style and Design Principles For The Web—I finish by looking at three different components:

  1. a button,
  2. a dropdown, and
  3. a datepicker.

In each case you could use native HTML elements:

  1. button,
  2. select, and
  3. input type="date".

Or you could use divs with a whole bunch of JavaScript and ARIA.

In the case of a datepicker, I totally understand why you’d go for writing your own JavaScript and ARIA. The native HTML element is quite restricted, especially when it comes to styling.

In the case of a dropdown, it’s less clear-cut. Personally, I’d use a select element. While it’s currently impossible to style the open state of a select element, you can style the closed state with relative ease. That’s good enough for me.

Still, I can understand why that wouldn’t be good enough for some cases. If pixel-perfect consistency across platforms is a priority, then you’re going to have to break out the JavaScript and ARIA.

Personally, I think chasing pixel-perfect consistency across platforms isn’t even desirable, but I get it. I too would like to have more control over styling select elements. That’s one of the reasons why the work being done by the Open UI group is so important.

But there’s one more component: a button.

Again, you could use the native button element, or you could use a div or a span and add your own JavaScript and ARIA.

Now, in this case, I must admit that I just don’t get it. Why wouldn’t you just use the native button element? It has no styling issues and the browser gives you all the interactivity and accessibility out of the box.

I’ve been trying to understand the mindset of a developer who wouldn’t use a native button element. The easy answer would be that they’re just bad people, and dismiss them. But that would probably be lazy and inaccurate. Nobody sets out to make a website with poor performance or poor accessibility. And yet, by choosing not to use the native HTML element, that’s what’s likely to happen.

I think I might have finally figured out what might be going on in the mind of such a developer. I think the issue is one of control.

When I hear that there’s a native HTML element—like button or select—that comes with built-in behaviours around interaction and accessibility, I think “Great! That’s less work for me. I can just let the browser deal with it.” In other words, I relinquish control to the browser (though not entirely—I still want the styling to be under my control as much as possible).

But I now understand that someone else might hear that there’s a native HTML element—like button or select—that comes with built-in behaviours around interaction and accessibility, and think “Uh-oh! What if there unexpected side-effects of these built-in behaviours that might bite me on the ass?” In other words, they don’t trust the browsers enough to relinquish control.

I get it. I don’t agree. But I get it.

If your background is in computer science, then the ability to precisely predict how a programme will behave is a virtue. Any potential side-effects that aren’t within your control are undesirable. The only way to ensure that an interface will behave exactly as you want is to write it entirely from scratch, even if that means using more JavaScript and ARIA than is necessary.

But I don’t think it’s a great mindset for the web. The web is filled with uncertainties—browsers, devices, networks. You can’t possibly account for all of the possible variations. On the web, you have to relinquish some control.

Still, I’m glad that I now have a bit more insight into why someone would choose to attempt to retain control by using div, JavaScript and ARIA. It’s not what I would do, but I think I understand the motivation a bit better now.

Sunday, July 24th, 2022

Checked in at The Bugle Inn. Sunday afternoon session ☘️🎶🎻 map

Checked in at The Bugle Inn. Sunday afternoon session ☘️🎶🎻