Tags: pi

The caching strategy for The Session that I wrote about is working a treat.

There are currently about 45,000 different tune settings on the site. One week after introducing the server-side caching, over 40,000 of those settings are already cached.

But even though it’s currently working well, I’m going to change the caching mechanism.

The eagle-eyed amongst you might have raised an eagle eyebrow when I described how the caching happens:

The first time anyone hits a tune page, the ABCs getting converted to SVGs as usual. But now there’s one additional step. I grab the generated markup and send it as an Ajax payload to an endpoint on my server. That endpoint stores the sheetmusic as a file in a cache.

I knew when I came up with this plan that there was a flaw. The endpoint that receives the markup via Ajax is accepting data from the client. That data could be faked by a malicious actor.

Sure, I’m doing a whole bunch of checks and sanitisation on the server, but there’s always going to be a way of working around that. You can never trust data sent from the client. I was kind of relying on security through obscurity …except it wasn’t even that obscure because I blogged about it.

So I’m switching over to using a headless browser to extract the sheetmusic. You may recall that I wrote:

I could spin up a headless browser, run the JavaScript and take a snapshot. But that’s a bit beyond my backend programming skills.

That’s still true. So I’m outsourcing the work to Browserless.

There’s a reason I didn’t go with that solution to begin with. Like I said, over 40,000 tune settings have already been cached. If I had used the Browserless API to do that work, it would’ve been quite pricey. But now that the flood is over and there’s a just a trickle of caching happening, Browserless is a reasonable option.

Anyway, that security hole has now been closed. Thank you to everyone who wrote in to let me know about it. Like I said, I was aware of it, but it was good to have it confirmed.

Funnily enough, the security lesson here is the same as my conclusion when talking about performance:

If that means shifting the work from the browser to the server, do it!

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.

Here’s the code I wrote.

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.

Every week of June sees me at a web event, but in a different capacity each time.

At the end of the first full week in June, I went to CSS Day in Amsterdam as an attendee. It was thought-provoking, as always. And it was great to catch up with my front-of-the-front-end friends.

Last week I went to Pixel Pioneers in Bristol as a speaker. Fortunately I was on first so I was able to get the speaking done with and enjoy the rest of the talks. It was a lovely little event and there was yet more catching up with old friends and making new ones.

This week is the big one. UX London is happening this week. This time I’m not there as an attendee or a speaker. I’m there as the curator and host.

On the one hand, I’m a bag of nerves. I’ve been preparing for this all year and now it’s finally happening. I keep thinking of all the things that could possibly go wrong.

On the other hand, I’m ridiculously excited. I know I should probably express some modesty, but looking at the line-up I’ve assembled, I feel an enormous sense of pride. I’m genuinely thrilled at the prospect of all those great talks and workshops.

Nervous and excited. Those are the two wolves inside me right now.

If you’re going to be at UX London, I hope that you’re equally excited (and not nervous). There are actually still some last-minute tickets available if you haven’t managed to get one yet.

See you there!

I’ve been banging the drum for a button type="share" for a while now.

I’ve also written about other potential button types. The pattern I noticed was that, if a JavaScript API first requires a user interaction—like the Web Share API—then that’s a good hint that a declarative option would be useful:

The Fullscreen API has the same restriction. You can’t make the browser go fullscreen unless you’re responding to user gesture, like a click. So why not have button type=”fullscreen” in HTML to encapsulate that? And again, the fallback in non-supporting browsers is predictable—it behaves like a regular button—so this is trivial to polyfill.

There’s another “smell” that points to some potential button types: what functionality do browsers provide in their interfaces?

Some browsers provide a print button. So how about button type="print"? The functionality is currently doable with button onclick="window.print()" so this would be a nicer, more declarative way of doing something that’s already possible.

It’s the same with back buttons, forward buttons, and refresh buttons. The functionality is available through a browser interface, and it’s also scriptable, so why not have a declarative equivalent?

How about bookmarking?

And remember, the browser interface isn’t always visible: progressive web apps that launch with minimal browser UI need to provide this functionality.

