Journal tags: ie

372

sparkline

Image previews with the FileReader API

I added a “notes” section to this website eight years ago. I set it up so that notes could be syndicated to Twitter. Ever since then, that’s the only way I post to Twitter.

A few months later I added photos to my notes. Again, this would get syndicated to Twitter.

Something’s bothered me for a long time though. I initially thought that if I posted a photo, then the accompanying text would serve as a decription of the image. It could effectively act as the alt text for the image, I thought. But in practice it didn’t work out that way. The text was often a commentary on the image, which isn’t the same as a description of the contents.

I needed a way to store alt text for images. To make it more complicated, it was possible for one note to have multiple images. So even though a note was one line in my database, I somehow needed a separate string of text with the description of each image in a single note.

I eventually settled on using the file system instead of the database. The images themselves are stored in separate folders, so I figured I could have an accompanying alt.txt file in each folder.

Take this note from yesterday as an example. Different sizes of the image are stored in the folder /images/uploaded/19077. Here’s a small version of the image and here’s the original. In that same folder is the alt text.

This means I’m reading a file every time I need the alt text instead of reading from a database, which probably isn’t the most performant way of doing it, but it seems to be working okay.

Here’s another example:

In order to add the alt text to the image, I needed to update my posting interface. By default it’s a little textarea, followed by a file upload input, followed by a toggle (a checkbox under the hood) to choose whether or not to syndicate the note to Twitter.

The interface now updates automatically as soon as I use that input type="file" to choose any images for the note. Using the FileReader API, I show a preview of the selected images right after the file input.

Here’s the code if you ever need to do something similar. I’ve abstracted it somewhat in that gist—you should be able to drop it into any page that includes input type="file" accept="image/*" and it will automatically generate the previews.

I was pleasantly surprised at how easy this was. The FileReader API worked just as expected without any gotchas. I think I always assumed that this would be quite complex to do because once upon a time, it was quite complex (or impossible) to do. But now it’s wonderfully straightforward. Story of the web.

My own version of the script does a little bit more; it also generates another little textarea right after each image preview, which is where I write the accompanying alt text.

I’ve also updated my server-side script that handles the syndication to Twitter. I’m using the /media/metadata/create method to provide the alt text. But for some reason it’s not working. I can’t figure out why. I’ll keep working on it.

In the meantime, if you’re looking at an image I’ve posted on Twitter and you’re judging me for its lack of alt text, my apologies. But each tweet of mine includes a link back to the original note on this site and you will most definitely find the alt text for the image there.

Agile design principles

I may have mentioned this before, but I’m a bit of a nerd for design principles. Have I shown you my equivalent of an interesting rock collection lately?

If you think about design principles for any period of time, it inevitably gets very meta very quickly. You start thinking about what makes for good design principles. In other words, you start wondering if there are design principles for design principles.

I’ve written before about how I think good design principles should encode some level of prioritisation. The classic example is the HTML design principle called the priority of consitituencies:

In case of conflict, consider users over authors over implementors over specifiers over theoretical purity.

It’s wonderfully practical!

I realised recently that there’s another set of design princples that put prioritisation front and centre—the Agile manifesto:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

And there’s this excellent explanation which could just as well apply to the priorty of constituencies:

That is, while there is value in the items on the right, we value the items on the left more.

Yes! That’s the spirit!

Ironically, the Agile manifesto also contains a section called principles behind the Agile manifesto which are …less good (at least they’re less good as design principles—they’re fine as hypotheses to be tested).

Agile is far from perfect. See, for example, Miriam Posner’s piece Agile and the Long Crisis of Software. But where Agile isn’t fulfilling its promise, I’d say it’s not because of its four design principles. If anything, I think the problems arise from organisations attempting to implement Agile without truly internalising the four principles.

Oh, and that’s another thing I like about the Agile manifesto as a set of design principles—the list of prioritised principles is mercifully short. Just four lines.

Bugblogging

A while back I wrote a blog post called Web Audio API weirdness on iOS. I described a bug in Mobile Safari along with a hacky fix. I finished by saying:

If you ever find yourself getting weird but inconsistent behaviour on iOS using the Web Audio API, this nasty little hack could help.

Recently Jonathan Aldrich posted a thread about the same bug. He included a link to my blog post. He also said:

Thanks so much for your post, this was a truly pernicious problem!

That warms the cockles of my heart. It’s very gratifying to know that documenting the bug (and the fix) helped someone out. Or, as I put it:

Yay for bugblogging!

Forgive the Germanic compound word, but in this case I think it fits.

Bugblogging doesn’t need to involve a solution. Just documenting a bug is a good thing to do. Recently I documented a bug with progressive web apps on iOS. Before that I documented a bug in Facebook Container for Firefox. When I documented some weird behaviour with the Web Share API in Safari on iOS, I wasn’t even sure it was a bug but Tess was pretty sure it was and filed a proper bug report.

I’ve benefited from other people bugblogging. Phil Nash wrote Service workers: beware Safari’s range request. That was exactly what I needed to solve a problem I’d been having. And then that post about Phil solving my problem helped Peter Rukavina solve a similar issue so he wrote Phil Nash and Jeremy Keith Save the Safari Video Playback Day.

Again, this warmed the cockles of my heart. Bugblogging is worth doing just for the reward of that feeling.

There’s a similar kind of blog post where, instead of writing about a bug, you write about a particular technique. In one way, this is the opposite of bugblogging because you’re writing about things working exactly as they should. But these posts have a similar feeling to bugblogging because they also result in a warm glow when someone finds them useful.

Here are some recent examples of these kinds of posts—tipblogging?—that I’ve found useful:

All three are very handy tips. Thanks, Eric! Thanks, Rich! Thanks, Stephanie!

Suspicion

I’ve already had some thoughtful responses to yesterday’s post about trust. I wrapped up my thoughts with a request:

I would love it if someone could explain why they avoid native browser features but use third-party code.

Chris obliged:

I can’t speak for the industry, but I have a guess. Third-party code (like the referenced Bootstrap and React) have a history of smoothing over significant cross-browser issues and providing better-than-browser ergonomic APIs. jQuery was created to smooth over cross-browser JavaScript problems. That’s trust.

Very true! jQuery is the canonical example of a library smoothing over the bumpy landscape of browser compatibilities. But jQuery is also the canonical example of a library we no longer need because the browsers have caught up …and those browsers support standards directly influenced by jQuery. That’s a library success story!

