Thursday, December 12th, 2019
Wednesday, December 11th, 2019
It was such a pleasure and an honour to watch Saron at work—she did an amazing job!
Thursday, December 5th, 2019
JS is also global by default. We use IIFEs and wrapper functions to add scope.
Wednesday, November 27th, 2019
Accessibility on The Session revisited
Earlier this year, I wrote about an accessibility issue I was having on The Session. Specifically, it was an issue with Ajax and pagination. But I managed to sort it out, and the lesson was very clear:
As is so often the case, the issue was with me trying to be too clever with ARIA, and the solution was to ease up on adding so many ARIA attributes.
Wherever the pagination pattern appears, there are “previous” and “next” links, marked up with the appropriate
rel="next" attributes. Well, apparently past me thought it would be clever to add some ARIA attributes in there too. My thinking must’ve been something like this:
- Those links control the area of the page with the search results.
- That area of the page has an ID of “results”.
- I should add
aria-controls="results"to those links.
That was the problem …which is kind of weird, because VoiceOver isn’t supposed to have any support for
aria-controls. Anyway, once I removed that attribute from the links, everything worked just fine.
Just as the solution last time was to remove the
aria-atomic attribute on the updated area, the solution this time was to remove the
aria-controls attribute on the links that trigger the update. Maybe this time I’ll learn my lesson: don’t mess with ARIA attributes you don’t understand.
Wednesday, November 20th, 2019
Tuesday, November 19th, 2019
I’ve found that the older I get, the less I care about looking stupid. This is remarkably freeing. I no longer have any hesitancy about raising my hand in a meeting to ask “What’s that acronym you just mentioned?” This sometimes has the added benefit of clarifying something for others in the room who might have been to shy to ask.
I remember a few years back being really confused about
npm. Fortunately, someone who was working at
npm at the time came to Brighton for FFConf, so I asked them to explain it to me.
As I understood it,
npm was intended to be used for managing packages of code for Node. Wasn’t it actually called “Node Package Manager” at one point, or did I imagine that?
Anyway, the mental model I had of
npm is to Node as PEAR is to PHP. A central repository of open source code projects that you could easily add to your codebase …for your server-side code.
But then I saw people talking about using
It turns out that my confusion was somewhat warranted. The
npm project had indeed started life as a repo for server-side code but had since expanded to encompass client-side code too.
I understand how it happened, but it confirmed a worrying trend I had noticed. Developers were writing front-end code as though it were back-end code.
On the other hand, it makes no sense at all! If your code’s run-time is on the server, then the size of the codebase doesn’t matter that much. Whether it’s hundreds or thousands of lines of code, the execution happens more or less independentally of the network. But that’s not how front-end development works. Every byte matters. The more code you write that needs to be executed on the user’s device, the worse the experience is for that user. You need to limit how much you’re using the network. That means leaning on what the browser gives you by default (that’s your run-time environment) and keeping your code as lean as possible.
Dave echoes my concerns in his end-of-the-year piece called The Kind of Development I Like:
I now think about npm and wonder if it’s somewhat responsible for some of the pain points of modern web development today. Fact is, npm is a server-side technology that we’ve co-opted on the client and I think we’re feeling those repercussions in the browser.
The Unix Philosophy encourages us to write small micro libraries that do one thing and do it well. The Node.js Ecosystem did this in spades. This works great on the server where importing a small file has a very small cost. On the client, however, this has enormous costs.
In a funny way, this situation reminds me of something I saw happening over twenty years ago. Print designers were starting to do web design. They had a wealth of experience and knowledge around colour theory, typography, hierarchy and contrast. That was all very valuable to bring to the world of the web. But the web also has fundamental differences to print design. In print, you can use as many typefaces as you want, whereas on the web, to this day, you need to be judicious in the range of fonts you use. But in print, you might have to limit your colour palette for cost reasons (depending on the printing process), whereas on the web, colours are basically free. And then there’s the biggest difference of all: working within known dimensions of a fixed page in print compared to working within the unknowable dimensions of flexible viewports on the web.
Fast forward to today and we’ve got a lot of Computer Science graduates moving into front-end development. They’re bringing with them a treasure trove of experience in writing robust scalable code. But web browsers aren’t like web servers. If your back-end code is getting so big that it’s starting to run noticably slowly, you can throw more computing power at it by scaling up your server. That’s not an option on the front-end where you don’t really have one run-time environment—your end users have their own run-time environment with its own constraints around computing power and network connectivity.
That’s a very, very challenging world to get your head around. The safer option is to stick to the mental model you’re familiar with, whether you’re a print designer or a Computer Science graduate. But that does a disservice to end users who are relying on you to deliver a good experience on the World Wide Web.
Don’t build more JS than you can maintain over the long term. If you’re going to be building something for a long time, make sure what you are building will grow with you. Make sure you don’t depend on other people’s work too much, lest you want to keep refactoring your code when the framework you picked goes out of style.
Sunday, November 17th, 2019
Let us not overlook the fact that a semantic HTML web site is inherently accessible by default. When we bend the web to our will, we break that. So we have a responsibility to correct it. Sure the new technologies are neat, but the end result is usually garbage. This all requires some next-level narcissism that our goals and priorities as developers are far more important than that of the audience we’re theoretically building software to serve.
Tuesday, November 12th, 2019
The web turned 30 this year. When I was back at CERN to mark this anniversary, there was a lot of introspection and questioning the direction that the web has taken. Everyone I know that uses the web is in agreement that tracking and surveillance are out of control. It seems only right to question whether the web has lost its way.
Without cookies, the web was stateless. This was by design. Now, I totally understand why cookies—or something like cookies—were needed. Without some way of keeping track of state, there’s no good way for a website to “remember” what’s in your shopping cart, or whether you’ve authenticated yourself.
But why would cookies ever need to work across domains? Authentication, shopping carts and all that good stuff can happen on the same domain. Third-party cookies, on the other hand, seem custom made for tracking and frankly, not much else.
Browsers allow you to disable third-party cookies, though it’s not yet the default. If enough people do it—and complain about the sites that stop working when third-party cookies are disabled—then maybe it can become the default.
Firefox is taking steps in this direction, automatically disabling some third-party cookies—the ones that known trackers. Safari is also taking steps to prevent cross-site tracking. It’s not too late to change the tide of third-party cookies.
- Embedding video, audio, and maps would get a lot finickier.
- Analytics would need to be self-hosted. I don’t think that would bother any site owners. An analytics platform like Google Analytics that tracks people across domains is doing it for its own benefit rather than that of site owners.
- Advertising wouldn’t be creepy and annoying. Instead of what’s so euphemistically called “personalisation”, advertisers would have to rely on serving relevant ads based on the content of the site rather than an invasive psychological profile of the user. (I honestly think that advertisers would benefit from this kind of targetting.)
93% of pages include at least one third-party resource, 76% of pages issue a request to an analytics domain, the median page requests content from at least 9 unique third-party domains that represent 35% of their total network activity, and the most active 10% of pages issue a whopping 175 third-party requests or more.
Monday, November 11th, 2019
When it comes to frameworks and UI libraries, there are some interesting numbers. Given the volume of chatter in the dev world, you’d be forgiven for thinking that React is used on the majority of websites today. The real number? 4.6% of websites. That’s less than the number of websites using CSS custom properties.
This is reminding me of what I wrote about dev perception.
Thursday, November 7th, 2019
Nolan writes up what he learned making accessibiity improvements to a single page app. The two big takeways involve letting the browser do the work for you:
Here’s the best piece of accessibility advice for newbies: if something is a button, make it a
<button>. If something is an input, make it an
<input>. Don’t try to reinvent everything from scratch using
And then there are all the issues that crop up when you take over the task of handling navigations:
- You need to manage focus yourself.
- You need to manage scroll position yourself.
For classic server-rendered pages, most browser engines give you this functionality for free. You don’t have to code anything. But in an SPA, since you’re overriding the normal navigation behavior, you have to handle the focus yourself.
Tuesday, November 5th, 2019
The answer to that is around 1% of the time.
If you had an application bug which occurred 1% of the time, you’d fix it. No team I’ve come across would put up with that level of reliability.
Thursday, October 31st, 2019
Remember when I wrote about adding travel maps to my site at the recent Indie Web Camp Brighton? I must confess that the last line I wrote was an attempt to catch a fish from the river of the lazy web:
It’s a shame that I can’t use the lovely Stamen watercolour tiles for these static maps though.
In the spirit of Cunningham’s Law, I was hoping that somebody was going to respond with “It’s totally possible to use Stamen’s watercolour tiles for static maps, dumbass—look!” (to which my response would have been “thank you very much!”).
Alas, no such response was forthcoming. The hoped-for schooling never forthcame.
Still, I couldn’t quite let go of the idea of using those lovely watercolour maps somewhere on my site. But I had decided that dynamic maps would have been overkill for my archive pages:
Sure, it looked good, but displaying the map required requests for a script, a style sheet, and multiple map tiles.
Then I had a thought. What if I keep the static maps on my archive pages, but make them clickable? Then, on the other end of that link, I can have the dynamic version. In other words, what if I had a separate URL just for the dynamic maps?
These seemed like a good plan to me, so while I was travelling by Eurostar—the only way to travel—back from the lovely city of Antwerp where I had been speaking at Full Stack Europe, I started hacking away on making the dynamic maps even more dynamic. After all, now that they were going to have their own pages, I could go all out with any fancy features I wanted.
I kept coming back to my original goal:
I was looking for something more like the maps in Indiana Jones films—a line drawn from place to place to show the movement over time.
I found a plug-in for Leaflet.js that animates polylines—thanks, Iván! With a bit of wrangling, I was able to get it to animate between the lat/lon points of whichever archive section the map was in. Rather than have it play out automatically, I also added a control so that you can start and stop the animation. While I was at it, I decided to make that “play/pause” button do something else too. Ahem.
If you’d like to see the maps in action, click the “play” button on any of these maps:
- Everything from this August.
- Links from June 2017.
- Photos from October 2014.
- The entirety of 2018—that might take a while.
You get the idea. It’s all very silly really. It’s right up there with the time I made my sparklines playable. But that’s kind of the point. It’s my website so I can do whatever I want with it, no matter how silly.
First of all, the research department for adactio.com (that’s me) came up with the idea. Then that had to be sold in to upper management (that’s me too). A team was spun up to handle design and development (consisting of me and me). Finally, the finished result went live thanks to the tireless efforts of the adactio.com ops group (that would be me). Any feedback should be directed at the marketing department (no idea who that is).
Tuesday, October 29th, 2019
Friday, October 25th, 2019
Here’s a nice example of showing pages offline. It’s subtly different from what I’m doing on my own site, which goes to show that there’s no one-size-fits-all recipe when it comes to offline strategies.
HTML lets you create the structure of a website.
CSS lets you make the website look nice.
Monday, October 21st, 2019
It was Indie Web Camp Brighton on the weekend. After a day of thought-provoking discussions, I thoroughly enjoyed spending the second day tinkering on my website.
For a while now, I’ve wanted to add maps to my monthly archive pages (to accompany the calendar heatmaps I added at a previous Indie Web Camp). Whenever I post anything to my site—a blog post, a note, a link—it’s timestamped and geotagged. I thought it would be fun to expose that in a glanceable way. A map seems like the right medium for that, but I wanted to avoid the obvious route of dropping a load of pins on a map. Instead I was looking for something more like the maps in Indiana Jones films—a line drawn from place to place to show the movement over time.
After two hours, I admitted defeat.
I was able to find the kind of static maps I wanted from Mapbox—I’m already using them for my check-ins. I could even add a polyline, which is exactly what I wanted. But instead of passing latitude and longitude co-ordinates for the points on the polyline, the docs explain that I needed to provide …cur ominous thunder and lightning… The Encoded Polyline Algorithm Format.
Go to that link. I’ll wait.
Did you read through the eleven steps of instructions? Did you also think it was a piss take?
- Take the initial signed value.
- Multiply it by 1e5.
- Convert that decimal value to binary.
- Left-shift the binary value one bit.
- If the original decimal value is negative, invert this encoding.
- Break the binary value out into 5-bit chunks.
- Place the 5-bit chunks into reverse order.
- OR each value with 0x20 if another bit chunk follows.
- Convert each value to decimal.
- Add 63 to each value.
- Convert each value to its ASCII equivalent.
This was way beyond my brain’s pay grade. But surely someone else had written the code I needed? I did some Duck Duck Going and found a piece of PHP code to do the encoding. It didn’t work. I Ducked Ducked and Went some more. I found a different piece of PHP code. That didn’t work either.
At this point, my allotted time was up. If I wanted to have something to demo by the end of the day, I needed to switch gears. So I did.
It waits until the page has finished loading, then it searches for any instances of the
h-geo microformat (a way of encoding latitude and longitude coordinates in HTML). If there are three or more, it generates a
script element to pull in the Leaflet library, and a corresponding
style element. Then it draws the map with the polyline on it. I ended up using Stamen’s beautiful watercolour map tiles.
That’s what I demoed at the end of the day.
But I wasn’t happy with it.
Sure, it looked good, but displaying the map required requests for a script, a style sheet, and multiple map tiles. I made sure that it didn’t hold up the loading of the rest of the page, but it still felt wasteful.
So after Indie Web Camp, I went back to investigate static maps again. This time I did finally manage to find some PHP code for encoding lat/lon coordinates into a polyline that worked. Finally I was able to construct URLs for a static map image that displays a line connecting multiple points with a line.
I’ve put this maps on any of the archive pages that also have calendar heat maps. Some examples:
- Everything from August 2019
- Notes from July 2018
- Links from June 2017
- Photos from October 2014
- Journal entries from December 2012
If you go back much further than that, the maps start to trail off. That’s because I wasn’t geotagging everything from the start.
I’m pretty happy with the final results. It’s certainly far more responsible from a performance point of view. Oh, and I’ve also got the maps inside a
picture element so that I can swap out the tiles if you switch to dark mode.
It’s a shame that I can’t use the lovely Stamen watercolour tiles for these static maps though.
Wednesday, October 16th, 2019
Max describes how he does bookmarking on his own site—he’s got a bookmarklet for sharing links, like I do. But he goes further with a smart use of the “share target” section in his web app manifest, as described by Aaron.