Tags: is

2655

sparkline

Sunday, December 8th, 2019

On this day

I’m in San Francisco to speak at An Event Apart, which kicks off tomorrow. But I arrived a few days early so that I could attend Indie Web Camp SF.

Yesterday was the discussion day. Most of the attendees were seasoned indie web campers, so quite a few of the discussions went deep on some of the building blocks. It was a good opportunity to step back and reappraise technology decisions.

Today is the day for making, tinkering, fiddling, and hacking. I had a few different ideas of what to do, mostly around showing additional context on my blog posts. I could, for instance, show related posts—other blog posts (or links) that have similar tags attached to them.

But I decided that a nice straightforward addition would be to show a kind of “on this day” context. After all, I’ve been writing blog posts here for eighteen years now; chances are that if I write a blog post on any given day, there will be something in the archives from that same day in previous years.

So that’s what I’ve done. I’ll be demoing it shortly here at Indie Web Camp, but you can see it in action now. If you look at the page for this blog post, you should see a section at the end with the heading “Previously on this day”. There you’ll see links to other posts I’ve written on December 8th in years gone by.

It’s quite a mixed bag. There’s a post about when I used to have a webcam from sixteen years ago. There’s a report from the Flash On The Beach conference from thirteen years ago (I wrote that post while I was in Berlin). And five years ago, I was writing about markup patterns for web components.

I don’t know if anyone other than me will find this feature interesting (but as it’s my website, I don’t really care). Personally, I find it fascinating to see how my writing has changed, both in terms of subject matter and tone.

Needless to say, the further back in time you go, the more chance there is that the links in my blog posts will no longer work. That’s a real shame. But then it’s a pleasant surprise when I find something that I linked to that is still online after all this time. And I can take comfort from the fact that if anyone has ever linked to anything I’ve written on my website, then those links still work.

Monday, December 2nd, 2019

Oddly Amazing Animals from A to Z

This book is a beautiful tribute to Cindy.

Several talented illustrators have come together to create a unique book about unique animals. Each contributor has a special connection to the book’s original illustrator, Cindy Li. When she was unable to complete the illustrations before passing away in 2018, many of Cindy’s talented friends offered to help finish the project.

I think you should get a copy of this book for the little animal lover in your life this Christmas.

Proceeds from the sale of this book benefit Apollo Li Harris and Orion Li Harris, two out-of-this-world kids who had an amazing mom.

Saturday, November 30th, 2019

The Size of Space

Celestial objects ordered by size, covering a scale from one astronaut to the observable universe.

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.

Well, fast forward to the past few weeks, when I was contacted by one of the screen-reader users on The Session. There was, once again, a problem with the Ajax pagination, specifically with VoiceOver on iOS. The first page of results were read out just fine, but subsequent pages were not only never announced, the content was completely unavailable. The first page of results would’ve been included in the initial HTML, but the subsequent pages of results are injected with JavaScript (if JavaScript is available—otherwise it’s regular full-page refreshes all the way).

This pagination pattern shows up all over the site: lists of what’s new, search results, and more. I turned on VoiceOver and I was able to reproduce the problem straight away.

I started pulling apart my JavaScript looking for the problem. Was it something to do with how I was handling focus? I just couldn’t figure it out. And other parts of the site that used Ajax didn’t seem to be having the same problem. I was mystified.

Finally, I tracked down the problem, and it wasn’t in the JavaScript at all.

Wherever the pagination pattern appears, there are “previous” and “next” links, marked up with the appropriate rel="prev" and 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.

Case Study: lynnandtonic.com 2019 refresh - lynnandtonic.com

Lynn gives a step-by-step walkthrough of the latest amazing redesign of her website. There’s so much joy and craft in here, with real attention to detail—I love it!

Saturday, November 23rd, 2019

Save .ORG | SaveDotOrg.org

I’ve signed this letter.

Friday, November 22nd, 2019

Design APIs: The Evolution of Design Systems by Matthew Ström

This is an interesting comparison: design systems as APIs. It makes sense. A design system—like an API—is a contract. Also, an API without documentation is of little use …much like a design system without documentation.

Fit on a Floppy

Here’s a nice little test for the file size of your web pages—could they fit on a floppy disk?

The Session fits comfortably and adactio.com just about scrapes by.

Sacha Baron Cohen’s Keynote Address at ADL’s 2019 Never Is Now Summit on Anti-Semitism and Hate | Anti-Defamation League

On the internet, everything can appear equally legitimate. Breitbart resembles the BBC. The fictitious Protocols of the Elders of Zion look as valid as an ADL report. And the rantings of a lunatic seem as credible as the findings of a Nobel Prize winner. We have lost, it seems, a shared sense of the basic facts upon which democracy depends.