Charles Harries takes on my question in his post Libraries over browser features:

I think this perspective of trust has been hammered into developers over the past maybe like 5 years of JavaScript development based almost exclusively on inequality of browser feature support. Things are looking good in 2022; but as recently as 2019, 4 of the 5 top web developer needs had to do with browser compatibility.

Browser compatibility is one of the underlying promises that libraries—especially the big ones that Jeremy references, like React and Bootstrap—make to developers.

So again, it’s browser incompatibilities that made libraries attractive.

Jim Nielsen responds with the same message in his post Trusting Browsers:

We distrust the browser because we’ve been trained to. Years of fighting browser deficiencies where libraries filled the gaps. Browser enemy; library friend.

For example: jQuery did wonders to normalize working across browsers. Write code once, run it in any browser — confidently.

Three for three. My question has been answered: people gravitated towards libraries because browsers had inconsistent implementations.

I’m deliberately using the past tense there. I think Jim is onto something when he says that we’ve been trained not to trust browsers to have parity when it comes to supporting standards. But that has changed.

Charles again:

This approach isn’t a sustainable practice, and I’m trying to do as little of it as I can. Jeremy is right to be suspicious of third-party code. Cross-browser compatibility has gotten a lot better, and campaigns like Interop 2022 are doing a lot to reduce the burden. It’s getting better, but the exasperated I-just-want-it-to-work mindset is tough to uninstall.

I agree. Inertia is a powerful force. No matter how good cross-browser compatibility gets, it’s going to take a long time for developers to shed their suspicion.

Jim is glass-half-full kind of guy:

I’m optimistic that trust in browser-native features and APIs is being restored.

He also points to a very sensible mindset when it comes to third-party libraries and frameworks:

In this sense, third-party code and abstractions can be wonderful polyfills for the web platform. The idea being that the default posture should be: leverage as much of the web platform as possible, then where there are gaps to creating great user experiences, fill them in with exploratory library or framework features (features which, conceivably, could one day become native in browsers).

Yes! A kind of progressive enhancement approach to using third-party code makes a lot of sense. I’ve always maintained that you should treat libraries and frameworks like cattle, not pets. Don’t get too attached. If the library is solving a genuine need, it will be replaced by stable web standards in browsers (again, see jQuery).

I think that third-party libraries and frameworks work best as polyfills. But the whole point of polyfills is that you only use them when the browsers don’t supply features natively (and you also go back and remove the polyfill later when browsers do support the feature). But that’s not how people are using libraries and frameworks today. Developers are reaching for them by default instead of treating them as a last resort.

I like Jim’s proposed design princple:

Where available, default to browser-native features over third party code, abstractions, or idioms.

(P.S. It’s kind of lovely to see this kind of thoughtful blog-to-blog conversation happening. Right at a time when Twitter is about to go down the tubes, this is a demonstration of an actual public square with more nuanced discussion. Make your own website and join the conversation!)

Trust

I’ve noticed a strange mindset amongst front-end/full-stack developers. At least it seems strange to me. But maybe I’m the one with the strange mindset and everyone else knows something I don’t.

It’s to do with trust and suspicion.

I’ve made no secret of the fact that I’m suspicious of third-party code and dependencies in general. Every dependency you add to a project is one more potential single point of failure. You have to trust that the strangers who wrote that code knew what they were doing. I’m still somewhat flabbergasted that developers regularly add dependencies—via npm or yarn or whatever—that then pull in even more dependencies, all while assuming good faith and competence on the part of every person involved.

It’s a touching expression of faith in your fellow humans, but I’m not keen on the idea of faith-based development.

I’m much more trusting of native browser features—HTML elements, CSS features, and JavaScript APIs. They’re not always perfect, but a lot of thought goes into their development. By the time they land in browsers, a whole lot of smart people have kicked the tyres and considered many different angles. As a bonus, I don’t need to install them. Even better, end users don’t need to install them.

And yet, the mindset I’ve noticed is that many developers are suspicious of browser features but trusting of third-party libraries.

When I write and talk about using service workers, I often come across scepticism from developers about writing the service worker code. “Is there a library I can use?” they ask. “Well, yes” I reply, “but then you’ve got to understand the library, and the time it takes you to do that could be spent understanding the native code.” So even though a library might not offer any new functionality—just a different idion—many developers are more likely to trust the third-party library than they are to trust the underlying code that the third-party library is abstracting!

Developers are more likely to trust, say, Bootstrap than they are to trust CSS grid or custom properties. Developers are more likely to trust React than they are to trust web components.

On the one hand, I get it. Bootstrap and React are very popular. That popularity speaks volumes. If lots of people use a technology, it must be a safe bet, right?

But if we’re talking about popularity, every single browser today ships with support for features like grid, custom properties, service workers and web components. No third-party framework can even come close to that install base.

And the fact that these technologies have shipped in stable browsers means they’re vetted. They’ve been through a rigourous testing phase. They’ve effectively got a seal of approval from each individual browser maker. To me, that seems like a much bigger signal of trustworthiness than the popularity of a third-party library or framework.

So I’m kind of confused by this prevalent mindset of trusting third-party code more than built-in browser features.

Is it because of the job market? When recruiters are looking for developers, their laundry list is usually third-party technologies: React, Vue, Bootstrap, etc. It’s rare to find a job ad that lists native browser technologies: flexbox, grid, service workers, web components.

I would love it if someone could explain why they avoid native browser features but use third-party code.

Until then, I shall remain perplexed.

TEDxBrighton 2022

I went to TEDxBrighton on Friday. I didn’t actually realise it was happening until just a couple of days beforehand, but I once I knew, I figured I should take advantage of it being right here in my own town.

All in all, it was a terrific day. The MCing by Adam Pearson was great—just the right mix of enthusiasm and tongue-in-cheek humour. The curation of the line-up worked well too. The day was broken up into four loosely-themed sections. As I’m currently in the process of curating an event myself, I can appreciate how challenging it is.

Each section opened with a musical act. Again, having been involved behind the scenes with many events myself, I was impressed by the audaciousness, just from a logistical perspective. It all went relatively smoothly.

The talks at a TED or TEDx event can be a mixed bag. You can have a scientist on stage distilling years of research into a succint message followed by someone talking nonsense about some pseudo-psychological self-help scheme. But at TEDxBrighton, we lucked out.

