- Tech is dominated by “true believers” and those who tag along to make money.
- Politicians seem to be forever gullible to the promises of tech.
- Management loves promises of automation and profitable layoffs.
But it seems that the sentiment might be shifting, even among those predisposed to believe in “AI”, at least in part.
Some lovely HTML web components—perfect for progressive enhancement!
If you liked David Grann’s book The Wager, here’s another shipwreck tale, this time from the other side of the world.
Primer was a film about a start-up …and time travel. This is a short story about big tech …and time travel.
Robin Sloan on The Culture:
The Culture is a utopia: a future you might actually want to live in. It offers a coherent political vision. This isn’t subtle or allegorical; on the page, citizens of the Culture very frequently articulate and defend their values. (Their enthusiasm for their own politics is considered annoying by most other civilizations.)
Coherent political vision doesn’t require a lot, just some sense of “this is what we ought to do”, yet it is absent from plenty of science fiction that dwells only in the realm of the cautionary tale.
I don’t have much patience left for that genre. I mean … we have been, at this point, amply cautioned.
Vision, on the other hand: I can’t get enough.
As a self-initiated learner, being able to view source brought to mind the experience of a slow walk through someone else’s map.
This ability to “observe” software makes HTML special to work with.
Tammy takes a deep dive into our brains to examine the psychology of web performance. It opens with this:
If you don’t consider time a crucial usability factor, you’re missing a fundamental aspect of the user experience.
I wish that more UX designers understood that!
If there’s one takeaway from all this, it’s that the web is a flexible medium where any number of technologies can be combined in all sorts of interesting ways.
Here’s the video of the talk I gave in Nuremberg recently.
A presentation from border:none held in Nuremberg in October 2023, ten years after the first border:none in 2013.
I want to tell you about a word. And the reaction I had to reading that word. I had a very big reaction to a very small word.
This is the word.
Was.
The past tense of the verb “to be.”
I saw this word and I was struck with a sense of awe.
Now, obviously it’s not just about the word itself—I don’t get struck by feelings of awe anytime anyone says the word “was.” The context matters. Here’s the context…
I was reading the WikiPedia entry for smallpox. Don’t ask me how I ended up here, I don’t remember. But I read the second word in the first sentence, “Smallpox was…” And I think for the first time I really grasped what an astonishing achievement it is to eradicate a deadly disease.
We did that! Humans! Using science! Surely this must stand as one of the greatest achievements of our species?
I was curious as to how this was reported in news outlets at the time. I went searching through newspaper archives on the web to find out.
Here’s an article on Page 21 of The New York Times. It’s five paragraphs long. The first paragraph says:
Smallpox, one of the deadliest and oldest viral diseases of humans, has been eradicated, World Health Organization officials said today in a news conference broadcast here from Geneva.
A few paragraphs down it says:
The health organization began the intensified smallpox eradication program in 1967. In that year, smallpox was reported in 42 countries and killed 2 million people. It also scarred and blinded another eight million people.
In one year! About ten years later, the disease was eradicated! But it was a gradual process.
If something changes gradually, we don’t notice it. We literally exhibit something called change blindness.
But we are hard-wired to notice sudden changes. We pay attention to moments of change.
“Where were you when JFK was assassinated?”
“Where were you on September 11th?”
Nobody is ever going to ask “where were you when smallpox was eradicated?”
We mark the moments when an election is won or lost, the moment war breaks out, the moment a ceasefire is signed.
We also seem to be particular attuned to breaking changes—the moments when bad things happen.
We’re downright suspicious of good news.
We have this phrase: “sounds too good to be true.”
But we don’t have this phrase: “sounds too bad to be true.”
There may well be solid evolutionary reasons for being attuned to danger and threats. But maybe we should occasionally take a step back and notice the changes we’ve been blind to.
What if there were a newspaper that wasn’t published daily or weekly, but once every 100 years? What would the headline on the front page be?
Maybe it would be a moment, like “Yuri Gagarin went into space”—that was a pretty big one!
But maybe the headline would be something we don’t even think about.
Maybe the headline would be about how many more people can read the headline! Adult literacy rates have skyrocketed over the last hundred years—and this is showing percentages, not raw numbers; then the chart would be even more dramatic.
What about a 50 year newspaper? What would the headline be?
Maybe it would be about climate change: “burning coal and oil turns out to have been really bad.” Or maybe the headline would be about the remarkable drop in extreme poverty. Any percentage is still too much, but still, look at that rapid fall… particularly over the last 25 years.
Every single day, a real-time newspaper could’ve run the headline:
“130,000 People Escape Extreme Poverty Today”
…but no newspaper has every reported that. Sounds too good to be true.
What about a newspaper published once every 25 years?
Maybe the headline would still be about the drop in extreme poverty. Or maybe the headline would be about the equally steep drop in violent crime. Or deaths in natural disasters.
Or perhaps the editor would run with the story of infant mortality rates being halved. This time we are looking at the raw numbers; if this were percentages of the world population, the effect would be even more dramatic.
What about a newspaper published every 10 years? That’s the time frame we’re looking at here today, right?
For a newspaper published once a decade, I reckon today’s headline would probably be about climate change and the environment.
Maybe this is the most surprising development in the last 10 years: the huge increase in solar and wind energy. There’s a corresponding graph showing an equally dramatic drop in price, especially for solar.
We could be looking at part of an exponential curve here—time will tell!
But let’s get more specific. Let’s look at the World Wide Web.
How has the web changed since I was standing here 10 years ago?
Thanks to the internet archive, I can show what my own website looked like at the moment I was speaking at the first border: none.
Now let’s compare this to how my website looks today…
Hmmm …not exactly an astonishing amount of change, is it?
I think we need to go further back than 10 years. I think we need to go all the way back.
This is the first website ever made, displayed in the first web browser ever made. They were both made by Tim Berners-Lee 30 years ago. And this website is still online today at its original URL, because it’s cool.
The World Wide Web was somewhat lacking in colour originally. When I started making websites in the mid nineties, colour had arrived but it was limited.
We had a palette of 216 web safe colours. You knew if a colour was “web safe” if the hexadecimal notation was three sets of duplicated values. If you altered one of those values even slightly, there was no guarantee that the colour would display consistently on the monitors of the time. I have a confession to make: I kind of liked this constraint in a weird way. To this day, if I have a colour value that’s almost web-safe, I can’t resist nudging it slightly.
Fortunately, monitors improved. They got flatter for one thing. They were also capable of displaying plenty of colours.
And we also got more and more ways of specifying colours. As well as hexadecimal, we got RGB: Red, Green, Blue. Better yet, we got RGBa …with alpha transparency. That’s opacity to you and me.
Then we got HSL: hue, saturation, lightness. Or should I say HSLa: hue, saturation, lightness, and alpha transparency.
And there are more colour spaces available today. HWB (hue, whiteness, blackness), LAB, LCH. And now we’ve got a color() function so you can specify even more colour spaces.
Sounds too good to be true.
In the beginning, typography on the World Wide Web was non-existent. Your browser used whatever was available on your operating system.
That situation continued for quite a while. You’d have to guess which fonts were likely to be available on Windows or Mac.
If you wanted to use a sans-serif typeface, there was Arial on Windows and Helvetica on the Mac. Verdana was a pretty safe bet too.
For a while your only safe option for a serif typeface was Times New Roman. When Mathew Carter’s Georgia was released, it was a godsend. Here was a typeface specifically designed for the screen.
Later Microsoft released another four fonts designed for the screen. Four new fonts! It felt like we were being spoiled.
But what if you wanted to use a typeface that didn’t come installed with an operating system? Well, you went into Photoshop and made an image of the text. Now the user had to download additional images. The text wasn’t selectable and it was a fixed width.
We came up with all sorts of clever techniques to do what was called “image replacement” for text. Some of the techniques involved CSS and background images. One of the techniques involved Flash. It was called sIFR: Scalable Inman Flash Replacement. A later technique called Cufón converted the letter shapes into paths in Canvas.
All of these techniques were hacks. Very clever hacks, but hacks nonetheless. They were clever and they worked but they always reminded me of Samuel Johnson’s description of a dog walking on its hind legs:
It is not done well but you are surprised to find it done at all.
What if you wanted to use an actual font file in a web page?
There was only one browser that supported font embedding: Microsoft’s Internet Explorer. The catch was that you had to use a proprietary font format called Embedded Open Type.
Both type foundries and browser makers were nervous about allowing regular font files to be embedded in web pages. They were worried about licensing. Wouldn’t this lead to even more people downloading fonts illegally? How would the licensing be enforced?
The impasse was broken with a two-pronged approach. First of all, we got a new font format called Web Open Font Format or WOFF. It could be used to take a regular font file and wrap it in a light veneer of metadata about licensing. There’s a sequel that’s even better than the original, WOFF2.
The other breakthrough was the creation of intermediary services like Typekit and Fontdeck. They would take care of serving the actual font files, making sure they couldn’t be easily downloaded. They could also keep track of numbers to ensure that type foundries were being compensated fairly.
Over time it became clear to type foundries that most web designers wanted to do the right thing when it came to licensing fonts. And so these days, you can probably license a font straight from a type foundry for use on the web and host it yourself.
You might need to buy a few different weights. Regular. Bold. Maybe italic. What about extra bold? Or a light weight? It all starts to add up, especially for the end user who has to download all those files.
I remember being at the web typography conference Ampersand years ago and hearing a talk from Nick Sherman. He asked us to imagine one single font file that could go from light to regular to bold and everything in between. What he described sounded like science fiction.
It is now science fact, indistinguishable from magic. Variable fonts are here. You can typeset text on the web to be light, or regular, or bold, or anything in between.
When you use CSS to declare the font-weight property, you can use keywords like “normal” or “bold” but you can also use corresponding numbers like 400 or 700. There’s a scale with nine options from 100 to 900. But why isn’t the scale simply one to nine?
Well, even though the idea of variable fonts would have been pure fantasy when this part of CSS was being specced, the authors had some foresight:
One of the reasons we chose to use three-digit numbers was to support intermediate values in the future.
With the creation of variable fonts, Håkon Wium Lee added:
And the future is now.
On today’s web you could have 999 font-weight options.
Sounds too good to be true.
In the beginning, the World Wide Web was a medium for text only. There were no images and certainly no videos.
In an early mailing list discussion, there was talk of creating a new HTML element for images. Perhaps it should be called “icon”. Or maybe it should be more generic and be called “embed”. Tim Berners-Lee said he imagined using the rel attribute on the A element for embedding images.
While this discussion was happening, Marc Andreessen popped in to say that he had just shipped a new HTML element in the Mosaic browser. It’s called IMG and it takes an attribute called SRC that points to the source of the image.
This was a self-closing tag so there was no way to put fallback content in between the opening and closing tags if the image couldn’t be displayed. So the ALT attribute was introduced instead to provide an alternative description of the image.
For the images themselves, there were really only two choices. JPG for photographic images. GIF for icons or anything that needed basic transparency. GIFs could also do animation and today, that’s pretty much all they’re used for. That’s because there was a concerted campaign to ditch the GIF format on the web. Unisys, who owned the rights to a compression algorithm used by the GIF format, had started to make noises about potentially demanding license fees for its use.
The Portable Network Graphics format—or PNG—was created in response. It was more performant and it allowed you to have proper alpha transparency.
These were all bitmap formats. What if you wanted a vector format for images that would retain crispness at any size or resolution? There was only one option: Flash. You’d have to embed a Flash movie in your web page just to get the benefit of vector graphics.
By the 21st century there were some eggheads working on a text-based vector file format that could be embedded in webpages, but it sounded like a pipe dream. It was called SVG for Scalable Vector Graphics. The format was dreamed up in 2001 but for years, not a single browser supported it. It was like some theoretical graphical Shangri-La.
But by 2011, every major browser supported it. Styleable, scriptable, animatable, vector graphics have gone from fantasy to reality.
There’s more choice in the world of bitmap images too. WebP is well supported. AVIF is is gaining support.
The IMG element itself has grown too. You can use the srcset attribute to give the browser a range of images to choose from to best suit the user’s device and network connection. You can use the loading attribute to get lazy loading of images for free—no JavaScript required.
We now have audio in HTML. No JavaScript required. We now have video in HTML. No JavaScript required.
These elements have been designed with more thought than the IMG element. They are not self-closing elements, by design. You can put fallback content between the opening and closing tags.
The audio and video elements arrived long after the IMG element. For a long time, there was no easy way to do video or audio on the web.
That was very frustrating for me. The first websites I ever built were for bands. The only way to stream music was with a proprietary plug-in like Real Audio.
Or Flash.
While the web standards were still being worked on, Flash delivered the goods with streaming audio and video. This happened over and over. Flash gave us vector graphics, animation, video, and more. But the price was lock-in. Flash was a proprietary format.
Still, Flash showed the web standards bodies the direction of travel. Flash was the hare. Web standards were the tortoise.
We know how that race ended.
In a way, Flash was like the Research and Development incubator for the World Wide Web. We got CSS animations, SVG, and streaming video because Flash showed that there was an appetite for them.
Until web standards provide a way to do something, designers and developers will reach for whatever tool gets the job done. Take layout, for example.
In the early days of the web, you could have any layout you wanted …as long as it was a single column.
Before long, HTML expanded to provide some rudimentary formatting for that single column of text. Presentational elements and attributes were invented. And even when elements and attributes weren’t meant to be used for formatting, people got creative.
Tables for layout. A single pixel GIF that could be given width and height. These were clever solutions. But they were hacks. And they were in danger of turning HTML into a presentational language instead of a language for structuring content.
CSS came to the rescue. A language specifically for presentation. But we still didn’t get proper layout tools. There was a lot of debate in the early days about whether CSS should even attempt to provide layout tools or whether that was a job for a separate technology.
We could lay things out using the float property, but really that was just another hack.
Floats were an improvement over tables for layout, but we only swapped one tool for another. Our collective thinking still wasn’t very web-like.
For example, designers and developers insisted on building websites with a fixed width. This started in the era of table layouts and carried over into CSS.
To start with, the fixed width was 640 pixels. Then it was 800 pixels. Then people settled on the magical number of 960 pixels. Designers and developers didn’t seem at all concerned that people had different sized screens.
That was until the iPhone came out. Everyone shat the bed. What fixed width were we supposed to design for now?
The answer was there all along. Even before the web appeared in mobile devices, it was possible to build fluid layouts that would adapt to screen size. It’s just that the majority of designers and developers chose not to build in this way.
I was pleased that mobile came along and shook things up. It exposed the assumptions that people were making. And it forced designers and developers to think in a more fluid, webby way.
Even better, CSS had expanded to include media queries so it was possible to alter layouts at different breakpoints.
Ethan came along and put a nice bow on it with his definition of responsive design: fluid media, fluid layouts, and media queries.
I fell in love with responsive web design instantly becuase it matched how I was already thinking about the web. I was one of the handful of weirdos who insisted on building fluid websites when everyone else was using fixed-width layouts.
But I thought that responsive web design would struggle to take hold. I’m delighted to say that I was wrong. Responsive web design has become the default!
If I could go back to my past self in the mid 2000s, I’d love to tell them that in the future, everyone would be building with fluid layouts (and also that time travel had been invented apparently).
Not only that, but we finally have proper layout tools for the web. Flexbox. Grid. No more hacks. We’ve even got container queries, which for years we were told were literally too good to be true.
Web browsers now are positively overflowing with fantastic design tools that would have been unimaginable to my past self. Support for these technologies is pretty much universal.
When browsers differ today, it’s only terms of which standards they don’t yet support.
The web has come along way. It has grown and evolved. Browsers have become more and more powerful while maintaining backward compatibility.
In the past we had to hack our way around the technological limitations of the web and we had a long wish list of features we wanted.
I’m not saying we’re done. I’m sure that more features will keep coming. But our wish list has shrunk.
The biggest challenges facing the World Wide Web today are not technical challenges.
Today it is possible to create beautiful websites that make full use of colour, typography, layout, animation, and more. But this isn’t what users experience.
This is what users experience. A tedious frustrating game of whack-a-mole with websites that claim to value our privacy while asking us to relinquish it.
This is not a technical problem. It is a design decision. The decision might not be made by anyone with designer in their job title, but make no mistake, business decisions have a direct effect on user experience.
On the face of it, the problem seems to be with the business model of advertising. But that’s not quite right. To be more precise, the problem is with the business model of behavioural advertising. That relies on intermediaries to amass huge amounts of personal data so that they can supposedly serve up relevant advertising.
But contextual advertising, which serves up ads based on the content you’re looking at doesn’t require the invasive collection of personal data. And it works. Behavioural advertising, despite being a huge industry that depends on people giving up their privacy, doesn’t even work very well. And on the few occasions when it does work, it just feels creepy.
The problem is not advertising. The problem is tracking. The greatest trick the middlemen ever pulled was convincing us that you can’t have effective advertising without tracking. That is false. But they’ve managed to skew our sense of perspective so that invasive advertising seems inevitable.
Advertising was always possible on the web. You could publish anything and an ad is just one more thing you could choose to publish. But tracking was impossible. That’s because the early web was stateless. A browser requests a resource from a server and once that transaction is done, they both promptly forget about it. That made it very hard to do things like online shopping or logging into an account.
Two technologies were created later that enabled state on the web. Cookies and JavaScript. If these technologies had been limited to a same origin policy (like how cookies were originally specified), they would have nicely solved the problems of online shopping and authentication.
But these technologies work across domains. Third party cookies and third-party JavaScript enables users to be tracked as they move from site to site. The web gone from having no state to having too much.
There is hope. Browsers like Firefox and Safari are blocking third-party cookies by default. Personally, I’d love it if third-party JavaScript got the same treatment. You can also install add-ons to make your browser more secure, although these add-ons are often labelled ad-blockers, which is a shame. Because the problem is not advertising. The problem is tracking.
Perhaps none of this applies to you anyway. You may be thinking that this is a problem for websites. But you build web apps that don’t rely on behavioural advertising.
As I said here ten years ago, I’m not keen on the idea of dividing the entirety of the World Wide Web into two vaguely-defined categories. Ten years on, I still have yet to hear a good definition of “web app” other than “a website that requires JavaScript to work.”
But the phrase “single page app” has a more definite meaning. It refers to an architectural decision. That decision is to reinvent the web browser inside a web browser.
In a sense, it’s a testament to the power of JavaScript that you can choose to do this. Browsers render content and perform navigations, but if you’d rather recreate that functionality from scratch in JavaScript, you can.
But should you? Browsers have increased in complexity so that we can build without complexity. We can use the built-in power of modern HTML, CSS, and JavaScript to make web browsers do the work. If we work with the grain of the web, we can accomplish more and more with less and less code.
But that isn’t what happened. Instead developers have recreated form controls like dropdowns and datepickers from scratch using divs and lashings and lashings of JavaScript.
Perhaps this points to some missing features on the web. It’s still too hard to style native dropdowns and datepickers (but that’s being worked on—there’s standards work underway to give us more styling control over form elements). But that doesn’t explain why developers would choose to recreate something like a button using divs and JavaScript when the button element already exists and can be styled any way you like.
I think there’s a certain mindset being applied to web development here. And that mindset comes from the world of software. Again, it’s a testament to how far the web has come that it can be treated as a software platform on par with operating systems like iOS, Android, or Windows. There’s a lot to be learned from the world of software development, like testing, for example. But the web is different. When a user navigates to a URL, it shouldn’t feel like they’re installing a piece of software.
We should be aiming to keep our payloads as small as possible. And given how powerful browsers have become, we need fewer and fewer dependencies—fewer and fewer polyfills.
But performance has gotten worse. Payloads have gotten bigger. Dependencies like JavaScript frameworks have become more and more widespread even as they became less and less necessary.
When asked to justify the enormous payloads, web developers have responded by saying that user’s expectations have changed. That is correct, but not in the way that I think they mean.
When I talk to people about using the web—especially on mobile—their expectations are that they will have a terrible experience. That websites will be slow to load. And I guarantee you that none of them are saying, “Well I’d be annoyed if this were a website but seeing as this is a web app, I’m absolutely fine with this terrible experience.”
I said that the biggest challenges facing the World Wide Web today are not technical challenges. I think the biggest challenge facing the web today is people’s expectations.
There is no technical reason for websites or web apps to be so frustrating. But we have collectively led people to expect a bad experience on the web.
Our intentions may be have good. We thought users wanted nice page transitions and form elements that were on-brand. But if you talk to people, you find out that what they want is to accomplish their task without megabytes of JavaScript getting in the way.
There’s a great German word, “Verschlimmbessern”: the act of making something worse in the attempt to make it better. Perhaps we verschlimmbessert the web.
Let’s step back. Get some perspective. Instead of assuming that a single page app architecture is needed, ask what users need to accomplish. Instead of assuming you need a CSS framework or a JavaScript library, see what you can do in browsers today with native CSS and vanilla JavaScript. Don’t include a bunch of dependencies by default just in case you might need them. Instead, as Rachel puts it:
Stop solving problems you don’t yet have.
Lean into what web browsers can accomplish today. If you find something missing, that’s the time to reach for a library …but treat it like a polyfill. Whereas web standards stick around, every library and framework comes with a limited lifespan. Treat them as cattle, not pets.
I understand that tools and frameworks can make your life easier. And if we’re talking about server-side frameworks, then I say “Go for it.” Or if you’re using build tools that sit on your computer to do version control, linting, pre-processing, or transpiling, then I say “Go for it.” But once you make users download tools or frameworks, you’re making them pay a tax for your developer convenience.
We need to value user needs above developer convenience. If I have the choice of making something the user’s problem or making it my problem, I’ll make it my problem every time. That’s my job.
We need to change people’s expectations of the World Wide Web, especially on mobile. Otherwise, the web will be lost.
In 2019, I had the great honour of being invited to CERN to mark the 30th anniversary of the original proposal for the World Wide Web. One of the other people there was the journalist Zeynep Tüfekçi. She was on a panel along with Tim Berners-Lee and other luminaries of the early web. At the end of the panel discussion, she was asked:
What would you tell the next generation about how to use this wonderful tool?
She replied:
If you have something wonderful, if you do not defend it, you will lose it. If you do not defend the magic and the things that make it wonderful, it’s just not going to stay magical by itself.
I believe that we can save the web. I believe that we can change people’s expectations. We’ll do that by showing them what the web is capable of.
In 2013, I spoke at the border:none event in Nuremberg. I gave a talk called The Power of Simplicity.
It was a great little event. Most of the talks were, like mine, on technical topics; design, development, the usual conference material.
This year Joschi and Marc decided to have another border:none event ten years on from the first one. They invited back all the original speakers, as well as some new folks. They kept the ticket price the same as ten years ago—just thirty euros.
For us speakers from the previous event, the only brief they gave us was to consider what’s happened in the past decade. I played it pretty safe and talked about the web. I’ll post a transcript of my talk soon.
Some of the other speakers were far more ambitious. They spoke about themselves, the world, the meaning of life …my presentation was very tame in comparison.
I really, really admire the honesty and vulnerability that those people displayed. Tobias Baldauf in particular took my breath away. He delivered an intensely personal talk on generational trauma that was meticulously researched and took incredible bravery to deliver. It was worth going to Nuremberg just for the privilege of being present for that talk.
Other talks were refreshingly tech-free. There was a talk on cold-water swimming. There was a talk on paragliding. And I don’t mean they were saying “what designers can learn from cold-water swimming” or “how I became a better developer through paragliding.” The talks were literally about swimming and paragliding.
There was a great variety of speakers this time around, include age ranges from puberty to menopause (quite literally—that was the topic of one of the talks). I had the great pleasure of providing some coaching before the event to fifteen year old Maya who was delivering her first talk in English. She did a fantastic job! And the talk she gave—about how teachers in her school aren’t always trusting of the technology they provide to students—was directly relevant to what we’re seeing in the world of work. Give people autonomy, agency and trust.
There was a lot of trust at border:none. Everyone who bought a ticket did so on trust—they had no idea what to expect. Likewise, Marc and Joschi put their trust in the speakers. They gave the speakers the freedom to talk about whatever they wanted. That trust was repayed.
Florian took some superb pictures of the event. Matthias wrote up his experience. So did Tom. Valisis shared the gist of his excellent talk.
At the end of the event there was some joking about returning in 2033. I love the idea of a conference that happens once every ten years. Count me in!
Time capsules on the moon, using NanoFiche as the storage medium.
Last week Phil posted a little update about his excellent site, ooh.directory:
If you’re in the habit of visiting the Recently Updated Blogs page, and leaving it open, the times when each blog was updated will now keep up with the relentless passing of time.
Does that make sense? “3 minutes ago” will change to “4 minutes ago” and so on and on and on, until you refresh the page.
I thought that was a nice little addition, and I immediately thought of The Session. There are time elements all over the site with relative times as the text content: 2 minutes ago, 7 hours ago, 1 year ago, and so on. Those strings of text are generated on the server. But I figured it would be nice enhancement to periodically update them in the browser after the page has loaded.
I viewed source to see how Phil was doing it. The code is nice and short, using a library called Day.js with a plug-in for relative time.
“Hang on”, I thought, “isn’t there some web standard for doing this kind of thing?” I had a vague memory of some JavaScript API for formatting dates and times.
Sure enough, we’ve now got the Intl.RelativeTimeFormat object. It’s got browser support across the board.
I’ve got a function that loops through all the time elements with datetime attributes. It compares the current timestamp to that value to get the elapsed time. Then that’s formatted using the format() method and output as innerText.
You need to tell the format() method which units you want to use: seconds, minutes, hours, days, etc. So there’s a little bit of looping to figure out which unit is most appropriate. If the elapsed time is less than a minute, use seconds. If the elapsed time is less than an hour, use minutes. If the elapsed time is less than a day, use hours. You get the idea.
It’s a pity there isn’t some kind of magic unit like “auto” to do this, but it’s not much extra code to figure it out.
Anyway, that function runs periodically using setInterval(). I’ve set it to run every 30 seconds in my gist. On The Session I’ve set it to one minute.
You’ll notice that I’m grabbing all the relevant time elements—using document.querySelector('time[datetime]')—every time the function is run. That may seem inefficient. Couldn’t I just grab them once and then keep them stored as an array? But I want this to work even if the page contents have been updated with Ajax. (Do people even say “Ajax” any more? Get off my lawn, you pesky kids!)
I think I’ve written this code in an abstract way so that you should be able to drop it into any web page. For the calculations to work, you’ll need to either make sure that your datetime attributes are using timezones. Or, if there’s no timezone info, UTC is assumed.
This was a fun little piece of functionality to play around with. Now I know a little more about this Intl.RelativeTimeFormat object. The way I’m using it as a classic example of progressive enhancement. If a browser doesn’t support it, or if my code breaks, it’s no big deal. The funtionality is a little bonus that almost nobody will notice anyway. Just a small delighter …if you’re the kind of person who finds it delightful when relative time strings automatically update.
Where and when were these photographs taken?
It’s like that Chronophoto game I linked to with an added dimension of location.
There are two kinds of time-travel stories.
There are time-travel stories that explore the many-worlds hypothesis. Going back in time and making a change forks the universe. But the universe is constantly forking anyway. So effectively the time travel is a kind of universe-hopping (there’s a big crossover here with the alternative history subgenre).
The problem with multiverse stories is that there’s always a reset available. No matter how bad things get, there’s a parallel universe where everything is hunky dory.
The other kind of time travel story explores the idea of a block universe. There is one single timeline.
This is what you’ll find in Tenet, for example, or for a beautiful reduced test case, the Ted Chiang short story What’s Expected Of Us. That gets straight to the heart of the biggest implication of a block universe—the lack of free will.
There’s no changing what has happened or what will happen. In fact, the very act of trying to change the past often turns out to be the cause of what you’re trying to prevent in the present (like in Twelve Monkeys).
I’ve often referred to these single-timeline stories as being like Greek tragedies. But only recently—as I’ve been reading quite a bit of Greek mythology—have I realised that the reverse is also true:
Greek tragedies are time-travel stories.
Hear me out…
Time-travel stories aren’t actually about physically travelling in time. That’s just a convenience for the important part—information travelling in time. That’s at the heart of most time-travel stories; informaton from the future travelling back to the past.
William Gibson’s The Peripheral—very much a many-worlds story with its alternate universe “stubs”—takes this to its extreme. Nothing phyiscal ever travels in time. But in an age of telecommuting, nothing has to. Our time travellers are remote workers.
That book also highlights the power dynamics inherent in information wealth. Knowledge of the future gives you an advantage that you can exploit in the past. This is what Mark Twain’s Connecticut yankee does in King Arthur’s court.
This power dynamic is brilliantly inverted in Octavia Butler’s brilliant Kindred. No amount of information can help you if your place in society is determined by the colour of your skin.
Anyway, the point is that information flow is what matters in time-travel stories. Therefore any story where information travels backwards in time is a time-travel story.
That includes any story with a prophecy. A prophecy is information about the future, like:
Oedipus will kill his father and marry his mother.
You can try to change your fate, but you’ll just end up triggering it instead.
Greek tragedies are time-travel stories.
Spring is arriving. It’s just taking its time.
There are little signs. Buds on the trees. The first asparagus of the year. Daffodils. Changing the clocks. A stretch in the evenings. But the weather remains, for the most part, chilly and grim.
Reality is refusing to behave like a fast-forward montage leading up to to a single day when you throw open the curtains and springtime is suddenly there in all its glory.
That’s okay. I can wait. I’ve had a lot of practice over the past three years. We all have. Staying home, biding time, saving lives.
But hunkering down during The Situation isn’t like taking shelter during an air raid. There isn’t a signal that sounds to indicate “all clear!” It’s more like going from Winter to Spring. It’s slow, almost impercetible. But it is happening.
I’ve noticed a subtle change in my risk assessment over the past few months. I still think about COVID-19. I still factor it into my calculations. But it’s no longer the first thing I think of.
That’s a subtle change. It doesn’t seem like that long ago when COVID was at the forefront of my mind, especially if I was weighing up an excursion. Is it worth going to that restaurant? How badly do I want to go to that gig? Should I go to that conference?
Now I find myself thinking of COVID as less of a factor in my decision-making. It’s still there, but it has slowly slipped down the ranking.
I know that other people feel differently. For some people, COVID slipped out of their minds long ago. For others, it’s still very much front and centre. There isn’t a consensus on how to evaluate the risks. Like I said:
It’s like when you’re driving and you think that everyone going faster than you is a maniac, and everyone going slower than you is an idiot.
COVID-19 isn’t going away. But perhaps The Situation is.
The Situation has been gradually fading away. There isn’t a single moment where, from one day to the next, we can say “this marks the point where The Situation ended.” Even if there were, it would be a different moment for everyone.
As of today, the COVID-19 app officially stops working. Perhaps today is as good a day as any to say Spring has arrived. The season of rebirth.
I have a very simple rule that serves me well: Don’t think too much about your life after dinnertime.
A lovely bit of real-time data visualisation from Robin:
It’s a personal project created at home in Wales with an aim to explore and visualise renewable energy systems. Specifically, it aims to visualise live generation from renewable energy systems around Great Britain and to show where that generation is physically coming from.
Temporal standards bodies.
Matt made this lovely website for spelunking and hyperlinking through the thousand episodes of Radio 4’s excellent In Our Time programme.
He’s also written a little bit about how he made it using some AI (artificial insemination) for the categorisation code.