Thursday, November 21st, 2019

Request with Intent: Caching Strategies in the Age of PWAs – A List Apart

Aaron outlines some sensible strategies for serving up images, including using the Cache API from your service worker script.

Good Enough | Max Böck - Frontend Web Developer

I know the anxiety of sharing something with the world. I know there is a pressure to match the quality we see elsewhere on the web. But maybe we should stop trying to live up to somebody else’s standards and focus on just getting stuff out there instead. Maybe our “imperfect” things are already helpful to someone. Maybe this shouldn’t be so hard.

Surveillance giants: How the business model of Google and Facebook threatens human rights | Amnesty International

Amnesty International have released a PDF report on the out-of-control surveillance perpetrated by Google and Facebook:

Google and Facebook’s platforms come at a systemic cost. The companies’ surveillance-based business model forces people to make a Faustian bargain, whereby they are only able to enjoy their human rights online by submitting to a system predicated on human rights abuse. Firstly, an assault on the right to privacy on an unprecedented scale, and then a series of knock-on effects that pose a serious risk to a range of other rights, from freedom of expression and opinion, to freedom of thought and the right to non-discrimination.

However…

This page on the Amnesty International website has six tracking scripts. Also, consent to accept tracking cookies is assumed (check dev tools). It looks like you can reject marketing cookies, but I tried that without any success.

The stone PDF has been thrown from a very badly-performing glass house.

Tuesday, November 19th, 2019

Modest JS Works | You were never sold on heavy-handed JavaScript approaches. Here’s a case for keeping your JS modest.

The fat JavaScript stacks-du-jour have a lot of appeal. They promise you to be able to do more with less. But what if I want to do less?

This is a terrific little (free!) online book all about modest JavaScript. The second part has practical code, but it’s the first part—all about the principles of staying lean—that really resonates with me.

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

Responsible JavaScript: Part III – A List Apart

This chimes nicely with my recent post on third-party scripts. Here, Jeremy treats third-party JavaScript at technical debt and outlines some solutions to staying on top of it.

Convenience always has a price, and the web is wracked by our collective preference for it. JavaScript, in particular, is employed in a way that suggests a rapidly increasing tendency to outsource whatever it is that We (the first party) don’t want to do. At times, this is a necessary decision; it makes perfect financial and operational sense in many situations.

But make no mistake, third-party JavaScript is never cheap. It’s a devil’s bargain where vendors seduce you with solutions to your problem, yet conveniently fail to remind you that you have little to no control over the side effects that solution introduces.

Saturday, November 16th, 2019

The new dot com bubble is here: it’s called online advertising - The Correspondent

The benchmarks that advertising companies use — intended to measure the number of clicks, sales and downloads that occur after an ad is viewed — are fundamentally misleading. None of these benchmarks distinguish between the selection effect (clicks, purchases and downloads that are happening anyway) and the advertising effect (clicks, purchases and downloads that would not have happened without ads).

It gets worse: the brightest minds of this generation are creating algorithms which only increase the effects of selection.

A terrificly well-written piece on the emperor’s new clothes worn by online advertising. Equal parts economic rigour and Gladwellian anecdata, it’s a joy to read! Kudos to Alana Gillespie for the great translation work (the original article was written in Dutch).

We currently assume that advertising companies always benefit from more data. … But the majority of advertising companies feed their complex algorithms silos full of data even though the practice never delivers the desired result. In the worst case, all that invasion of privacy can even lead to targeting the wrong group of people.

This insight is conspicuously absent from the debate about online privacy. At the moment, we don’t even know whether all this privacy violation works as advertised.

The interaction design of this article is great too—annotations, charts, and more!

The Layers Of The Web

Here are the slides from my opening keynote at Beyond Tellarrand on Thursday. They don’t make much sense out of context.

The Layers Of The Web - Jeremy Keith on Vimeo

Thanks to the quick work of Marc and his team, the talk I gave at Beyond Tellerrand on Thursday was online within hours!

I’m really pleased with how this turned out. I wasn’t sure if anybody was going to be interested in the deep dive into history that I took for the first 15 or 20 minutes, but lots of people told me that they really enjoyed that part, so that makes me happy.

Tuesday, November 12th, 2019

Third party

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.

But here’s the thing: the technologies that enable tracking and surveillance didn’t exist in the early years of the web—JavaScript and cookies.

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.

Then there’s third-party JavaScript.

In retrospect, it seems unbelievable that third-party JavaScript is even possible. I mean, putting arbitrary code—that can then inject even more arbitrary code—onto your website? That seems like a security nightmare!