A highlight for me was Dr James Mannion talking about implementation science—something that felt directly applicable to design work. Victoria Jenkins was also terrific, and again, her points about inclusive design felt very relevant. And of course I really enjoyed the space-based talks by Melissa Thorpe and Bianca Cefalo. Now that I think about it, just about everyone was great: Katie Vincent, Lewis Wedlock, Dina Nayeri—they all wowed me.

With one exception. There was a talk that was supposed to be about the future of democracy. In reality it quickly veered into DAOs before descending into a pitch for crypto and NFTs. The call to action was literally for everyone in the audience to go out and get a crypto wallet and buy an NFT …using ethereum no less! We were exhorted to use an unbelievably wasteful and energy-intensive proof-of-work technology to get our hands on a receipt for a JPG …from the same stage that would later highlight the work of climate activists like Tommie Eaton. It was really quite disgusting. The fear-based message of the talk was literally about getting in on the scheme before it’s too late. At one point we were told to “do the research.” I’m surprised we weren’t all told that we’re “not going to make it.”

A disgraceful shill for a ponzi scheme would’ve ruined any other event. Fortunately the line-up at TEDxBrighton was so strong that one scam artist couldn’t torpedo the day. Just like crypto itself—and associated bollocks like NFTs and web3—it was infuriating to have to sit through it in the short term, but then it just faded away into insignificance. One desperate peddler of snake oil couldn’t make a dent in an otherwise great day.

When should there be a declarative version of a JavaScript API?

I feel like it’s high time I revived some interest in my proposal for button type="share". Last I left it, I was gathering use cases and they seem to suggest that the most common use case for the Web Share API is sharing the URL of the current page.

If you want to catch up on the history of this proposal, here’s what I’ve previously written:

Remember, my proposal isn’t to replace the JavaScript API, it’s to complement it with a declarative option. The declarative option doesn’t need to be as fully featured as the JavaScript API, but it should be able to cover the majority use case. I think this should hold true of most APIs.

A good example is the Constraint Validation API. For the most common use cases, the required attribute and input types like “email”, “url”, and “number” have you covered. If you need more power, reach for the JavaScript API.

A bad example is the Geolocation API. The most common use case is getting the user’s current location. But there’s no input type="geolocation" (or button type="geolocation"). Your only choice is to use JavaScript. It feels heavy-handed.

I recently got an email from Taylor Hunt who has come up with a good litmus test for JavaScript APIs that should have a complementary declarative option:

I’ve been thinking about how a lot of recently-proposed APIs end up having to deal with what Chrome devrel’s been calling the “user gesture/activation budget”, and wondering if that’s a good indicator of when something should have been HTML in the first place.

I think he’s onto something here!

Think about any API that requires a user gesture. Often the documentation or demo literally shows you how to generate a button in JavaScript in order to add an event handler to it in order to use the API. Surely that’s an indication that a new button type could be minted?

The Web Share API is a classic example. You can’t invoke the API after an event like the page loading. You have to invoke the API after a user-initiated event like, oh, I don’t know …clicking on a button!

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. I should probably whip up a polyfill to demonstrate this.

I can’t find a list of all the JavaScript APIs that require a user gesture, but I know there’s more that I’m just not thinking of. I’d love to see if they’d all fit this pattern of being candidates for a new button type value.

The only potential flaw in this thinking is that some APIs that require a user gesture might also require a secure context (either being served over HTTPS or localhost). But as far as I know, HTML has never had the concept of features being restricted by context. An element is either supported or it isn’t.

That said, there is some prior art here. If you use input type="password" in a non-secure context—like a page being served over HTTP—the browser updates the interface to provide scary warnings. Perhaps browsers could do something similar for any new button types that complement secure-context JavaScript APIs.

A bug with progressive web apps on iOS

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:

  1. Navigate to thesession.org in Safari on an iOS device.
  2. Add the site to your home screen.
  3. Open the installed site from your home screen—it will launch in standalone mode.
  4. Log in with your username and password.
  5. Using the site menu, navigate to the links section of the site.
  6. Click on any external link.
  7. After the external link opens in a web view, tap on “Done” to close the web view.

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!

Media queries with display-mode

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!

2021 in numbers

I posted to adactio.com 968 times in 2021. sparkline

That’s considerably less than 2020 or 2019. Not sure why.

March was the busiest month with 118 posts. sparkline

I published:

Those notes include 170 photos sparkline and 162 replies. sparkline

Elsewhere in 2021 I published two seasons of the Clearleft podcast (12 episodes), and I wrote the 15 modules that comprise a course on responsive design on web.dev.

Most of my speaking engagements in 2021 were online though I did manage a little bit of travel in between COVID waves.

My travel map for the year includes one transatlantic trip: Christmas in Arizona, where I’m writing this end-of-year wrap-up before getting back on a plane to England tomorrow, Omicron willing.

Books I read in 2021

I read 26 books in 2021, which is a bit more than I read in 2020. That said, some of them were brief books. I don’t think I actually read any more than my usual annual allotment of words.

I’m glad that I’m tracking my reading here on my own site. About halfway through the year I thought that I was doing a pretty good job of reading a mix of books from men and women, but a glance at my reading list showed that wasn’t the case at all and I was able to adjust my intake accordingly. I wasn’t doing as badly as some but by just keeping an ongoing reading list is a handy to spot any worrying trends.

I continued my practice of alternating between fiction and non-fiction. It’s working for me.

Now that the year is at an end, I’m going to my traditional round-up and give a little review of each book. I’m also going to engage in the pointless and annoying practice of assigning a rating out of five stars for each book.

To calibrate:

  • a one-star book would be rubbish,
  • a two-star book would be perfectly fine,
  • a three-star book would be good,
  • a four-star book would be excellent, and
  • a five-star book is unheard of.

This is How You Lose the Time War by Amal El-Mohtar and Max Gladstone

★★★☆☆

I was reading this at the end of 2020 and finished it at the start of 2021. I let it wash over me, which I think is how this impressionistic and rightly short book is meant to be enjoyed. But I might just be telling myself that because I wasn’t following it closely enough.

Humankind: A Hopeful History by Rutger Bregman

★★★★☆

A terrific book about human nature. As I wrote at the time, it makes a great companion piece to—and is influenced by—Rebecca Solnit’s excellent A Paradise Built In Hell.