Šime Vidas was wondering about button type="copy” for copying to clipboard. Again, it’s something that’s currently scriptable and requires a user gesture. It’s a little more complex than the other actions because there needs to be some way of providing the text to be copied, but it’s definitely a valid use case.

• button type="share"
• button type="fullscreen"
• button type="print"
• button type="bookmark"
• button type="back"
• button type="forward"
• button type="refresh"
• button type="copy"

Any more?

It all started with a trip into the countryside one Sunday a few weeks back.

The weather has been getting better and better. The countryside was calling. Meanwhile, Jessica was getting worried about her newly-acquired driving skills getting rusty. She has her license, but doesn’t get the chance to drive very often. She signed up to a car club that lets her book a hybrid car for a few hours at a time—just enough to keep in practice, and also just enough for a little jaunt into the countryside.

We went for Sunday lunch at the Shepherd and Dog in Fulking, near to Devil’s Dyke (I swear that sentence makes sense if you live ’round these parts). It was a lovely day. The Sunday roast was good. But it was on the way back that things started to go wrong.

We had noticed that one of the front tyres was looking a little flat so we planned to stop into a garage to get that seen to. We never made it that far. The tell-tale rhythmic sounds of rubber flapping around told us that we now had a completely flat tyre. Cue panic.

Fortunately we weren’t too far from a layby. We pulled in on the side of the busy road that runs by Saddlescombe Farm.

This is when the Kafkaesque portion of the day began. Jessica had to call the car club, but reception was spotty to put it mildly. There was much frustration, repitition, and hold music.

Eventually it was sorted out enough that we were told to wait for someone from the AA who’d come by and change the tyre in a few hours. To be fair, there are worse places to be stuck on a sunny Summer’s day. We locked the car and walked off across the rolling hills to pass the time.

The guy from the AA actually showed up earlier than expected. We hurried back and then sat and watched as he did his mechanical mending. We got the all-clear to drive the car back to Brighton, as long we didn’t exceed 50 miles per hour.

By the time we got home, we were beat. What a day! I could feel the beginnings of a headache so I popped some ibuprofin to stave it off. Neither of us could be bothered cooking, so we opted for a lazy evening in front of the telly eating takeaway.

I went onto Deliveroo and realised I couldn’t even manage the cognitive overhead of deciding what to eat. So I just went to my last order—a nice mix of Chinese food—and clicked on the option to place exactly the same order again.

And so we spent our Sunday evening munching on Singapore fried noodles and catching up on the most excellent Aussie comedy series, Colin From Accounts. It was just what I needed after an eventful day.

I had just finished my last bite when I felt I needed to cough. That kicked off some wheezing. That was a bit weird. So was the itchy sensation in my ears. Like, the insides of my ears were itchy. Come to think of it, my back was feeling really itchy too.

The wheeziness was getting worse. I had been trying to pass it off, responding to Jessica’s increasingly worried questions with “I’m grand, I’ll be f…” Sorry, had to cough. Trying to clear my throat. It feels a bit constricted.

When Jessica asked if she should call 111, I nodded. Talking took a bit of effort.

Jessica described my symptoms over the phone. Then the operator asked to speak to me. I answered the same questions, but in a much wheezier way.

An ambulance was on its way. But if the symptoms got worse, we should call 999.

The symptoms got worse. Jessica called 999. The ambulance arrived within minues.

The two paramedics, Alastair and Lucy, set to work diagnosing the problem. Let’s go into the ambulance, they said. They strapped a nebuliser onto my face which made breathing easier. It also made everything I said sound like a pronouncement from Bane.

They were pretty sure it was anaphylaxis. I’ve never been allergic to anything in my life, but clearly I was reacting to something. Was it something in the Chinese food? Something in the countryside?

In any case, they gave me a jab of antihistamine into my arm and took us to the emergency room.

By the time we got there, I was feeling much better. But they still needed to keep me under observation. So Jessica and I spent a few hours sitting in the hallway. Someone came by every now and then to check on me and offer us some very welcome cups of tea.

Once it was clear that I was fully recovered, I was discharged with a prescription for an EpiPen.