I imagine if JavaScript were being specced today, it would almost certainly be restricted to the same origin by default. But I guess the precedent had been set with images and style sheets: they could be embedded regardless of whether their domain names matched yours. Still, this is executable code we’re talking about here: that’s quite a footgun that the web has given site owners. And boy, oh boy, has it been used by the worst people to do the most damage.

Again, as with cookies, if we were to imagine what the web would be like if JavaScript was restricted by a same-domain policy, there are certainly things that would be trickier to do.

  • 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.)

It’s harder to imagine putting the genie back in the bottle when it comes to third-party JavaScript than it is with third-party cookies. All the same, I wish that browsers made it easier to experiment with it. Just as I can choose to accept all cookies, reject all cookies, or only accept same-origin cookies, I wish I could accept all JavaScript, reject all JavaScript, or only accept same-origin JavaScript.

As it is, browsers are making it harder and harder to exercise any control over JavaScript at all. So we reach for third-party tools. We don’t call them JavaScript managers though. We call them ad blockers. But honestly, most of the ad-blocker users I know—myself included—are not bothered by the advertising; we’re bothered by the tracking. We should really call them surveillance blockers.

If third-party JavaScript weren’t the norm, not only would it make the web more secure, it would make it way more performant. Read the chapter on third parties in this year’s newly-released Web Almanac. The figures are staggering.

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.

I don’t think all the web’s performance ills are due to third-party scripts; developers are doing a bang-up job of making their sites big and bloated with their own self-hosted frameworks and code. But as long as third-party JavaScript is allowed onto a site, there’s a limit to how much good developers can do to improve the performance of their sites.

I go to performance-related conferences and you know who I’ve never seen at those events? The people who write the JavaScript for third-party tracking scripts. Those developers are wielding an outsized influence on the health of the web.

I’m very happy to see the work being done by Mozilla and Apple to normalise the idea of rejecting third-party cookies. I’d love to see the rejection of third-party JavaScript normalised in the same way. I know that it would make my life as a developer harder. But that’s of lesser importance. It would be better for the web.

Thursday, November 7th, 2019

Near miss

When I was travelling across the Atlantic ocean on the Queen Mary 2 back in August, I had the pleasure of attending a series of on-board lectures by Charles Barclay from the Royal Astronomical Society.

One of those presentations was on the threat of asteroid impacts—always a fun topic! Charles mentioned Spaceguard, the group that tracks near-Earth objects.

Spaceguard is a pretty cool-sounding name for any organisation. The name comes from a work of (science) fiction. In Arthur C. Clarke’s 1973 book Rendezvous with Rama, Spaceguard is the name of a fictional organisation formed after a devastating asteroid impact on northen Italy—an event which is coincidentally depicted as happening on September 11th. That’s not a spoiler, by the way. The impact happens on the first page of the book.

At 0946 GMT on the morning of September 11 in the exceptionally beautiful summer of the year 2077, most of the inhabitants of Europe saw a dazzling fireball appear in the eastern sky.  Within seconds it was brighter than the Sun, and as it moved across the heavens—at first in utter silence—it left behind it a churning column of dust and smoke.

Somewhere above Austria it began to disintegrate, producing a series of concussions so violent that more than a million people had their hearing permanently damaged.  They were the lucky ones.

Moving at fifty kilometers a second, a thousand tons of rock and metal impacted on the plains of northern Italy, destroying in a few flaming moments the labor of centuries.

Later in the same lecture, Charles talked about the Torino scale, which is used to classify the likelihood and severity of impacts. Number 10 on the Torino scale means an impact is certain and that it will be an extinction level event.

Torino—Turin—is in northern Italy. “Wait a minute!”, I thought to myself. “Is this something that’s also named for that opening chapter of Rendezvous with Rama?”

I spoke to Charles about it afterwards, hoping that he might know. But he said, “Oh, I just assumed that a group of scientists got together in Turin when they came up with the scale.”

Being at sea, there was no way to easily verify or disprove the origin story of the Torino scale. Looking something up on the internet would have been prohibitively slow and expensive. So I had to wait until we docked in New York.

On our first morning in the city, Jessica and I popped into a bookstore. I picked up a copy of Rendezvous with Rama and re-read the details of that opening impact on northern Italy. Padua, Venice and Verona are named, but there’s no mention of Turin.

Sure enough, when I checked Wikipedia, the history and naming of the Torino scale was exactly what Charles Barclay surmised:

A revised version of the “Hazard Index” was presented at a June 1999 international conference on NEOs held in Torino (Turin), Italy. The conference participants voted to adopt the revised version, where the bestowed name “Torino Scale” recognizes the spirit of international cooperation displayed at that conference toward research efforts to understand the hazards posed by NEOs.