Jen pointed me to this proposal, which should help smooth over some of the inconsistencies I documented in iOS when it comes to the Web Audio API.
I’ve preemptively add this bit of feature detection to The Session:
if ('audioSession' in navigator) {
navigator.audioSession.type = "playback";
}
I documented a weird bug with web audio on iOS a while back:
On some pages of The Session, as well as the audio player for tunes (using the Web Audio API) there are also embedded YouTube videos (using the
videoelement). Press play on the audio player; no sound. Press play on the YouTube video; you get sound. Now go back to the audio player and suddenly you do get sound!It’s almost like playing a
videooraudioelement “kicks” the browser into realising it should be playing the sound from the Web Audio API too.This was happening on iOS devices set to mute, but I was also getting reports of it happening on devices with the sound on. But it’s that annoyingly intermittent kind of bug that’s really hard to reproduce consistently. Sometimes the sound doesn’t play. Sometimes it does.
I found a workaround but it was really hacky. By playing a one-second long silent mp3 file using audio, you could “kick” the sound into behaving. Then you can use the Web Audio API and it would play consistently.
Well, that’s all changed with the latest release of Mobile Safari. Now what happens is that the Web Audio stuff plays …for one second. And then stops.
I removed the hacky workaround and the Web Audio API started behaving itself again …but your device can’t be set to silent.
The good news is that the Web Audio behaviour seems to be consistent now. It only plays if the device isn’t muted. This restriction doesn’t apply to video and audio elements; they will still play even if your device is set to silent.
This descrepancy between the two different ways of playing audio is kind of odd, but at least now the Web Audio behaviour is predictable.
You can hear the Web Audio API in action by going to any tune on The Session and pressing the “play audio” button.
Usually an end-of-year music round-up is a list of favourite recordings released in the year. But in 2022 I wasn’t paying very much attention to new releases. I bought a few albums on Bandcamp. They were mostly of—surprise, surprise—traditional Irish music.
Still, I had a very music-filled 2022. Mostly I was playing mandolin in sessions, both here in Brighton and wherever else my travels took me.
These moments were undoubtedly highlights of the year for me.
I’ve always liked the idea that your website can be your API. Like, you’ve already got URLs to identify resources, so why not make that URL structure predictable and those resources parsable?
That’s why the (read-only) API for The Session doesn’t live at a separate subdomain. It uses the same URL structure as the regular site, but you can request the resources in an alternative format: JSON, XML, RSS.
This works out pretty well, mostly because I put a lot of thought into the URL structure of the site. I’m something of a URL fetishist, but I think that taking a URL-first approach to information architecture can be a good exercise.
Most of the resources on The Session involve nouns like tunes, events, discussions, and so on. There’s a consistent and predictable structure to the URLs for those sections:
/things/things/new/things/searchAnd then an idividual item can be found at:
things/IDThat’s all nice and predictable and the naming of the URLs matches what you’d expect to find:
Tunes, events, discussions, sessions. Those are all fine. But there’s one section of the site that has this root URL:
When I was coming up with the URL structure twenty years ago, it was clear what you’d find there: track listings for albums of music. No one would’ve expected to find actual recordings of music available to listen to on-demand. The bandwidth constraints and technical limitations of the time made that clear.
Two decades on, the situation has changed. Now someone new to the site might well expect to hit a link called “recordings” and expect to hear actual recordings of music.
So I should probably change the label on the link. I don’t think “albums” is quite right—what even is an album any more? The word “discography” is probably the most appropriate label.
Here’s my dilemma: if I update the label, should I also update the URL structure?
Right now, the section of the site with /tunes URLs is labelled “tunes”. The section of the site with /events URLs is labelled “events”. Currently the section of the site with /recordings URLs is labelled “recordings”, but may soon be labelled “discography”.
If you click on “tunes”, you end up at /tunes. But if you click on “discography”, you end up at /recordings.
Is that okay? Am I the only one that would be bothered by that?
I could update the URLs to match the labelling (with redirects for the old URLs, of course), but I’m not so keen on this URL structure:
/discography/discography/new/discography/search/discography/IDIt doesn’t seem as tidy as:
/recordings/recordings/new/recordings/search/recordings/IDBut if I don’t update the URLs to match the label, then I’m just going to have to live with the mismatch.
I’m just thinking out loud here. I think I should definitely update the label. I just won’t make any decision on changing URLs for a while yet.
Gerry talks about “top tasks” a lot. He literally wrote the book on it:
Top tasks are what matter most to your customers.
Seems pretty obvious, right? But it’s actually pretty rare to see top tasks presented any differently than other options.
Look at the global navigation on most websites. Typically all the options are given equal prominence. Even the semantics under the hood often reflect this egalitarian ideal, with each list in an unordered list. All the navigation options are equal, but I bet that the reality for most websites is that some navigation options are more equal than others.
I’ve been guilty of this on The Session. The site-wide navigation shows a number of options: tunes, events, discussions, etc. Each one is given equal prominence, but I can tell you without even looking at my server logs that 90% of the traffic goes to the tunes section—that’s the beating heart of The Session. That’s why the home page has a search form that defaults to searching for tunes.
I wanted the navigation to reflect the reality of what people are coming to the site for. I decided to make the link to the tunes section more prominent by bumping up the font size a bit.
I was worried about how weird this might look; we’re so used to seeing all navigation items presented equally. But I think it worked out okay (though it might take a bit of getting used to if you’re accustomed to the previous styling). It helps that “tunes” is a nice short word, so bumping up the font size on that word doesn’t jostle everything else around.
I think this adjustment is working well for this situation where there’s one very clear tippy-top task. I wouldn’t want to apply it across the board, making every item in the navigation proportionally bigger or smaller depending on how often it’s used. That would end up looking like a ransom note.
But giving one single item prominence like this tweaks the visual hierarchy just enough to favour the option that’s most likely to be what a visitor wants.
That last bit is crucial. The visual adjustment reflects what visitors want, not what I want. You could adjust the size of a navigation option that you want to drive traffic to, but in the long run, all you’re going to do is train people to trust your design less.
You don’t get to decide what your top task is. The visitors to your website do. Trying to foist an arbitrary option on them would be the tail wagging the dog.
Anway, I’m feeling a lot better about the site-wide navigation on The Session now that it reflects reality a little bit more. Heck, I may even bump that font size up a little more.
It’s been almost two years since I added audio playback on The Session. The interface is quite straightforward. For any tune setting, there’s a button that says “play audio”. When you press that button, audio plays and the button’s text changes to “pause audio.”
By updating the button’s text like this, I’m updating the button’s accessible name. In other situations, where the button text doesn’t change, you can indicate whether a button is active or not by toggling the aria-pressed attribute. I’ve been doing that on the “share” buttons that act as the interface for a progressive disclosure. The label on the button—“share”—doesn’t change when the button is pressed. For that kind of progressive disclosure pattern, the button also has an aria-controls and aria-expanded attribute.
From all the advice I’ve read about button states, you should either update the accessible name or change the aria-pressed attribute, but not both. That would lead to the confusing situation of having a button labelled “pause audio” as having a state of “pressed” when in fact the audio is playing.
That was all fine until I recently added some more functionality to The Session. As well as being able to play back audio, you can now adjust the tempo of the playback speed. The interface element for this is a slider, input type="range".
But this means that the “play audio” button now does two things. It plays the audio, but it also acts as a progressive disclosure control, revealing the tempo slider. The button is simultaneously a push button for playing and pausing music, and a toggle button for showing and hiding another interface element.
So should I be toggling the aria-pressed attribute now, even though the accessible name is changing? Or is it enough to have the relationship defined by aria-controls and the state defined by aria-expanded?
Based on past experience, my gut feeling is that I’m probably using too much ARIA. Maybe it’s an anti-pattern to use both aria-expanded and aria-pressed on a progressive disclosure control.
I’m kind of rubber-ducking here, and now that I’ve written down what I’m thinking, I’m pretty sure I’m going to remove the toggling of aria-pressed in any situation where I’m already toggling aria-expanded.
What I really need to do is enlist the help of actual screen reader users. There are a number of members of The Session who use screen readers. I should get in touch and see if the new functionality makes sense to them.
I wrote recently about making the switch to logical properties over on The Session.
Initially I tried ripping the band-aid off and swapping out all the directional properties for logical properties. After all, support for logical properties is green across the board.
But then I got some reports of people seeing formating issues. These people were using Safari on devices that could no longer update their operating system. Because versions of Safari are tied to versions of the operating system, there was nothing they could do other than switch to using a different browser.
I’ve said it before and I’ll say it again, but as long as this situation continues, Safari is not an evergreen browser. (I also understand that problem lies with the OS architecture—it must be incredibly frustrating for the folks working on WebKit and/or Safari.)
So I needed to add fallbacks for older browsers that don’t support logical properties. Or, to put it another way, I needed to add logical properties as a progressive enhancement.
“No problem!” I thought. “The way that CSS works, I can just put the logical version right after the directional version.”
element {
margin-left: 1em;
margin-inline-start: 1em;
}
But that’s not true in this case. I’m not over-riding a value, I’m setting two different properties.
In a left-to-right language like English it’s true that margin-inline-start will over-ride margin-left. But in a right-to-left language, I’ve just set margin-left and margin-inline-start (which happens to be on the right).
This is a job for @supports!
element {
margin-left: 1em;
}
@supports (margin-inline-start: 1em) {
element {
margin-left: unset;
margin-inline-start: 1em;
}
}
I’m doing two things inside the @supports block. I’m applying the logical property I’ve just tested for. I’m also undoing the previously declared directional property.
A value of unset is perfect for this:
The
unsetCSS keyword resets a property to its inherited value if the property naturally inherits from its parent, and to its initial value if not. In other words, it behaves like theinheritkeyword in the first case, when the property is an inherited property, and like theinitialkeyword in the second case, when the property is a non-inherited property.
Now I’ve got three CSS features working very nicely together:
@supports (also known as feature queries),unset keyword.For anyone using an up-to-date browser, none of this will make any difference. But for anyone who can’t update their Safari browser because they can’t update their operating system, because they don’t want to throw out their perfectly functional Apple device, they’ll continue to get the older directional properties:
I discovered that my Mom’s iPad was a 1st generation iPad Air. Apple stopped supporting that device in iOS 12, which means it was stuck with whatever version of Safari last shipped with iOS 12.
I was refactoring some CSS on The Session over the weekend. I thought it would be good to switch over to using logical properties exclusively. I did this partly to make the site more easily translatable into languages with different writing modes, but mostly as an exercise to help train me in thinking with logical properties by default.
All in all, it went pretty smoothly. You can kick the tyres by opening up dev tools on The Session and adding a writing-mode declaration to the body or html element.
For the most part, the switchover was smooth. It mostly involved swapping out property names with left, right, top, and bottom for inline-start, inline-end, block-start, and block-end.
The border-radius properties tripped me up a little. You have to use shorthand like border-start-end-radius, not border-block-start-inline-end-radius (that doesn’t exist). So you have to keep the order of the properties in mind:
border-{{block direction}}-{{inline-direction}}-radius
Speaking of shorthand, I also had to kiss some shorthand declarations goodbye. Let’s say I use this shorthand for something like margin or padding:
margin: 1em 1.5em 2em 0.5em;
Those values get applied to margin-top, margin-right, margin-bottom, and margin-left, not the logical equivalents (block-start, inline-end, block-end, and inline-start). So separate declarations are needed instead:
margin-block-start: 1em;
margin-inline-end: 1.5em;
margin-block-end: 2em;
margin-inline-start: 0.5em;
Same goes for shorthand like this:
margin: 1em 2em;
That needs to be written as two declarations:
margin-block: 1em;
margin-inline: 2em;
Now I’ve said it before and I’ll say it again: it feels really weird that you can’t use logical properties in media queries. Although as I said:
Now you could rightly argue that in this instance we’re talking about the physical dimensions of the viewport. So maybe width and height make more sense than inline and block.
But along comes the new kid on the block (or inline), container queries, ready to roll with container-type values like inline-size. I hope it’s just a matter of time until we can use logical properties in all our conditional queries.
The other place where there’s still a cognitive mismatch is in transforms and animations. We’ve got a translateX() function but no translate-inline(). We’ve got translateY() but no translate-block().
On The Session I’m using some JavaScript to figure out the details of some animation effects. I’m using methods like getBoundingClientRect(). It doesn’t return logical properties. So if I ever want to adjust my animations based on writing direction, I’ll need to fork my JavaScript code.
Oh, and one other thing: the aspect-ratio property takes values in the form of width/height, not inline/block. That makes sense if you’re dealing with images, videos, or other embedded content but it makes it really tricky to use aspect-ratio on elements that contain text. I mean, it works fine as long as the text is in a language using a top-to-bottom writing mode, but not for any other languages.
I’m taking a nice long weekend break after dConstruct on Friday (I will of course have more to say on that—I’m collecting my thoughts still—but it was a wonderful day).
On Saturday I did absolutely nothing. It was just as well really, considering that I may have over-indulged in the pub on Friday evening after dConstruct was done. So a day of lounging around idly playing mandolin was just the ticket.
Yesterday, Sunday, I had one of those perfect leisurely days.
It began with a good bout of lazing about in the morning. Then, as lunchtime approached, Jessica and I went to a nearby pub for a Sunday Roast. In this case it was the Dover Castle. It turned out to be an excellent choice—top notch roasts!
While we were enjoying our lunch, Jessica spotted a poster on the wall for Bark In The Park, a local fun day of dog-centred activities. We were sure it had already happened earlier in Summer, but the poster said it was rescheduled to …yesterday!
So after lunch we went to the park and spent the next few hours in the sunshine, petting very good dogs and enjoying the spectacle of such catgories as “fancy dress”, “best rescue”, and “sausage catching.” We left shortly before the announcement of “best in show”—my money was on Mayhem—so I could nip home, grab my mandolin, and head to The Bugle pub for the weekly 4pm Irish music session.
After two hours of jigs’n’reels, I headed home. The weather was still lovely. The forecast was for cloudy weather, but it was unexpectedly sunny. So I fired up the outdoor grill.
We grilled: one aubergine, halved and scored; one yellow courgette, halved; one green courgette, halved; half a hispe cabbage, quartered. Once they were nicely charred outside and soft within, we ate them with a drizzle of tahini sauce, accompanied by a green salad.
By that time the sun had gone down and it was time for a nice evening spent watching the latest episode of The Rings Of Power and drinking a nice cup of tea.
Like I said, a perfect leisurely day.
Dave recently wrote some good advice about what to do—and what not to do—when it comes to complaining about web browsers. I wrote something on this topic a little while back:
If there’s something about a web browser that you’re not happy with (or, indeed, if there’s something you’re really happy with), take the time to write it down and publish it
To summarise Dave’s advice, avoid conspiracy theories and snark; stick to specifics instead.
It’s very good advice that I should heed (especially the bit about avoiding snark). In that spirit, I’d like to document what I think is a bug on iOS.
I don’t need to name the specific browser, because there is basically only one browser allowed on iOS. That’s not snark; that’s a statement of fact.
This bug involves navigating from a progressive web app that has been installed on your home screen to an external web view.
To illustrate the bug, I’ll use the example of The Session. If you want to recreate the bug, you’ll need to have an account on The Session. Let me know if you want to set up a temporary account—I can take care of deleting it afterwards.
Here are the steps:
Expected behaviour: you are returned to the page you were on with no change of state.
Actual behaviour: you are returned to the page you were on but you are logged out.
So the act of visiting an external link in a web view while in a progressive web app in standalone mode seems to cause a loss of cookie-based authentication.
This isn’t permanent. Clicking on any internal link restores the logged-in state.
It is surprising though. My mental model for opening an external link in a web view is that it sits “above” the progressive web app, which remains in stasis “behind” it. But the page must actually be reloading, either when the web view is opened or when the web view is closed. And that reload is behaving like a fetch event without credentials.
Anyway, that’s my bug report. It may already be listed somewhere on the WebKit Bugzilla but I lack the deductive skills to find it. I’m not even sure if that’s the right place for this kind of bug. It might be specific to the operating system rather than the rendering engine.
This isn’t a high priority bug, but it is one of those cumulatively annoying software paper cuts.
Hope this helps!
I don’t know about you, but it seems like everyone I follow on Twitter is playing Wordle. Although I don’t play the game myself, I think it’s pretty great.
Not only does Wordle have a very sweet backstory, but it’s also unashamedly on the web. If you want to play, you go to the URL powerlanguage.co.uk/wordle. That’s it. No need to download an app.
That hasn’t stopped some nefarious developers trying to trick people into downloading their clones of Wordle from app stores. App stores, which are meant to be curated and safe, are in fact filled with dodgy knock-offs and scams. Contrary to popular belief, the web is quite literally a safer bet.
Wordle has a web app manifest, which means you can add it to your home screen and it will behave just like a native app (although I don’t believe it has offline support). That’s great, but the process of adding a web app to your home screen on iOS is ludicrously long-winded.
Macworld published an article detailing how to get the real Wordle app on your iPhone or iPad. On the one hand it’s great to see this knowledge being spread. On the other hand it’s dispiriting that it’s even necessary to tell people that they can do this, like it’s a hidden nerdy secret just for power users.
At this point I’ve pretty much given up on Apple ever doing anything about this pathetic situation. So what can I do instead?
Well, taking my cue from that Macworld article, the least I can do is inform people how they can add a progressive web app to their home screen.
That’s what I’ve done on thesession.org. I’ve published a page on how to install The Session to your home screen.
On both Android and iPhone the journey to installing a progressive web app begins with incomprehensible iconography. On Android you must first tap on the unlabeled kebab icon—three vertical dots. On iOS you must first tap on the unlabeled share icon—a square with an arrow coming out of it.
When it comes to mobile operating systems, consumer choice means you choose which kind of mystery meat to eat.
I’ve included screenshots to help people identify these mysterious portals. For iOS I’ve also included a video to illustrate the quest to find the secret menu item buried beneath the share icon.
I’ve linked to the page with the installation instructions from the site’s “help” page and the home page.
Handy tip: when you’re adding a start_url value to your web app manifest, it’s common to include a query string like this:
start_url: "/?homescreen"
I’m guessing most people to that so they can get analytics on how many people are starting from an icon tap. I don’t do analytics on The Session but I’m still using that query string in my start_url. On the home page of the site, I check for the existence of the query string. If it exists, I don’t show the link to the installation page. So once someone has installed the site to their home screen, they shouldn’t see that message when they launch The Session.
If you’ve got a progressive web app, it might be worth making a page with installation instructions rather than relying on browsers to proactively inform your site’s visitors. You’d still need to figure out the right time and place to point people to that page, but at least the design challenge would be in your hands.
Should you decide to take a leaf out of the Android and iOS playbooks and use mystery meat navigation to link to such a page, there’s an emoji you could potentially use: 📲
It’s still worse than using actual words, but it might be better than some random combination of dots, squares and arrows.
(I’m not really serious about using that emoji, but if you do, be sure to use a sensible aria-label value on the enclosing a element.)
It’s said that the best way to learn about something is to teach it. I certainly found that to be true when I was writing the web.dev course on responsive design.
I felt fairly confident about some of the topics, but I felt somewhat out of my depth when it came to some of the newer modern additions to browsers. The last few modules in particular were unexplored areas for me, with topics like screen configurations and media features. I learned a lot about those topics by writing about them.
Best of all, I got to put my new-found knowledge to use! Here’s how…
The Session is a progressive web app. If you add it to the home screen of your mobile device, then when you launch the site by tapping on its icon, it behaves just like a native app.
In the web app manifest file for The Session, the display-mode property is set to “standalone.” That means it will launch without any browser chrome: no address bar and no back button. It’s up to me to provide the functionality that the browser usually takes care of.
So I added a back button in the navigation interface. It only appears on small screens.
Do you see the assumption I made?
I figured that the back button was most necessary in the situation where the site had been added to the home screen. That only happens on mobile devices, right?
Nope. If you’re using Chrome or Edge on a desktop device, you will be actively encourged to “install” The Session. If you do that, then just as on mobile, the site will behave like a standalone native app and launch without any browser chrome.
So desktop users who install the progressive web app don’t get any back button (because in my CSS I declare that the back button in the interface should only appear on small screens).
I was alerted to this issue on The Session:
It downloaded for me but there’s a bug, Jeremy - there doesn’t seem to be a way to go back.
Luckily, this happened as I was writing the module on media features. I knew exactly how to solve this problem because now I knew about the existence of the display-mode media feature. It allows you to write media queries that match the possible values of display-mode in a web app manifest:
.goback {
display: none;
}
@media (display-mode: standalone) {
.goback {
display: inline;
}
}
Now the back button shows up if you “install” The Session, regardless of whether that’s on mobile or desktop.
Previously I made the mistake of inferring whether or not to show the back button based on screen size. But the display-mode media feature allowed me to test the actual condition I cared about: is this user navigating in standalone mode?
If I hadn’t been writing about media features, I don’t think I would’ve been able to solve the problem. It’s a really good feeling when you’ve just learned something new, and then you immediately find exactly the right use case for it!
I had an extra long weekend recently. It was four days of being a culture vulture. It was also four days of ever-increasing risk assessment.
It began on Thursday morning with the first Salter Cane band practice in eighteen months. That was pretty safe—three of us in a room, reminding ourselves of how the songs go. I honestly thought it could’ve been a disaster and that I wouldn’t remember anything, but thanks to a little bit of last-minute revision the evening before, it actually went really well. And boy, did it feel good to plug in and play those songs again.
Later that day, Jessica went up to London. We spent that evening in the Royal Opera House, watching a ballet, The Dante Project. We wore masks. Not everyone else did.
The next day, the indoor gatherings continued. We went to the IMAX to see Dune. The opportunity was too good to pass up. It was wonderful! But again, while we wore masks for the duration, not everyone else did.
Still, I reckon the ventilation was reasonably good in both the Royal Opera House and the BFI’s IMAX cinema. But that evening we checked into the Clayton Crown Hotel in Cricklewood, venue for the Return To London Town festival of Irish traditional music.
That’s where we spent two days going to concerts, sessions, and workshops, all of them indoors. The music was great, and we had a lovely time, but I couldn’t help but feel a sense of nervousness throughout.
When we got back to Brighton, we both took lateral flow tests—thank goodness that these are freely available! We were both negative. We had dodged a viral bullet.
That was the last trip out of town we’ll be making for a while. But even for Brighton-based activities, this is the routine now: weigh up the risks, decide whether an activity is worth it, and if so, testing afterwards.
For example, the week after our trip to London, the Wednesday evening Irish music session at The Jolly Brewer pub started up again here in Brighton. It was one of the things I missed most during The Situation.
I wrote about this at the very start of the first lockdown:
I’m quite certain that one positive outcome of The Situation will be a new-found appreciation for activities we don’t have to do. I’m looking forward to sitting in a pub with a friend or two, or going to see a band, or a play or a film, and just thinking “this is nice.”
I certainly did find myself thinking “this is nice” during the session, which was as wonderful as I had remembered. But I was also thinking about ventilation, and distancing, and airflow. Like I said:
Risks. Benefits. Running the numbers. Making decisions. Trying to do the right thing. Trying to stay safe but also trying to live life.
I had fun coming up five trad music tracks related to the letter J.
On June 3rd, 2001, I launched thesession.org. Happy twentieth birthday to The Session!
Although actually The Session predates its domain name by a few years. It originally launched as a subdirectory here on adactio.com with the unwieldly URL /session/session.shtml
That incarnation was more like a blog. I’d post the sheetmusic for a tune every week with a little bit of commentary. That worked fine until I started to run out of tunes. That’s when I made the site dynamic. People could sign up to become members of The Session. Then they could also post tunes and add comments.
That’s the version that is two decades old today.
The last really big change to the site happened in 2012. As well as a complete redesign, I introduced lots of new functionality.
In all of those incarnations, the layout was fluid …long before responsive design swept the web. That was quite unusual twenty years ago, but I knew it was the webby thing to do.
What’s also unusual is just keeping a website going for twenty years. Keeping a community website going for twenty years is practically unheard of. I’m very proud of The Session. Although, really, I’m just the caretaker. The site would literally be nothing without all the contributions that people have made.
I’ve more or less adopted a Wikipedia model for contributions. Some things, like tune settings, can only be edited by the person who submitted it But other things, like the track listing of a recording, or the details of a session, can be edited by any member of the site. And of course anyone can add a comment to any listing. There’s a certain amount of risk to that, but after testing it for two decades, it’s working out very nicely.
What’s really nice is when I get to meet my fellow members of The Session in meatspace. If I’m travelling somewhere and there’s a local session happening, I always get a warm welcome. I mean, presumably everyone would get a warm welcome at those sessions, but I’ve also had my fair share of free pints thanks to The Session.
I feel a great sense of responsibility with The Session. But it’s not a weight of responsibility—the way that many open source maintainers describe how their unpaid labour feels. The sense of responsibility I feel drives me. It gives me a sense of purpose.
The Session is older than any client work I’ve ever done. It’s older than any books I’ve written. It’s even older than Clearleft by a few years. Heck, it’s even older than this blog (just).
I’m 50 years old now. The Session is 20 years old. That’s quite a chunk of my life. I think it’s fair to say that it’s part of me now. Of all the things I’ve made so far in my life, The Session is the one I’m proudest of.
I’m looking forward to stewarding the site through the next twenty years.
In 2020, I didn’t have the honour and privilege of speaking at An Event Apart in places like Seattle, Boston, and Minneapolis. I didn’t experience that rush that comes from sharing ideas with a roomful of people, getting them excited, making them laugh, sparking thoughts. I didn’t enjoy the wonderful and stimulating conversations with my peers that happen in the corridors, or over lunch, or at an after-party. I didn’t have a blast catching up with old friends or making new ones.
But the States wasn’t the only country I didn’t travel to. Closer to home, I didn’t have the opportunity to take the Eurostar and connecting trains to cities like Cologne, Lisbon, and Stockholm. I didn’t sample the food and drink of different countries.
In the summer, I didn’t travel to the west coast of Ireland for the second in year in a row for the annual Willie Clancy festival of traditional Irish music. I didn’t spend each day completely surrounded by music. I didn’t play in some great sessions. I didn’t hear some fantastic and inspiring musicians.
Back here in Brighton, I didn’t go to the session in The Jolly Brewer every Wednesday evening and get lost in the tunes. I didn’t experience that wonderful feeling of making music together and having a pint or two. And every second Sunday afternoon, I didn’t pop along to The Bugle for more jigs and reels.
I didn’t walk into work most days, arrive at the Clearleft studio, and make a nice cup of coffee while chit-chatting with my co-workers. I didn’t get pulled into fascinating conversations about design and development that spontaneously bubble up when you’re in the same space as talented folks.
Every few months, I didn’t get a haircut.
Throughout the year, I didn’t make any weekend trips back to Ireland to visit my mother.
2020 gave me a lot of free time. I used that time to not write a book. And with all that extra time on my hands, I read fewer books than I had read in 2019. Oh, and on the side, I didn’t learn a new programming language. I didn’t discover an enthusiasm for exercise. I didn’t get out of the house and go for a brisk walk on most days. I didn’t start each day prepping my sourdough.
But I did stay at home, thereby slowing the spread of a deadly infectious disease. I’m proud of that.
I did play mandolin. I did talk to my co-workers through a screen. I did eat very well—and very local and seasonal. I did watch lots of television programmes and films. I got by. Sometimes I even took pleasure in this newly-enforced lifestyle.
I made it through 2020. And so did you. That’s an achievement worth celebrating—congratulations!
Let’s see what 2021 doesn’t bring.
I added a dark mode to my site last year. Since then I’ve been idly toying with the addition of a dark mode to The Session too.
As with this site, the key to adding a dark mode was switching to custom properties for color and background-color declarations. But my plans kept getting derailed by the sheet music on the site. The sheet music is delivered as SVG generated by ABCJS which hard-codes the colour in stroke and fill attributes:
fill="#000000" stroke="#000000"
When I was describing CSS recently I mentioned the high specifity of inline styles:
Whereas external CSS and embedded CSS don’t have any effect on specificity, inline styles are positively radioactive with specificity.
Given that harsh fact of life, I figured it would be nigh-on impossible to over-ride the colour of the sheetmusic. But then I realised I was an idiot.
The stroke and fill attributes in SVG are presentational but they aren’t inline styles. They’re attributes. They have no affect on specifity. I can easily over-ride them in an external style sheet.
In fact, if I had actually remembered what I wrote when I was adding a dark mode to adactio.com, I could’ve saved myself some time:
I have SVGs of sparklines on my homepage. The SVG has a hard-coded colour value in the stroke attribute of the path element that draws the sparkline. Fortunately, this can be over-ridden in the style sheet:
svg.activity-sparkline path {
stroke: var(--text-color);
}
I was able to do something similar on The Session. I used the handy currentColor keyword in CSS so that the sheet music matched the colour of the text:
svg path {
fill: currentColor;
}
svg path:not(stroke="none") {
stroke: currentColor;
}
Et voila! I now had light-on-dark sheet music for The Session’s dark mode all wrapped up in a prefers-color-scheme: dark media query.
I pushed out out the new feature and started getting feedback. It could be best summarised as “Thanks. I hate it.”
It turns out that while people were perfectly fine with a dark mode that inverts the colours of text, it felt really weird and icky to do the same with sheet music.
On the one hand, this seems odd. After all, sheet music is a writing system like any other. If you’re fine with light text on a dark background, why doesn’t that hold for light sheet music on a dark background?
But on the other hand, sheet music is also like an image. And we don’t invert the colours of our images when we add a dark mode to our CSS.
With that in mind, I went back to the drawing board and this time treated the sheet music SVGs as being intrinsicly dark-on-light, rather than a stylistic choice. It meant a few more CSS rules, but I’m happy with the final result. You can see it in action by visiting a tune page and toggling your device’s “appearance” settings between light and dark.
If you’re a member of The Session, I also added a toggle switch to your member profile so you can choose dark or light mode regardless of your device settings.
I told you about how I’m using the Web Audio API on The Session to generate synthesised audio of each tune setting. I also said:
Except for some weirdness on iOS that I had to fix.
Here’s that weirdness…
Let me start by saying that this isn’t anything to do with requiring a user interaction (the Web Audio API insists on some kind of user interaction to prevent developers from having auto-playing sound on websites). All of my code related to the Web Audio API is inside a click event handler. This is a different kind of weirdness.
First of all, I noticed that if you pressed play on the audio player when your iOS device is on mute, then you don’t hear any audio. Seems logical, right? Except if using the same device, still set to mute, you press play on a video or audio element, the sound plays just fine. You can confirm this by going to Huffduffer and pressing play on any of the audio elements there, even when your iOS device is set on mute.
So it seems that iOS has different criteria for the Web Audio API than it does for audio or video. Except it isn’t quite that straightforward.
On some pages of The Session, as well as the audio player for tunes (using the Web Audio API) there are also embedded YouTube videos (using the video element). Press play on the audio player; no sound. Press play on the YouTube video; you get sound. Now go back to the audio player and suddenly you do get sound!
It’s almost like playing a video or audio element “kicks” the browser into realising it should be playing the sound from the Web Audio API too.
This was happening on iOS devices set to mute, but I was also getting reports of it happening on devices with the sound on. But it’s that annoyingly intermittent kind of bug that’s really hard to reproduce consistently. Sometimes the sound doesn’t play. Sometimes it does.
Following my theory that the browser needs a “kick” to get into the right frame of mind for the Web Audio API, I resorted to a messy little hack.
In the event handler for the audio player, I generate the “kick” by playing a second of silence using the JavaScript equivalent of the audio element:
var audio = new Audio('1-second-of-silence.mp3');
audio.play();
I’m not proud of that. It’s so hacky that I’ve even wrapped the code in some user-agent sniffing on the server, and I never do user-agent sniffing!
Still, if you ever find yourself getting weird but inconsistent behaviour on iOS using the Web Audio API, this nasty little hack could help.
Update: Time to remove this workaround. Mobile Safari has been updated.
I spent the last couple of weekends rolling out a new feature on The Session. It involves playing audio in a web page. No big deal these days, right? But the history involves some old file formats…
The first venerable format is ABC notation. File extension: .abc, mime type: text/vnd.abc. It’s an ingenious text format for musical notation using ASCII. The metadata of the piece of music is defined in JSON-like key/value pairs. Then the contents are encoded with letters: A, B, C, etc. Uppercase and lowercase denote different octaves. Numbers can be used for note lengths.
The format was created by Chris Walshaw in 1997 when dial-up was the norm. With ABC, people were able to swap tunes on email lists or bulletin boards without transferring weighty image or sound files. If you had ABC software on your computer, you could convert that lightweight text file into sheet music …or audio.
That brings me to the second old format: midi files. File extension: .mid, mime-type: audio/midi. Like ABC, it’s a lightweight format for encoding the instructions for music instead of the music itself.
Think of it like SVG: instead of storing the final pixels of an image, SVG stores the instructions for drawing the image instead. The instructions in a midi file are like “play this note for this long on this instrument.” Again, as with ABC, you need some software to turn the instructions into sound.
There was a time when lots of software could play midi files. Quicktime on the Mac, for example. You could even embed midi files in web pages. I mean literally embed them …with the embed element. No Geocities page was complete without an autoplaying midi file.
On The Session, people submit tunes in ABC format. Then, using the amazing ABCJS JavaScript library, the ABC is turned into SVG on the fly! For years I’ve also offered midi files, generated on the server from the ABC notation.
But times have changed. These days it’s hard to find software that plays midi files. Quicktime doesn’t do it anymore. And you’d need to go to the app store on iOS to find a midi file player. It’s time to phase out the midi files on The Session.
I still want to provide automatically-generated audio though. Fortunately ABCJS gives me a way to do this. But instead of using the old technology of midi files, it uses a more modern browser feature: the Web Audio API.
The end result sounds like a midi file, but the underlying technique is more like a synthesiser. There’s a separate mp3 file for each note. The JavaScript figures out how long each “sample” needs to be played for, strings them all together, and outputs them with Web Audio. So you’ve got cutting-edge browser technology recreating a much older file format. Paul Rosen—the creator of ABCJS—has a presentation explaining how it all works under the hood.
Not only is there a separate short mp3 file for each note in seven octaves, but if you want the sound of a different instrument, you need samples for all seven octaves in that instrument. They’re called soundfonts.
Paul provides soundfonts for ABCJS. It’s a repo that was forked from this repo from Benjamin Gleitzman. And here’s where it gets small worldy…
The reason why Benjamin has a repo of soundfonts is because he needed to create midi-like audio in the browser. He wanted to do this for a project on September 28th and 29th, 2013 …at Science Hack Day San Francisco!
I was there too—working on my own audio-related hack—and I remember the excellent (and winning) hack that Benjamin worked on. It was called Symphony of Satellites and it’s still online along with the promo video. Here’s Benjamin’s post-hackday write-up from seven years ago.
It’s rare that the worlds of the web and Irish music cross over. When I got to meet Paul—creator of ABCJS—at a web conference a couple of years ago it kind of blew my mind. Last weekend when I set out to dabble with a feature on The Session, I certainly didn’t expect to stumble on a connection to Science Hack Day! (Aside: the first Science Hack Day was ten years ago—yowzers!)
Anyway, I was able to get that audio playback working on The Session. Except for some weirdness on iOS that I had to fix. But that’s a hack for another day.
I added a long-overdue enhancement to The Session recently. Here’s the scenario…
You’re on a web page with a comment form. You type your well-considered thoughts into a textarea field. But then something happens. Maybe you accidentally navigate away from the page or maybe your network connection goes down right when you try to submit the form.
This is a textbook case for storing data locally on the user’s device …at least until it has safely been transmitted to the server. So that’s what I set about doing.
My first decision was choosing how to store the data locally. There are multiple APIs available: sessionStorage, IndexedDB, localStorage. It was clear that sessionStorage wasn’t right for this particular use case: I needed the data to be saved across browser sessions. So it was down to IndexedDB or localStorage. IndexedDB is the more versatile and powerful—because it’s asynchronous—but localStorage is nice and straightforward so I decided on that. I’m not sure if that was the right decision though.
Alright, so I’m going to store the contents of a form in localStorage. It accepts key/value pairs. I’ll make the key the current URL. The value will be the contents of that textarea. I can store other form fields too. Even though localStorage technically only stores one value, that value can be a JSON object so in reality you can store multiple values with one key (just remember to parse the JSON when you retrieve it).
Now I know what I’m going to store (the textarea contents) and how I’m going to store it (localStorage). The next question is when should I do it?
I could play it safe and store the comment whenever the user presses a key within the textarea. But that seems like overkill. It would be more efficient to only save when the user leaves the current page for any reason.
Alright then, I’ll use the unload event. No! Bad Jeremy! If I use that then the browser can’t reliably add the current page to the cache it uses for faster back-forwards navigations. The page life cycle is complicated.
So beforeunload then? Well, maybe. But modern browsers also support a pagehide event that looks like a better option.
In either case, just adding a listener for the event could screw up the caching of the page for back-forwards navigations. I should only listen for the event if I know that I need to store the contents of the textarea. And in order to know if the user has interacted with the textarea, I’m back to listening for key presses again.
But wait a minute! I don’t have to listen for every key press. If the user has typed anything, that’s enough for me. I only need to listen for the first key press in the textarea.
Handily, addEventListener accepts an object of options. One of those options is called “once”. If I set that to true, then the event listener is only fired once.
So I set up a cascade of event listeners. If the user types anything into the textarea, that fires an event listener (just once) that then adds the event listener for when the page is unloaded—and that’s when the textarea contents are put into localStorage.
I’ve abstracted my code into a gist. Here’s what it does:
localStorage, bail out.localStorage key to be the current URL.textarea with the value in localStorage.textarea in localStorage but don’t call the function yet.textarea, start listening for the page being unloaded.textarea in localStorage.localStorage for the current URL.That last step isn’t something I’m doing on The Session. Instead I’m relying on getting something back from the server to indicate that the form was successfully submitted. If you can do something like that, I’d recommend that instead of listening to the form submission event. After all, something could still go wrong between the form being submitted and the data being received by the server.
Still, this bit of code is better than nothing. Remember, it’s intended as an enhancement. You should be able to drop it into any project and improve the user experience a little bit. Ideally, no one will ever notice it’s there—it’s the kind of enhancement that only kicks in when something goes wrong. A little smidgen of resilient web design. A defensive enhancement.