The only frustrating facet of Bregman’s book is that it’s also influenced by Yuval Noah Harari’s mess Sapiens. That’s probably where it gets its wrong-headed fantasy about the evils of the agricultural revolution and the glories of a pre-civilisational nomadic lifestyle. Fortunately it sounds like this pernicious myth is in for a well-earned skewering in Davids Graeber and Wengrow’s new book The Dawn of Everything

Apart from that though, Humankind is pretty darn wonderful.

The Stinging Fly Issue 43/Volume Two Winter 2020-21 — The Galway 2020 Edition edited by Lisa McInerney and Elaine Feeney

★★★☆☆

Reading this collection of stories, poems and essays was my way of travelling to Galway when a global pandemic prevented me from actually going there. The quality was consistently high and some of the stories really stayed with me.

The Moment of Eclipse by Brian Aldiss

★★☆☆☆

Another pulp paperback of short stories from Brian Aldiss. I wrote about reading this book.

Sustainable Web Design by Tom Greenwood

★★★☆☆

Reading a title from A Book Apart almost feels like a cheat—the books are laser-focused into a perfectly brief length. This one is no exception and the topic is one that every web designer and developer needs to be versed in.

Lagoon by Nnedi Okorafor

★★★☆☆

A thoroughly enjoyable first-contact story set in Nigeria. It’s absolutely dripping in atmosphere and features fully-formed characters that feel grounded even when in the middle of fantastical events.

Broad Band: The Untold Story of the Women Who Made the Internet by Claire L. Evans

★★★★★

Yeah, that’s right: five stars! This books is superb, the perfect mix of subject matter and style as I wrote as soon as I finished it. What a writer!

British Ice by Owen D. Pomery

★★☆☆☆

This is a bit of a cheat on my part. It’s a short graphic novel, and the story is told more through pictures than words. The story is somewhat slight but the imagary, like the landscape being described, is hauntingly sparse.

Klara and the Sun by Kazuo Ishiguro

★★★☆☆

This one divided opinion. I thought that, on the whole, the novel worked. There are moments of seeing the world through a robot’s eyes that feel truly alien. It’s not in the same league as Never Let Me Go, but it does share the same feeling of bleak inevitability. So not a feelgood book then.

It pairs nicely with Ian McEwan’s recent Machines Like Us to see how two respected mainstream authors approach a genre topic.

Invisible Women: Exposing Data Bias in a World Designed for Men by Caroline Criado Perez

★★★☆☆

Sharp and scathing, this is a thorough exposé. Sometimes it feels a little too thorough—there are a lot of data points that might have been better placed in footnotes. Then again, the whole point of this book is that the data really, really matters so I totally get why it’s presented this way.

A Memory Called Empire by Arkady Martine

★★★☆☆

Properly good human-level space opera with oodles of political intrigue. I will definitely be reading the next book in the series.

My Rock ‘n’ Roll Friend by Tracey Thorn

★★★☆☆

I really enjoyed this account of the friendship between Tracey Thorn and Lindy Morrison. I’m a huge Go-Betweens fan, but the band’s story is almost always told from the perspective of the boys, Grant and Robert. You could say that those narratives have (puts on sunglasses) …Everything But The Girl.

Anyway, this was a refreshing alternative. Writing about music is notoriously tricky, but this might be the best biography of a musician I’ve read.

Piranesi by Susanna Clarke

★★★★☆

I loved this! If I tried to give a plot synopsis, it would sound ridiculous, like someone describing their dreams. But somehow this works in a way that feels cohesive and perfectly internally consistent. Just read it—you won’t regret it.

On Writing: A Memoir of the Craft by Stephen King

★★★☆☆

I enjoy reading books about the craft of writing and this is one that I had been meaning to read for years. It didn’t disappoint. That said, I think I might have enjoyed it more as an autobiography of an American childhood than as a guide to writing. Some of the writing advice is dispensed as gospel when really, that’s just like your opinion, man.

A Brilliant Void: A Selection of Classic Irish Science Fiction edited by Jack Fennell

★★☆☆☆

A quirky collection of 19th century and early 20th century short stories. Today we’d probably classify them as fantasy more than science fiction. What was really interesting was reading the biographies of the writers. The collection has an impressive amount of stories by fascinating women. Kudos to Jack Fennell for the curation.

Let The Game Do Its Work by J.M. Berger

★★☆☆☆

An enjoyable little study of dystopian film sports (I’ve always wanted to do a movie marathon on that theme). The format of this work is interesting. It’s not a full-length book. Instead it’s like a quick exploration of the topic to see whether it should be a full-length book. Personally, I think this is enough. Frankly, I can think of plenty of full-length non-fiction books that should’ve been more like this length.

The City We Became by N. K. Jemisin

★★★☆☆

Sci-fi? Fantasy? Magical realism? This has a premise that’s tricky to pull off, but it works. That said, I think it could’ve been shorter. I enjoyed this but I’m not sure if I’ll be reading any sequels.

Factfulness: Ten Reasons We’re Wrong About The World - And Why Things Are Better Than You Think by Hans Rosling with Ola Rosling and Anna Rosling Roennlund

★★★★☆

Wonderful! A book about facts and figures with a very human soul. It can be summed up in this quote:

The world cannot be understood without numbers. And it cannot be understood with numbers alone.

Sometimes the self-effacing style of the late Hans Rosling can be a little grating, but overall this is a perfectly balanced book.

The Sunken Land Begins to Rise Again by M. John Harrison

★★★☆☆

Dripping with creepy Brexity atmosphere, this is more of a slow rising damp than a slow burn. But while the writing is terrific at the sentence level, it didn’t quite pull me in as a book. I admired it more than I enjoyed it.

The Relentless Moon by Mary Robinette Kowal

★★★☆☆

More escapist wish fulfilment in the Lady Astronaut series. These books aren’t great literature by any stretch, but I find the premise of an alternative history of the space race very appealing (like For All Mankind). This third book has a change of narrator and a change of scene: the moon.

Let It Go: My Extraordinary Story - From Refugee to Entrepreneur to Philanthropist by Dame Stephanie Shirley

★★★★☆

Absolutely brilliant! Both the book and the author, I mean. Steve Shirley is a hero of mine so it’s gratifying to find that she’s a great writer along with being a great person. Her story is by turns astonishing and heartbreaking. She conveys it all in an honest, heartfelt, but matter-of-fact manner.