I picked up the prescription the next day. Having an EpiPen filled with adrenaline was reassuring but it was disconcerting not knowing what caused my anaphylactic reaction in the first place.

After that stressful weekend, life went back to normal, but with this cloud of uncertainty hovering above. Was that it? Would it happen again? Why did it happen?

The weather stayed nice all week. By the time the next weekend rolled around, I planned to spend it doing absolutely nothing. That was just as well, because when I woke up on Saturday morning, I had somehow managed to twist something in my shoulder. I guess I’m at that age now where I can injure myself in my sleep.

I took some neproxin, which helped. After a while, the pain was gone completely.

Jessica and I strolled to the park and had brunch in a nice local café. Then we strolled home and sat out in the garden, enjoying the sunshine.

I was sitting there reading my book when I noticed it. The insides of my ears. They were getting itchy. I swallowed nervously. Was it my imagination or did that swallowing sensation feel slightly constricted. And is that a wheeze I hear?

It was happening again.

The symptoms continued to get worse. Alright, it was time to use that EpiPen. I had read the instructions carefully so I knew just what to do. I did the EpiPen mambo: hold, jab, press.

It worked. We called 999 (as instructed) and were told to go the emergency room. This time we went by taxi.

I checked in, and then sat in the waiting room. I noticed that everyone else had white wristbands, but mine was red. I guess my place in the triage was high priority.

As I sat there, I could feel some of those symptoms returning, but very slowly. By the time we saw someone, there was no mistaking it. The symptoms were coming back.

I was hooked up to the usual instruments—blood pressure, heart rate, blood oxygen—while the hospital staff conferred about what to do. I was getting a bit clammy. I started to feel a bit out of it.

Beep, beep! One of those numbers—blood oxygen?—had gone below a safe threshold. I saw the staff go into action mode. Someone hit a button—the red light in the ceiling started flashing. Staff who had been dealing with other patients came to me.

Instructions were spoken clearly and efficiently, then repeated back with equal clarity and efficiency. “Adrenaline. One in ten thousand.” “Adrenaline. One in ten thousand.” They reclined my chair, elevated my legs, pulled down my trousers, and gave me my second shot in one day.

It worked. I started to feel much better straight away. But once again, I needed to be kept under observation. I was moved to the “recus” ward, passing through the corridor that was so familiar from the previous weekend.

This time we’d spend a grand total of twelve hours in the hospital. Once again, it was mercifully uneventful. But it gave us the opportunity to put two and two together. What was the common thread between both episodes?

Ibuprofin. Neproxin. They’re both non-steroidal anti-inflammatory drugs (NSAIDS). That fits

Foods are the most common trigger in children and young adults, while medications and insect bites and stings are more common in older adults. … Any medication may potentially trigger anaphylaxis. The most common are β-lactam antibiotics (such as penicillin) followed by aspirin and NSAIDs.

The doctors agreed—the connection looked pretty clear. I saw my GP a few days later and she’s reffered me to an allergy-testing clinic to confirm it. That might take a while though. In the meantime, I also got another prescription for more EpiPens.

Hopefully I won’t need them. I’m very, very glad that I don’t appear to be allergic to a foodstuff. I’d rather do without ibuprofin and aspirin than have to vigilantly monitor my diet.

But I do need to get into the habit of making sure I’ve got at least one EpiPen with me wherever I go. I’ll probably never need to use it. I feel like I’ve had enough anaphylaxis in the past couple of weeks to last me a lifetime.

Oh, and one more thing. I know everyone says this after dealing with some kind of health emergency in this country, but I’m going to say it anyway:

The NHS is easily the best thing ever invented in the UK. Everyone I dealt with was fantastic. It was all in a day’s work for them, but I am forever in their debt (whereas had this happened in, say, the USA, I would forever be in a much more literal debt).

Thank you, NHS!

In just a couple of weeks, I’ll be heading to Bristol for Pixel Pioneers. The line-up looks really, really good …with the glaring exception of the opening talk, which I’ll be delivering. But once that’s done, I’m very much looking forward to enjoying the rest of the day’s talks.

There are still tickets available if you fancy joining me.