I didn’t expect to find resonances in here about my own work, but it turns out that Clearleft wouldn’t have been able to become an employee-owned company without the groundwork laid down by Steve Shirley.

If you’re ever tempted to read some self-help business autobiography by some dude from Silicon Valley, don’t—read this instead.

Binti: The Night Masquerade by Nnedi Okorafor

★★★☆☆

The third in the Binti series of novellas is just as good as the previous two. This is crying out to be turned into a television show that I would most definitely watch.

Design For Safety by Eva PenzeyMoog

★★★☆☆

Another excellent addition to the canon of A Book Apart. I found myself noting down quotations that really resonated.

Parable of the Sower by Octavia E. Butler

★★★★☆

Excellent writing once again from Octavia Butler. Like Kindred, this can be harrowing at times but there’s a central core of humanity running through even the darkest moments. I’ll definitely be reading Parable of the Talents.

Responsible JavaScript by Jeremy Wagner

★★★☆☆

It will come as a surprise to absolutely no one that this book was right up my alley. I was nodding my head vigorously at many passages. While I might talk about progressive enhancement at the theoretical level, my fellow Jeremy dives deep into the practicalities. If you write JavaScript, you have to read this book.

Record of a Spaceborn Few by Becky Chambers

★★★☆☆

I wasn’t that into the first book in the Wayfarers series. I enjoyed the second one more. When it came to this third installment, I was completely won over. I was in just the right mood for it after the heaviness of Parable of the Sower. There’s not much in the way of threat, but plenty in the way of warmth. I’m also a sucker for stories of generation starships.

The Road from Castlebarnagh: Growing Up in Irish Music, A Memoir by Paddy O’Brien

★★★☆☆

An enjoyable series of vignettes told from the viewpoint of a young boy growing up in rural Ireland. I was hoping for more stories of the music, but if you’re involved in trad music in any way, this is well worth a read.


Now it’s time to choose one book of the year from the fiction stack and one book of the year from non-fiction.

In any other year I think Parable of the Sower would be the fiction winner, but this year I’m going to have to go for Piranesi.

There’s stiff competition in the non-fiction category: Humankind, Factfulness, and Let It Go are all excellent. But it’s got to be Broad Band.

Most of these books are available on Bookshop if you fancy reading any of them.

And for context, here’s:

Even more writing on web.dev

The final five are here! The course on responsive design I wrote for web.dev is now complete, just in time for Christmas. The five new modules are:

  1. Accessibility
  2. Interaction
  3. User interface patterns
  4. Media features
  5. Screen configurations

These five felt quite “big picture”, and often quite future-facing. I certainly learned a lot researching proposals for potential media features and foldable screens. That felt like a fitting way to close out the course, bookending it nicely with the history of responsive design in the introduction.

And with that, the full course is now online. Go forth and learn responsive design!

Faulty logic

I’m a fan of logical properties in CSS. As I wrote in the responsive design course on web.dev, they’re crucial for internationalisation.

Alaa Abd El-Rahim has written articles on CSS tricks about building multi-directional layouts and controlling layout in a multi-directional website. Not having to write separate stylesheets—or even separate rules—for different writing modes is great!

More than that though, I think understanding logical properties is the best way to truly understand CSS layout tools like grid and flexbox.

It’s like when you’re learning a new language. At some point your brain goes from translating from your mother tongue into the other language, and instead starts thinking in that other language. Likewise with CSS, as some point you want to stop translating “left” and “right” into “inline-start” and “inline-end” and instead start thinking in terms of inline and block dimensions.

As is so often the case with CSS, I think new features like these are easier to pick up if you’re new to the language. I had to unlearn using floats for layout and instead learn flexbox and grid. Someone learning layout from scatch can go straight to flexbox and grid without having to ditch the cognitive baggage of floats. Similarly, it’s going to take time for me to shed the baggage of directional properties and truly grok logical properties, but someone new to CSS can go straight to logical properties without passing through the directional stage.

Except we’re not quite there yet.

In order for logical properties to replace directional properties, they need to be implemented everywhere. Right now you can’t use logical properties inside a media query, for example:

@media (min-inline-size: 40em)

That wont’ work. You have to use the old-fashioned syntax:

@media (min-width: 40em)

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 then take a look at how the syntax for container queries is going to work. First you declare the axis that you want to be contained using the syntax from logical properties:

main {
  container-type: inline-size;
}

But then when you go to declare the actual container query, you have to use the corresponding directional property:

@container (min-width: 40em)

This won’t work:

@container (min-inline-size: 40em)

I kind of get why it won’t work: the syntax for container queries should match the syntax for media queries. But now the theory behind disallowing logical properties in media queries doesn’t hold up. When it comes to container queries, the physical layout of the viewport isn’t what matters.

I hope that both media queries and container queries will allow logical properties sooner rather than later. Until they fall in line, it’s impossible to make the jump fully to logical properties.

There are some other spots where logical properties haven’t been fully implemented yet, but I’m assuming that’s a matter of time. For example, in Firefox I can make a wide data table responsive by making its container side-swipeable on narrow screens:

.table-container {
  max-inline-size: 100%;
  overflow-inline: auto;
}

But overflow-inline and overflow-block aren’t supported in any other browsers. So I have to do this:

.table-container {
  max-inline-size: 100%;
  overflow-x: auto;
}

Frankly, mixing and matching logical properties with directional properties feels worse than not using logical properties at all. The inconsistency is icky. This feels old-fashioned but consistent:

.table-container {
  max-width: 100%;
  overflow-x: auto;
}

I don’t think there are any particular technical reasons why browsers haven’t implemented logical properties consistently. I suspect it’s more a matter of priorities. Fully implementing logical properties in a browser may seem like a nice-to-have bit of syntactic sugar while there are other more important web standard fish to fry.

But from the perspective of someone trying to use logical properties, the patchy rollout is frustrating.

Priority of design inputs

As you may already know, I’m a nerd for design principles. I collect them. I did a podcast episode on them. I even have a favourite design principle. It’s from the HTML design principles. The priority of constituencies:

In case of conflict, consider users over authors over implementors over specifiers over theoretical purity.

It’s all about priorities, see?

Prioritisation isn’t easy, and it gets harder the more factors come into play: user needs, business needs, technical constraints. But it’s worth investing the time to get agreement on the priority of your constituencies. And then formulate that agreement into design principles.

Jason is also a fan of the priority of constituencies. He recently wrote about applying it to design systems and came up with this:

User needs come before the needs of component consumers, which come before the needs of component developers, which come before the needs of the design system team, which come before theoretical purity.

That got me thinking about how this framing could be applied to other areas, like design.

Designers are used to juggling different needs (or constituencies); user needs, business needs, and so on. But what I’m interested in is how designers weigh up different inputs into the design process.

The obvious inputs are the insights you get from research. But even that can be divided into different categories. There’s qualitative research (talking to people) and qualitative research (sifting through numbers). Which gets higher priority?

There are other inputs too. Take best practices. If there’s a tried and tested solution to a problem, should that take priority over something new and untested? Maybe another way of phrasing it is to call it experience (whether that’s the designer’s own experience or the collective experience of the industry).

And though we might not like to acknowledge it because it doesn’t sound very scientific, gut instinct is another input into the design process. Although maybe that’s also related to experience.

Finally, how do you prioritise stakeholder wishes? What do you do if the client or the boss wants something that conflicts with user needs?

I could imagine a priority of design inputs that looks like this:

Qualitative research over quantitative research over stakeholder wishes over best practices over gut instinct.

But that could change over time. Maybe an experienced designer can put their gut instinct higher in the list, overruling best practices and stakeholder wishes …and maybe even some research insights? I don’t know.

I’ve talked before about how design principles should be reversible in a different context. The original priority of constituencies, for example, applies to HTML. But if you were to invert it, it would work for XML. Different projects have different priorities.

I could certainly imagine company cultures where stakeholder wishes take top billing. There are definitely companies that value qualitative research (data and analytics) above qualitative research (user interviews), and vice-versa.

Is a priority of design inputs something that should change from project to project? If so, maybe it would be good to hammer it out in the discovery phase so everyone’s on the same page.

Anyway, I’m just thinking out loud here. This is something I should chat more about with my colleagues to get their take.

Inertia

When I’ve spoken in the past about evaluating technology, I’ve mentioned two categories of tools for web development. I still don’t know quite what to call these categories. Internal and external? Developer-facing and user-facing?

The first category covers things like build tools, version control, transpilers, pre-processers, and linters. These are tools that live on your machine—or on the server—taking what you’ve written and transforming it into the raw materials of the web: HTML, CSS, and JavaScript.

The second category of tools are those that are made of the raw materials of the web: CSS frameworks and JavaScript libraries.

I think the criteria for evaluating these different kinds of tools should be very different.

For the first category, developer-facing tools, use whatever you want. Use whatever makes sense to you and your team. Use whatever’s effective for you.

But for the second category, user-facing tools, that attitude is harmful. If you make users download a CSS or JavaScript framework in order to benefit your workflow, then you’re making users pay a tax for your developer convenience. Instead, I firmly believe that user-facing tools should provide some direct benefit to end users.

When I’ve asked developers in the past why they’ve chosen to use a particular JavaScript framework, they’ve been able to give me plenty of good answers. But all of those answers involved the benefit to their developer workflow—efficiency, consistency, and so on. That would be absolutely fine if we were talking about the first category of tools, developer-facing tools. But those answers don’t hold up for the second category of tools, user-facing tools.

If a user-facing tool is only providing a developer benefit, is there any way to turn it into a developer-facing tool?

That’s very much the philosophy of Svelte. You can compare Svelte to other JavaScript frameworks like React and Vue but you’d be missing the most important aspect of Svelte: it is, by design, in that first category of tools—developer-facing tools:

Svelte takes a different approach from other frontend frameworks by doing as much as it can at the build step—when the code is initially compiled—rather than running client-side. In fact, if you want to get technical, Svelte isn’t really a JavaScript framework at all, as much as it is a compiler.

You install it on your machine, you write your code in Svelte, but what it spits out at the other end is HTML, CSS, and JavaScript. Unlike Vue or React, you don’t ship the library to end users.

In my opinion, this is an excellent design decision.

I know there are ways of getting React to behave more like a category one tool, but it is most definitely not the default behaviour. And default behaviour really, really matters. For React, the default behaviour is to assume all the code you write—and the tool you use to write it—will be sent over the wire to end users. For Svelte, the default behaviour is the exact opposite.

I’m sure you can find a way to get Svelte to send too much JavaScript to end users, but you’d be fighting against the grain of the tool. With React, you have to fight against the grain of the tool in order to not send too much JavaScript to end users.

But much as I love Svelte’s approach, I think it’s got its work cut out for it. It faces a formidable foe: inertia.

If you’re starting a greenfield project and you’re choosing a JavaScript framework, then Svelte is very appealing indeed. But how often do you get to start a greenfield project?

React has become so ubiquitous in the front-end development community that it’s often an unquestioned default choice for every project. It feels like enterprise software at this point. No one ever got fired for choosing React. Whether it’s appropriate or not becomes almost irrelevant. In much the same way that everyone is on Facebook because everyone is on Facebook, everyone uses React because everyone uses React.

That’s one of its biggest selling points to managers. If you’ve settled on React as your framework of choice, then hiring gets a lot easier: “If you want to work here, you need to know React.”

The same logic applies from the other side. If you’re starting out in web development, and you see that so many companies have settled on using React as their framework of choice, then it’s an absolute no-brainer: “if I want to work anywhere, I need to know React.”

This then creates a positive feedback loop. Everyone knows React because everyone is hiring React developers because everyone knows React because everyone is hiring React developers because…

At no point is there time to stop and consider if there’s a tool—like Svelte, for example—that would be less harmful for end users.

This is where I think Astro might have the edge over Svelte.

Astro has the same philosophy as Svelte. It’s a developer-facing tool by default. Have a listen to Drew’s interview with Matthew Phillips:

Astro does not add any JavaScript by default. You can add your own script tags obviously and you can do anything you can do in HTML, but by default, unlike a lot of the other component-based frameworks, we don’t actually add any JavaScript for you unless you specifically tell us to. And I think that’s one thing that we really got right early.

But crucially, unlike Svelte, Astro allows you to use the same syntax as the incumbent, React. So if you’ve learned React—because that’s what you needed to learn to get a job—you don’t have to learn a new syntax in order to use Astro.

I know you probably can’t take an existing React site and convert it to Astro with the flip of a switch, but at least there’s a clear upgrade path.