This will be my second time speaking at this conference. I spoke at the inaugural conference back in 2017 when I gave a talk called Evaluating Technology. This time my talk is called Declarative Design.

A few weeks back, Oliver asked me some questions about my upcoming talk. I figured I’d post my answers here…

Welcome back to Pixel Pioneers! You return with another keynote - how do you manage to stay so ever-enthusiastic about designing for the web?

Well, I’d say my enthusiasm is mixed with frustration. And that’s always been the case. Just as I’ve always found new things that excite me about the World Wide Web, there are just as many things that upset me.

But that’s okay. Both forces can be motivating. When I find myself writing a blog post or preparing a talk, the impetus might be “This is so cool! Check this out!” or it might be “This is so maddening! What’s happening!?” …or perhaps a mix of both.

But to answer your question, the World Wide Web never stays still so there’s always something to get excited about. Equally, the longer the web exists, the more sense it makes to examine the fundamental bedrock—HTML, accessibility,progressive enhancement—and see how they’re just as important as ever. And that’s also something to get excited about!

Without too many spoilers, what can we expect to take away from your talk?

I’m hoping to provide people with a lens that they can use to examine their tools, processes, and approaches to designing for the web. It’s a fairly crude lens—it divides the world into a binary split that I’ve borrowed from the world of programming; imperative and declarative languages. But it’s a surprisingly thought-provoking angle.

Along the way I’ll also be pointing out some of the incredible things that we can do with CSS now. In the past few years there’s been an explosion in capabilities.

But this won’t be a code-heavy presentation. It’s mostly about the ideas. I’ll be referencing some projects by other people that I’m very excited by.

What other web design and development tools, techniques and technologies are you currently most excited about?

Outside of the world of CSS—which is definitely where a lot of the most exciting developments are happening—I’m really interested in the View Transitions API. If it delivers on its promise, it could be a very useful nail in the coffin of uneccessary single page apps. But I’m a little nervous. Right now the implementation only works for single page apps, which makes it an incentive to use that model. I really, really hope that the multipage version ships soon.

But honestly, I probably get most excited about discovering some aspect of HTML that I wasn’t aware of. Even after all these years the language can still surprise me.

And on the flipside, what bugs you most about the web at the moment?

How much time have you got?

Seriously though, the thing that’s really bugged me for the past decade is the increasing complexity of “modern” frontend development when it isn’t driven by user needs. Yes, I’m talking about JavaScript frameworks like React and the assumption that everything should be a single page app.

Honestly, the mindset became so ubiquitous that I felt like I must be missing something. But no, the situation really has spiralled out of control, much to the detriment of end users.

Luckily we’re starting to see the pendulum swing back. The proponents of trickle-down developer convenience are having to finally admit that it’s bollocks.

I don’t care if the move back to making websites is re-labelled as “isomorphic server-rendered multi-page apps.” As long as we make sensible architectural decisions, that’s all that matters.

What’s next, Jeremy?

Right now I’m curating the line-up for this year’s UX London conference which is the week after Pixel Pioneers. As you know, conference curation is a lot of work, but it’s also very rewarding. I’m really proud of the line-up.

It’s been a while since the last season of the Clearleft podcast. I hope to remedy that soon. It takes a lot of effort to make even one episode, but again, it’s very rewarding.

I must admit, when Jake told me he was leaving Google, I got very worried about the future of the View Transitions API.

To recap: Chrome shipped support for the API, but only for single page apps. That had me worried:

If the View Transitions API works across page navigations, it could be the single best thing to happen to the web in years.

If the View Transitions API only works for single page apps, it could be the single worst thing to happen to the web in years.

Well, the multi-page version still hasn’t yet shipped in Chrome stable, but it is available in Chrome Canary behind a flag, so it looks like it’s almost here!

Robin took the words out of my mouth:

Anyway, even this cynical jerk is excited about this thing.

Are you the kind of person who flips feature flags on in nightly builds to test new APIs?

Me neither.

But I made an exception for the View Transitions API. So did Dave:

I think the most telling predictor for the success of the multi-page View Transitions API – compared to all other proposals and solutions that have come before it – is that I actually implemented this one. Despite animations being my bread and butter for many years, I couldn’t be arsed to even try any of the previous generation of tools.

Dave’s post is an excellent step-by-step introduction to using view transitions on your website. To recap:

Enable these two flags in Chrome Canary:

chrome://flags#view-transition
chrome://flags#view-transition-on-navigation

Then add this meta element to the head of your website:

<meta name="view-transition" content="same-origin">

You could stop there. If you navigate around your site, you’ll see that the navigations now fade in and out nicely from one page to another.

But the real power comes with transitioning page elements. Basically, you want to say “this element on this page should morph into that element on that page.” And when I say morph, I mean morph. As Dave puts it:

Behind the scenes the browser is rasterizing (read: making an image of) the before and after states of the DOM elements you’re transitioning. The browser figures out the differences between those two snapshots and tweens between them similar to Apple Keynote’s “Magic Morph” feature, the liquid metal T-1000 from Terminator 2: Judgement Day, or the 1980s cartoon series Turbo Teen.

If those references are lost on you, how about the popular kids book series Animorphs?

Some classic examples would be:

• A thumbnail of a video on one page morphs into the full-size video on the next page.
• A headline and snippet of an article on one page morphs into the full article on the next page.

I’ve added view transitions to The Session. Where I’ve got index pages with lists of titles, each title morphs into the heading on the next page.

Again, Dave’s post was really useful here. Each transition needs a unique name, so I used Dave’s trick of naming each transition with the ID of the individual item being linked to.

In the recordings section, for example, there might be a link like this on the index page:

<a href="/recordings/7812" style="view-transition-name: recording-7812">The Banks Of The Moy</a>

Which, if you click on it, takes you to the page with this heading:

<h1><span style="view-transition-name: recording-7812">The Banks Of The Moy</span></h1>

Why the span? Well, like Dave, I noticed some weird tweening happening between block and inline elements. Dave solved the problem with width: fit-content on the block-level element. I just stuck in an extra inline element.

Anyway, the important thing is that the name of the view transition matches: recording-7812.

I also added a view transition to pages that have maps. The position of the map might change from page to page. Now there’s a nice little animation as you move from one page with a map to another page with a map.

That’s all good, but I found myself wishing that I could just have those enhancements. Every single navigation on the site was triggering a fade in and out—the default animation. I wondered if there was a way to switch off the default fading.

There is! That default animation is happening on a view transition named root. You can get rid of it with this snippet of CSS:

::view-transition-image-pair(root) {
  isolation: auto;
}
::view-transition-old(root),
::view-transition-new(root) {
  animation: none;
  mix-blend-mode: normal;
  display: block;
}

Voila! Now only the view transitions that you name yourself will get applied.

You can adjust the timing, the easing, and the animation properites of your view transitions. Personally, I was happy with the default morph.

In fact, that’s one of the things I like about this API. It’s another good example of declarative design. I say what I want to happen, but I don’t need to specify the details. I’ll let the browser figure all that out.

That’s what’s got me so excited about this API. Yes, it’s powerful. But just as important, it’s got a very low barrier to entry.

Chris has gathered a bunch of examples together in his post Early Days Examples of View Transitions. Have a look around to get some ideas.

If you like what you see, I highly encourage you to add view transitions to your website now.

“But wait,” I hear you cry, “this isn’t supported in any public-facing browser yet!”

To which, I respond “So what?” It’s a perfect example of progressive enhancement. Adding one meta element and a smidgen of CSS will do absolutely no harm to your website. And while no-one will see your lovely view transitions yet, once browsers do start shipping with support for the API, your site will automatically get better.

Your website will be enhanced. Progressively.

Update: Simon Pieters quite rightly warns against adding view transitions to live sites before the API is done:

in general, using features before they ship in a browser isn’t a great idea since it can poison the feature with legacy content that might break when the feature is enabled. This has happened several times and renames or so were needed.

Good point. I must temper my excitement with pragmatism. Let me amend my advice:

I highly encourage you to experiment with view transitions on your website now.