Astro reminds me of Sass. Specifically, it reminds me of the .scss syntax. You could take any CSS file, rename its file extension from .css to .scss and it was automatically a valid Sass file. You could start using Sass features incrementally. You didn’t have to rewrite all your style sheets.

Sass also has a .sass syntax. If you take a CSS file and rename it with a .sass file extension, it is not going to work. You need to rewrite all your CSS to use the .sass syntax. Some people used the .sass syntax but the overwhelming majority of people used .scss

I remember talking with Hampton about this and he confirmed the proportions. It was also the reason why one of his creations, Sass, was so popular, but another of his creations, Haml, was not, comparitively speaking—Sass is a superset of CSS but Haml is not a superset of HTML; it’s a completely different syntax.

I’m not saying that Svelte is like Haml and Astro is like Sass. But I do think that Astro has inertia on its side.

Twenty years of writing on my website

On this day twenty years ago I wrote the first entry in my online journal. In the intervening two decades I’ve written a further 2,817 entries.

I am now fifty years old, which means I’ve been blogging for two fifths of my lifetime.

My website has actually been around for longer than twenty years, but its early incarnations had no blog. That all changed when I relaunched the site on September 30th, 2001.

I wrote at the time:

I’m not quite sure what I will be saying here over the coming days, weeks, months and years.

Honestly I still feel like that.

I think it’s safe to assume an “anything goes” attitude for what I post here. Being a web developer, there’s bound to be lots of geeky, techy stuff but I also want a place where I can rant and rave about life in general.

That’s been pretty true, although I feel that maybe there’s been too much geeky stuff and not enough about everything else in my life.

I’ll try and post fairly regularly but I don’t want to make any promises I can’t keep. Hopefully, I’ll be updating the journal on a daily basis.

I made no promises but I think I’ve done a pretty good job. Many’s the blogger who has let the weeds grow over their websites as they were lured by the siren song of centralised social networks. I’m glad that I’ve managed to avoid that fate. It feels good to look back on twenty years of updates posted on my own domain.

Anyway, let’s see what happens. I hope you’ll like it.

I hope you still like it.

Here are some of my handpicked highlights from the past twenty years of blogging:

  • Hyperdrive, April 20th, 2007

    Last night in San Francisco.

  • Design doing, November 11, 2007

    The opposite of design thinking.

  • Iron Man and me, December 1st, 2008

    The story of how one of my Flickr pictures came to be used in a Hollywood movie.

  • Seams, May 12th, 2014

    There is a crack, a crack in everything. That’s how the light gets in.

  • Web! What is it good for?, May 28th, 2015

    Not absolutely nothing, but not absolutely everything either.

  • Split, April 10th, 2019

    Materials and tools; client and server; declarative and imperative; inclusion and privilege.

SafarIE

I was moaning about Safari recently. Specifically I was moaning about the ridiculous way that browser updates are tied to operating system updates.

But I felt bad bashing Safari. It felt like a pile-on. That’s because a lot of people have been venting their frustrations with Safari recently:

I think it’s good that people share their frustrations with browsers openly, although I agree with Baldur Bjarnason that’s good to avoid Kremlinology and the motivational fallacy when blogging about Apple.

It’s also not helpful to make claims like “Safari is the new Internet Explorer!” Unless, that is, you can back up the claim.

On a recent episode of the HTTP 203 podcast, Jake and Surma set out to test the claim that Safari is the new IE. They did it by examining Safari according to a number of different measurements and comparing it to the olden days of Internet Explorer. The result is a really fascinating trip down memory lane along with a very nuanced and even-handed critique of Safari.

And the verdict? Well, you’ll just to have to listen to the podcast episode.

If you’d rather read the transcript, tough luck. That’s a real shame because, like I said, it’s an excellent and measured assessment. I’d love to add it to the links section of my site, but I can’t do that in good conscience while it’s inaccessible to the Deaf community.

When I started the Clearleft podcast, it was a no-brainer to have transcripts of every episode. Not only does it make the content more widely available, but it also makes it easier for people to copy and paste choice quotes.

Still, I get it. A small plucky little operation like Google isn’t going to have the deep pockets of a massive corporation like Clearleft. But if Jake and Surma were to open up a tip jar, I’d throw some money in to get HTTP 203 transcribed (I recommend getting Tina Pham to do it—she’s great!).

I apologise for my note of sarcasm there. But I share because I care. It really is an excellent discussion; one that everyone should be able to access.

Update: the bug with that episode of the HTTP 203 podcast has been fixed. Here’s the transcript! And all future episodes will have transcripts too:

Browsers

I mentioned recently that there might be quite a difference in tone between my links and my journal here on my website:

’Sfunny, when I look back at older journal entries they’re often written out of frustration, usually when something in the dev world is bugging me. But when I look back at all the links I’ve bookmarked the vibe is much more enthusiastic, like I’m excitedly pointing at something and saying “Check this out!” I feel like sentiment analyses of those two sections of my site would yield two different results.

My journal entries have been even more specifically negative of late. I’ve been bitchin’ and moanin’ about web browsers. But at least I’m an equal-opportunities bitcher and moaner.

I wish my journal weren’t so negative, but my mithering behaviour has been been encouraged. On more than one occasion, someone I know at a browser company has taken me aside to let me know that I should blog about any complaints I might have with their browser. It sounds counterintuitive, I know. But these blog posts can give engineers some ammunition to get those issues prioritised and fixed.

So my message to you is this: 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.

Publish it on your website. You could post your gripes on Twitter but whinging on Jack’s website is just pissing in the wind. And I suspect you also might put a bit more thought into a blog post on your own site.

I know it’s a cliché to say that browser makers want to hear from developers—and I’m often cynical about it myself—but they really do want to know what we think. Share your thoughts. I’ll probably end up linking to what you write.

Updating Safari

Safari has been subjected to a lot of ire recently. Most of that ire has been aimed at the proposed changes to the navigation bar in Safari on iOS—moving it from a fixed top position to a floaty bottom position right over the content you’re trying to interact with.

Courage.

It remains to be seen whether this change will actually ship. That’s why it’s in beta—to gather all the web’s hot takes first.

But while this very visible change is dominating the discussion, invisible changes can be even more important. Or in the case of Safari, the lack of changes.

Compared to other browsers, Safari lags far behind when it comes to shipping features. I’m not necessarily talking about cutting-edge features either. These are often standards that have been out for years. This creates a gap—albeit an invisible one—between Safari and other browsers.

Jorge Arango has noticed this gap:

I use Safari as my primary browser on all my devices. I like how Safari integrates with the rest of the OS, its speed, and privacy features. But, alas, I increasingly have issues rendering websites and applications on Safari.

That’s the perspective of an end-user. Developers who have to deal with the gap in features are more, um, strident in their opinions. Perry Sun wrote For developers, Apple’s Safari is crap and outdated:

Don’t get me wrong, Safari is very good web browser, delivering fast performance and solid privacy features.

But at the same time, the lack of support for key web technologies and APIs has been both perplexing and annoying at the same time.

Alas, that post also indulges in speculation about Apple’s motives which always feels a bit too much like a conspiracy theory to me. Baldur Bjarnason has more to say on that topic in his post Kremlinology and the motivational fallacy when blogging about Apple. He also points to a good example of critiquing Safari without speculating about motives: Dave’s post One-offs and low-expectations with Safari, which documents all the annoying paper cuts inflicted by Safari’s “quirks.”

Another deep dive that avoids speculating about motives comes from Tim Perry: Safari isn’t protecting the web, it’s killing it. I don’t agree with everything in it. I think that Apple—and Mozilla’s—objections to some device APIs are informed by a real concern about privacy and security. But I agree with his point that it’s not enough to just object; you’ve got to offer an alternative vision too.

That same post has a litany of uncontroversial features that shipped in Safari looong after they shipped in other browsers:

Again: these are not contentious features shipping by only Chrome, they’re features with wide support and no clear objections, but Safari is still not shipping them until years later. They’re also not shiny irrelevant features that “bloat the web” in any sense: each example I’ve included above primarily improving core webpage UX and performance. Safari is slowing that down progress here.

But perhaps most damning of all is how Safari deals with bugs.

A recent release of Safari shipped with a really bad Local Storage bug. The bug was fixed within a day. Yay! But the fix won’t ship until …who knows?

This is because browser updates are tied to operating system updates. Yes, this is just like the 90s when Microsoft claimed that Internet Explorer was intrinsically linked to Windows (a tactic that didn’t work out too well for them in the subsequent court case).

I don’t get it. I’m pretty sure that other Apple products ship updates and fixes independentally of OS releases. I’m sure I’ve received software updates for Keynote, Garage Band, and other pieces of software made by Apple.

And yet, of all the applications that need a speedy update cycle—a user agent for the World Wide Web—Apple’s version is needlessly delayed by the release cycle of the entire operating system.

I don’t want to speculate on why this might be. I don’t know the technical details. But I suspect that the root cause might not be technical in nature. Apple have always tied their browser updates to OS releases. If Google’s cardinal sin is avoiding anything “Not Invented Here”, Apple’s downfall is “We’ve always done it this way.”

Evergreen browsers update in the background, usually at regular intervals. Firefox is an evergreen browser. Chrome is an evergreen browser. Edge is an evergreen browser.

Safari is not an evergreen browser.

That’s frustrating when it comes to new features. It’s unforgivable when it comes to bugs.

At least on Apple’s desktop computers, users have the choice to switch to a different browser. But on Apple’s mobile devices, users have no choice but to use Safari’s rendering engine, bugs and all.

As I wrote when I had to deal with one of Safari’s bugs:

I wish that Apple would allow other rendering engines to be installed on iOS devices. But if that’s a hell-freezing-over prospect, I wish that Safari updates weren’t tied to operating system updates.

A Few Notes on A Few Notes on The Culture

When I post a link, I do it for two reasons.

First of all, it’s me pointing at something and saying “Check this out!”

Secondly, it’s a way for me to stash something away that I might want to return to. I tag all my links so when I need to find one again, I just need to think “Now what would past me have tagged it with?” Then I type the appropriate URL: adactio.com/links/tags/whatever

There are some links that I return to again and again.

Back in 2008, I linked to a document called A Few Notes on The Culture. It’s a copy of a post by Iain M Banks to a newsgroup back in 1994.

Alas, that link is dead. Linkrot, innit?

But in 2013 I linked to the same document on a different domain. That link still works even though I believe it was first published around twenty(!) years ago (view source for some pre-CSS markup nostalgia).

Anyway, A Few Notes On The Culture is a fascinating look at the world-building of Iain M Banks’s Culture novels. He talks about the in-world engineering, education, biology, and belief system of his imagined utopia. The part that sticks in my mind is when he talks about economics:

Let me state here a personal conviction that appears, right now, to be profoundly unfashionable; which is that a planned economy can be more productive - and more morally desirable - than one left to market forces.

The market is a good example of evolution in action; the try-everything-and-see-what-works approach. This might provide a perfectly morally satisfactory resource-management system so long as there was absolutely no question of any sentient creature ever being treated purely as one of those resources. The market, for all its (profoundly inelegant) complexities, remains a crude and essentially blind system, and is — without the sort of drastic amendments liable to cripple the economic efficacy which is its greatest claimed asset — intrinsically incapable of distinguishing between simple non-use of matter resulting from processal superfluity and the acute, prolonged and wide-spread suffering of conscious beings.

It is, arguably, in the elevation of this profoundly mechanistic (and in that sense perversely innocent) system to a position above all other moral, philosophical and political values and considerations that humankind displays most convincingly both its present intellectual immaturity and — through grossly pursued selfishness rather than the applied hatred of others — a kind of synthetic evil.

Those three paragraphs might be the most succinct critique of unfettered capitalism I’ve come across. The invisible hand as a paperclip maximiser.

Like I said, it’s a fascinating document. In fact I realised that I should probably store a copy of it for myself.

I have a section of my site called “extras” where I dump miscellaneous stuff. Most of it is unlinked. It’s mostly for my own benefit. That’s where I’ve put my copy of A Few Notes On The Culture.

Here’s a funny thing …for all the times that I’ve revisited the link, I never knew anything about the site is was hosted on—vavatch.co.uk—so this most recent time, I did a bit of clicking around. Clearly it’s the personal website of a sci-fi-loving college student from the early 2000s. But what came as a revelation to me was that the site belonged to …Adrian Hon!

I’m impressed that he kept his old website up even after moving over to the domain mssv.net, founding Six To Start, and writing A History Of The Future In 100 Objects. That’s a great snackable book, by the way. Well worth a read.