Tags: medium

663

sparkline

Thursday, January 20th, 2022

Screenshots

I wrote about how I created a page on The Session with instructions for installing the site to your home screen. When I said that I included screenshots on that page, I may have underplayed the effort involved. It was real faff.

I’ve got an iPhone so generating screenshots (and video) from that wasn’t too bad. But I don’t have access to an Android phone. I found myself scouring the web for templates that I could use to mockup a screenshot of the address bar.

That got me thinking…

Wouldn’t it be cool if there were a service that generated those screenshots for you? You give it a URL, and it spits out screenshots of the site complete with overlays showing the installation flow on Android and iOS. It could even generate the img markup, complete with differently-scaled images for the srcset attribute.

Download the images. Copy that markup. Paste it into a page on your site. Boom! Now you’ve got somewhere to point your visitors to if you’d like them to install your progressive web app.

There are already some services out there for generating screenshots of mobile phones but they’re missing is the menu overlays for adding to home screen.

The devrels at both Google and Microsoft have been doing a great job of promoting progressive web apps. They’ve built tools to help you with tasks like generating icons or creating your web app manifest. It would be sooooo nifty if those tools also generated instructional screenshots for adding to home screen!

Tuesday, January 18th, 2022

Installing progressive web apps

I don’t know about you, but it seems like everyone I follow on Twitter is playing Wordle. Although I don’t play the game myself, I think it’s pretty great.

Not only does Wordle have a very sweet backstory, but it’s also unashamedly on the web. If you want to play, you go to the URL powerlanguage.co.uk/wordle. That’s it. No need to download an app.

That hasn’t stopped some nefarious developers trying to trick people into downloading their clones of Wordle from app stores. App stores, which are meant to be curated and safe, are in fact filled with dodgy knock-offs and scams. Contrary to popular belief, the web is quite literally a safer bet.

Wordle has a web app manifest, which means you can add it to your home screen and it will behave just like a native app (although I don’t believe it has offline support). That’s great, but the process of adding a web app to your home screen on iOS is ludicrously long-winded.

Macworld published an article detailing how to get the real Wordle app on your iPhone or iPad. On the one hand it’s great to see this knowledge being spread. On the other hand it’s dispiriting that it’s even necessary to tell people that they can do this, like it’s a hidden nerdy secret just for power users.

At this point I’ve pretty much given up on Apple ever doing anything about this pathetic situation. So what can I do instead?

Well, taking my cue from that Macworld article, the least I can do is inform people how they can add a progressive web app to their home screen.

That’s what I’ve done on thesession.org. I’ve published a page on how to install The Session to your home screen.

On both Android and iPhone the journey to installing a progressive web app begins with incomprehensible iconography. On Android you must first tap on the unlabeled kebab icon—three vertical dots. On iOS you must first tap on the unlabeled share icon—a square with an arrow coming out of it.

The menu icon on Android. The share icon on iOS.

When it comes to mobile operating systems, consumer choice means you choose which kind of mystery meat to eat.

I’ve included screenshots to help people identify these mysterious portals. For iOS I’ve also included a video to illustrate the quest to find the secret menu item buried beneath the share icon.

I’ve linked to the page with the installation instructions from the site’s “help” page and the home page.

Handy tip: when you’re adding a start_url value to your web app manifest, it’s common to include a query string like this:

start_url: "/?homescreen"

I’m guessing most people to that so they can get analytics on how many people are starting from an icon tap. I don’t do analytics on The Session but I’m still using that query string in my start_url. On the home page of the site, I check for the existence of the query string. If it exists, I don’t show the link to the installation page. So once someone has installed the site to their home screen, they shouldn’t see that message when they launch The Session.

If you’ve got a progressive web app, it might be worth making a page with installation instructions rather than relying on browsers to proactively inform your site’s visitors. You’d still need to figure out the right time and place to point people to that page, but at least the design challenge would be in your hands.

Should you decide to take a leaf out of the Android and iOS playbooks and use mystery meat navigation to link to such a page, there’s an emoji you could potentially use: 📲

It’s still worse than using actual words, but it might be better than some random combination of dots, squares and arrows.

(I’m not really serious about using that emoji, but if you do, be sure to use a sensible aria-label value on the enclosing a element.)

Thursday, January 13th, 2022

Partnering with Google on web.dev

When the web.dev team at Google contacted Clearleft about writing a course on responsive design, our eyes lit up.

This was clearly a good fit. For one thing, Clearleft has been pioneering responsive design from day one—we helped launch some of the first responsive sites in the UK. But there was another reason why this partnership sounded good: we had the same approach to writing and sharing.

Ever since Clearleft was founded in 2005 we’ve taken on board the motto of the World Wide Web itself: let’s share what we know. As well as doing the work, we enjoy sharing how the work gets done. Whether it’s case studies, blog posts, podcasts, or conference talks, we’re always thinking about ways to contribute to the web community.

Many other great resources have contributed to our collective knowledge: A List Apart, CSS Tricks, Smashing Magazine, Mozilla Developer Network, and more recently web.dev, which has become an excellent resource for front-end developers. But they wanted to make sure that designers were also included. Una described her plan for a fifteen-part course on modern responsive design aimed at web designers.

It was ambitious. The plan included some cutting edge technology that’s just shipping in browsers now. It sounded daunting and exciting in equal measure. Mostly it sounded like far too good an opportunity for Clearleft to pass up so we jumped on it.

With my fellow Clearlefties otherwise engaged in client work, it fell to me to tap out the actual words. Fortunately I’ve had plenty of experience with my own website of moving my fingers up and down on a keyboard in attempt to get concepts out of my head and onto the screen. I familiarised myself with the house style and got to work.

I had lots of help from the Chrome developer relations team at Google. Project management (thanks, Terry!), technical editing (thanks, Adam!), and copy editing (thanks, Rachel!) were provided to me.

Working with Rachel again was a real treat—she wrote the second edition of my book, HTML5 For Web Designers. Every time she suggested a change to something I had written, I found myself slapping my forehead and saying “Of course! That’s so much better!” It felt great to have someone else be a content buddy for me.

We had a weekly video call to check in and make sure everything was on track. There was also an epic spreadsheet to track the flow of each module as they progressed from outline to first draft to second draft.

Those were just the stages when the words were in a Google doc. After that, the content moved to Github and there was a whole other process to shepherd it towards going live.

Take note of the license in that repo: Creative Commons Attribution 3.0. That means that you—or anyone—is free to use and reuse all the material (as long as you include a credit). I think I might republish the fifteen articles on my site at some point.

If you’d like to peruse the outcome of this collaboration between Clearleft and Google, head on over to web.dev and learn responsive design. Then feel free to share it!

  1. Introduction
  2. Media queries
  3. Internationalization
  4. Macro layouts
  5. Micro layouts
  6. Typography
  7. Responsive images
  8. The picture element
  9. Icons
  10. Theming
  11. Accessibility
  12. Interaction
  13. User interface patterns
  14. Media features
  15. Screen configurations

Wednesday, January 12th, 2022

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!

Thursday, January 6th, 2022

Today, the distant future

It’s a bit of a cliché to talk about living in the future. It’s also a bit pointless. After all, any moment after the big bang is a future when viewed from any point in time before it.

Still, it’s kind of fun when a sci-fi date rolls around. Like in 2015 when we reached the time depicted in Back To The Future 2, or in 2019 when we reached the time of Blade Runner.

In 2022 we are living in the future of web standards. Again, technically, we’re always living in the future of any past discussion of web standards, but this year is significant …in a very insignificant way.

It all goes back to 2008 and an interview with Hixie, editor of the HTML5 spec at the WHATWG at the time. In it, he mentioned the date 2022 as the milestone for having two completely interoperable implementations.

The far more important—and ambitious—date was 2012, when HTML5 was supposed to become a Candidate Recommendation, which is standards-speak for done’n’dusted.

But the mere mention of the year 2022 back in the year 2008 was too much for some people. Jeff Croft, for example, completely lost his shit (Jeff had a habit of posting angry rants and then denying that he was angry or ranty, but merely having a bit of fun).

The whole thing was a big misunderstanding and soon irrelevant: talk of 2022 was dropped from HTML5 discussions. But for a while there, it was fascinating to see web designers and developers contemplate a year that seemed ludicriously futuristic. Jeff wrote:

God knows where I’ll be in 13 years. Quite frankly, I’ll be pretty fucking disappointed in myself (and our entire industry) if I’m writing HTML in 13 years.

That always struck me as odd. If I thought like that, I’d wonder what the point would be in making anything on the web to begin with (bear in mind that both my own personal website and The Session are now entering their third decade of life).

I had a different reaction to Jeff, as I wrote in 2010:

Many web developers were disgusted that such a seemingly far-off date was even being mentioned. My reaction was the opposite. I began to pay attention to HTML5.

But Jeff was far from alone. Scott Gilbertson wrote an angry article on Webmonkey:

If you’re thinking that planning how the web will look and work 13 years from now is a little bit ridiculous, you’re not alone.

Even if your 2022 ronc-o-matic web-enabled toaster (It slices! It dices! It browses! It arouses!) does ship with Firefox v22.3, will HTML still be the dominant language of web? Given that no one can really answer that question, does it make sense to propose a standard so far in the future?

(I’m re-reading that article in the current version of Firefox: 95.0.2.)

Brian Veloso wrote on his site:

Two-thousand-twenty-two. That’s 14 years from now. Can any of us think that far? Wouldn’t our robot overlords, whether you welcome them or not, have taken over by then? Will the internet even matter then?

From the comments on Jeff’s post, there’s Corey Dutson:

2022: God knows what the Internet will look like at that point. Will we even have websites?

Dan Rubin, who has indeed successfully moved from web work to photography, wrote:

I certainly don’t intend to be doing “web work” by that time. I’m very curious to see where the web actually is in 14 years, though I can’t imagine that HTML5 will even get that far; it’ll all be obsolete before 2022.

Joshua Works made a prediction that’s worryingly close to reality:

I’ll be surprised if website-as-HTML is still the preferred method for moving around the tons of data we create, especially in the manner that could have been predicted in 2003 or even today. Hell, iPods will be over 20 years old by then and if everything’s not run as an iPhone App, then something went wrong.

Someone with the moniker Grand Caveman wrote:

In 2022 I’ll be 34, and hopefully the internet will be obsolete by then.

Perhaps the most level-headed observation came from Jonny Axelsson:

The world in 2022 will be pretty much like the world in 2009.

The world in 2009 is pretty much like 1996 which was pretty much like the world in 1983 which was pretty much like the world in 1970. Some changes are fairly sudden, others are slow, some are dramatic, others subtle, but as a whole “pretty much the same” covers it.

The Web in 2022 will not be dramatically different from the Web in 2009. It will be less hot and it will be less cool. The Web is a project, and as it succeeds it will fade out of our attention and into the background. We don’t care about things when they work.

Now that’s a sensible perspective!

So who else is looking forward to seeing what the World Wide Web is like in 2036?

I must remember to write a blog post then and link back to this one. I have no intention of trying to predict the future, but I’m willing to bet that hyperlinks will still be around in 14 years.

Speaking of long bets…

Monday, January 3rd, 2022

2021

2020 was the year of the virus. 2021 was the year of the vaccine …and the virus, obviously, but still it felt like the year we fought back. With science!

Whenever someone writes and shares one of these year-end retrospectives the result is, by its very nature, personal. These last two years are different though. We all still have our own personal perspectives, but we also all share a collective experience of The Ongoing Situation.

Like, I can point to three pivotal events in 2021 and I bet you could point to the same three for you:

  1. getting my first vaccine shot in March,
  2. getting my second vaccine shot in June, and
  3. getting my booster shot in December.

So while on the one hand we’re entering 2022 in a depressingly similar way to how we entered 2021 with COVID-19 running rampant, on the other hand, the odds have changed. We can calculate risk. We’ve got more information. And most of all, we’ve got these fantastic vaccines.

I summed up last year in terms of all the things I didn’t do. I could do the same for 2021, but there’s only one important thing that didn’t happen—I didn’t catch a novel coronavirus.

It’s not like I didn’t take some risks. While I was mostly a homebody, I did make excursions to Zürich and Lisbon. One long weekend in London was particurly risky.

At the end of the year, right as The Omicron Variant was ramping up, Jessica and I travelled to Ireland to see my mother, and then travelled to the States to see her family. We managed to dodge the Covid bullets both times, for which I am extremely grateful. My greatest fear throughout The Situation hasn’t been so much about catching Covid myself, but passing it on to others. If I were to give it to a family member or someone more vulnerable than me, I don’t think I could forgive myself.

Now that we’ve seen our families (after a two-year break!), I’m feeling more sanguine about this next stage. I’ll be hunkering down for the next while to ride out this wave, but if I still end up getting infected, at least I won’t have any travel plans to cancel.

But this is meant to be a look back at the year that’s just finished, not a battle plan for 2022.

There were some milestones in 2021:

  1. I turned 50,
  2. TheSession.org turned 20, and
  3. Adactio.com also turned 20.

This means that my websites are 2/5ths of my own age. In ten years time, my websites will be 1/2 of my own age.

Most of my work activities were necessarily online, though I did manage the aforementioned trips to Switzerland and Portugal to speak at honest-to-goodness real live in-person events. The major projects were:

  1. Publishing season two of the Clearleft podcast in February,
  2. Speaking at An Event Apart Online in April,
  3. Hosting UX Fest in June,
  4. Publishing season three of the Clearleft podcast in September, and
  5. Writing a course on responsive design in November.

Outside of work, my highlights of 2021 mostly involved getting to play music with other people—something that didn’t happen much in 2020. Band practice with Salter Cane resumed in late 2021, as did some Irish music sessions. Both are now under an Omicron hiatus but this too shall pass.

Another 2021 highlight was a visit by Tantek in the summer. He was willing to undergo quarantine to get to Brighton, which I really appreciate. It was lovely hanging out with him, even if all our social activities were by necessity outdoors.

But, like I said, the main achievement in 2021 was not catching COVID-19, and more importantly, not passing it on to anyone else. Time will tell whether or not that winning streak will be sustainable in 2022. But at least I feel somewhat prepared for it now, thanks to those magnificent vaccines.

2021 was a shitty year for a lot of people. I feel fortunate that for me, it was merely uneventful. If my only complaint is that I didn’t get to travel and speak as much I’d like, well boo-fucking-hoo, I’ll take it. I’ve got my health. My family members have their health. I don’t take that for granted.

Maybe 2022 will turn out to be similar—shitty for a lot of people, and mostly unenventful for me. Or perhaps 2022 will be a year filled with joyful in-person activities, like conferences and musical gatherings. Either way, I’m ready.

Thursday, December 30th, 2021

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:

Thursday, December 23rd, 2021

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!

Saturday, December 11th, 2021

More writing on web.dev

Last month I wrote about writing on web.dev. At that time, the first five parts of a fourteen-part course on responsive design had been published. I’m pleased to say that the next five parts are now available. They are:

  1. Typography
  2. Responsive images
  3. The picture element
  4. Icons
  5. Theming

It wasn’t planned, but these five modules feel like they belong together. The first five modules were concerned with layout tools—media queries, flexbox, grid, and even container queries. The latest five modules are about the individual elements of design—type, colour, and images. But those elements are examined through the lens of responsiveness; responsive typography with clamp, responsive colour with prefers-color-scheme, and responsive images with picture and srcset.

The final five modules should be available later this month. In the mean time, I hope you like the first ten modules.

Thursday, December 9th, 2021

Ain’t no party like a third party

This was originally published on CSS Tricks in December 2021 as part of a year-end round-up of responses to the question “What is one thing people can do to make their website bettter?”

I’d like to tell you something not to do to make your website better. Don’t add any third-party scripts to your site.

That may sound extreme, but at one time it would’ve been common sense. On today’s modern web it sounds like advice from a tinfoil-hat wearing conspiracy nut. But just because I’m paranoid doesn’t mean they’re not out to get your user’s data.

All I’m asking is that we treat third-party scripts like third-party cookies. They were a mistake.

Browsers are now beginning to block third-party cookies. Chrome is dragging its heels because the same company that makes the browser also runs an advertising business. But even they can’t resist the tide. Third-party cookies are used almost exclusively for tracking. That was never the plan.

In the beginning, there was no state on the web. A client requested a resource from a server. The server responded. Then they both promptly forgot about it. That made it hard to build shopping carts or log-ins. That’s why we got cookies.

In hindsight, cookies should’ve been limited to a same-origin policy from day one. That would’ve solved the problems of authentication and commerce without opening up a huge security hole that has been exploited to track people as they moved from one website to another. The web went from having no state to having too much.

Now that vulnerability is finally being closed. But only for cookies. I would love it if third-party JavaScript got the same treatment.

When you add any third-party file to your website—an image, a style sheet, a font—it’s a potential vector for tracking. But third-party JavaScript files go one further. They can execute arbitrary code.

Just take a minute to consider the implications of that: any third-party script on your site is allowing someone else to execute code on your web pages. That’s astonishingly unsafe.

It gets better. One of the pieces of code that this invited intruder can execute is the ability to pull in other third-party scripts.

You might think there’s no harm in adding that one little analytics script. Or that one little Google Tag Manager snippet. It’s such a small piece of code, after all. But in doing that, you’ve handed over your keys to a stranger. And now they’re welcoming in all their shady acquaintances.

Request Map Generator is a great tool for visualizing the resources being loaded on any web page. Try pasting in the URL of an interesting article from a news outlet or magazine that someone sent you recently. Then marvel at the sheer size and number of third-party scripts that sneak in via one tiny script element on the original page.

That’s why I recommend that the one thing people can do to make their website better is to not add third-party scripts.

Easier said than done, right? Especially if you’re working on a site that currently relies on third-party tracking for its business model. But that exploitative business model won’t change unless people like us are willing to engage in a campaign of passive resistance.

I know, I know. If you refuse to add that third-party script, your boss will probably say, “Fine, I’ll get someone else to do it. Also, you’re fired.”

This tactic will only work if everyone agrees to do what’s right. We need to have one another’s backs. We need to support one another. The way people support one another in the workplace is through a union.

So I think I’d like to change my answer to the question that’s been posed.

The one thing people can do to make their website better is to unionize.

Sunday, December 5th, 2021

Getting back

The three-part almost nine-hour long documentary Get Back is quite fascinating.

First of all, the fact that all this footage exists is remarkable. It’s as if Disney had announced that they’d found the footage for a film shot between Star Wars and The Empire Strikes Back.

Still, does this treasure trove really warrant the daunting length of this new Beatles documentary? As Terence puts it:

There are two problems with this Peter Jackson documentary. The first is that it is far too long - are casual fans really going to sit through 9 hours of a band bickering? The second problem is that it is far too short! Beatles obsessives (like me) could happily drink in a hundred hours of this stuff.

In some ways, watching Get Back is liking watching one of those Andy Warhol art projects where he just pointed a camera at someone for 24 hours. It’s simultaneously boring and yet oddly mesmerising.

What struck myself and Jessica watching Get Back was how much it was like our experience of playing with Salter Cane. I’m not saying Salter Cane are like The Beatles. I’m saying that The Beatles are like Salter Cane and every other band on the planet when it comes to how the sausage gets made. The same kind of highs. The same kind of lows. And above all, the same kind of tedium. Spending hours and hours in a practice room or a recording studio is simultaneously exciting and dull. This documentary captures that perfectly.

I suppose Peter Jackson could’ve made a three-part fly-on-the-wall documentary series about any band and I would’ve found it equally interesting. But this is The Beatles and that means there’s a whole mythology that comes along for the ride. So, yes, it’s like watching paint dry, but on the other hand, it’s paint painted by The Beatles.

What I liked about Get Back is that it demystified the band. The revelation for me was really understanding that this was just four lads from Liverpool making music together. And I know I shouldn’t be surprised by that—the Beatles themselves spent years insisting they were just four lads from Liverpool making music together, but, y’know …it’s The Beatles!

There’s a scene in the Danny Boyle film Yesterday where the main character plays Let It Be for the first time in a world where The Beatles have never existed. It’s one of the few funny parts of the film. It’s funny because to everyone else it’s just some new song but we, the audience, know that it’s not just some new song…

Christ, this is Let It Be! You’re the first people on Earth to hear this song! This is like watching Da Vinci paint the Mona Lisa right in front of your bloody eyes!

But truth is even more amusing than fiction. In the first episode of Get Back, we get to see when Paul starts noodling on the piano playing Let It Be for the first time. It’s a momentous occasion and the reaction from everyone around him is …complete indifference. People are chatting, discussing a set design that will never get built, and generally ignoring the nascent song being played. I laughed out loud.

There’s another moment when George brings in the song he wrote the night before, I Me Mine. He plays it while John and Yoko waltz around. It’s in 3/4 time and it’s minor key. I turned to Jessica and said “That’s the most Salter Cane sounding one.” Then, I swear at that moment, after George has stopped playing that song, he plays a brief little riff on the guitar that sounded exactly like a Salter Cane song we’re working on right now. Myself and Jessica turned to each other and said, “What was that‽”

Funnily enough, when we told this to Chris, the singer in Salter Cane, he mentioned how that was the scene that had stood out to him as well, but not for that riff (he hadn’t noticed the similarity). For him, it was about how George had brought just a scrap of a song. Chris realised it was the kind of scrap that he would come up with, but then discard, thinking there’s not enough there. So maybe there’s a lesson here about sharing those scraps.

Watching Get Back, I was trying to figure out if it was so fascinating to me and Jessica (and Chris) because we’re in a band. Would it resonate with other people?

The answer, it turns out, is yes, very much so. Everyone’s been sharing that clip of Paul coming up with the beginnings of the song Get Back. The general reaction is one of breathless wonder. But as Chris said, “How did you think songs happened?” His reaction was more like “yup, accurate.”

Inevitably, there are people mining the documentary for lessons in creativity, design, and leadership. There are already Medium think-pieces and newsletters analysing the processes on display. I guarantee you that there will be multiple conference talks at UX events over the next few years that will include footage from Get Back.

I understand how you could watch this documentary and take away the lesson that these were musical geniuses forging remarkable works of cultural importance. But that’s not what I took from it. I came away from it thinking they’re just a band who wrote and recorded some songs. Weirdly, that made me appreciate The Beatles even more. And it made me appreciate all the other bands and all the other songs out there.

Wednesday, November 24th, 2021

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.

Wednesday, November 17th, 2021

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.

Tuesday, November 16th, 2021

Tracking

I’ve been reading the excellent Design For Safety by Eva PenzeyMoog. There was a line that really stood out to me:

The idea that it’s alright to do whatever unethical thing is currently the industry norm is widespread in tech, and dangerous.

It stood out to me because I had been thinking about certain practices that are widespread, accepted, and yet strike me as deeply problematic. These practices involve tracking users.

The first problem is that even the terminology I’m using would be rejected. When you track users on your website, it’s called analytics. Or maybe it’s stats. If you track users on a large enough scale, I guess you get to just call it data.

Those words—“analytics”, “stats”, and “data”—are often used when the more accurate word would be “tracking.”

Or to put it another way; analytics, stats, data, numbers …these are all outputs. But what produced these outputs? Tracking.

Here’s a concrete example: email newsletters.

Do you have numbers on how many people opened a particular newsletter? Do you have numbers on how many people clicked a particular link?

You can call it data, or stats, or analytics, but make no mistake, that’s tracking.

Follow-on question: do you honestly think that everyone who opens a newsletter or clicks on a link in a newsletter has given their informed constent to be tracked by you?

You may well answer that this is a widespread—nay, universal—practice. Well yes, but a) that’s not what I asked, and b) see the above quote from Design For Safety.

You could quite correctly point out that this tracking is out of your hands. Your newsletter provider—probably Mailchimp—does this by default. So if the tracking is happening anyway, why not take a look at those numbers?

But that’s like saying it’s okay to eat battery-farmed chicken as long as you’re not breeding the chickens yourself.

When I try to argue against this kind of tracking from an ethical standpoint, I get a frosty reception. I might have better luck battling numbers with numbers. Increasing numbers of users are taking steps to prevent tracking. I had a plug-in installed in my mail client—Apple Mail—to prevent tracking. Now I don’t even need the plug-in. Apple have built it into the app. That should tell you something. It reminds me of when browsers had to introduce pop-up blocking.

If the outputs generated by tracking turn out to be inaccurate, then shouldn’t they lose their status?

But that line of reasoning shouldn’t even by necessary. We shouldn’t stop tracking users because it’s inaccurate. We should stop stop tracking users because it’s wrong.

Monday, November 15th, 2021

4 + 3

I work a four-day week now.

It started with the first lockdown. Actually, for a while there, I was working just two days a week while we took a “wait and see” attitude at Clearleft to see how The Situation was going to affect work. We weathered that storm, but rather than going back to a full five-day week I decided to try switching to four days instead.

This meant taking a pay cut. Time is literally money when it comes to work. But I decided it was worth it. That’s a privileged position to be in, I know. I managed to pay off the mortgage on our home last year so that reduced some financial pressure. But I also turned fifty, which made me think that I should really be padding some kind of theoretical nest egg. Still, the opportunity to reduce working hours looked good to me.

The ideal situation would be to have everyone switch to a four-day week without any reduction in pay. Some companies have done that but it wasn’t an option for Clearleft, alas.

I’m not the only one working a four-day week at Clearleft. A few people were doing it even before The Situation. We all take Friday as our non-work day, which makes for a nice long three-day weekend.

What’s really nice is that Friday has been declared a “no meeting” day for everyone at Clearleft. That means that those of us working a four-day week know we’re not missing out on anything and it’s pretty nice for people working a five-day week to have a day free of appointments. We have our end-of-week all-hands wind-down on Thursday afternoons.

I haven’t experienced any reduction in productivity. Quite the opposite. There may be a corollay to Parkinson’s Law: work contracts to fill the time available.

At one time, a six-day work week was the norm. It may well be that a four-day work week becomes the default over time. That could dovetail nicely with increasing automation.

I’ve got to say, I’m really, really liking this. It’s quite nice that when Wednesday rolls around, I can say “it’s almost the weekend!”

A three-day weekend feels normal to me now. I could imagine tilting the balance even more over time. Maybe every few years I could reduce the working by a day or half a day. So instead of going from a full-on five-day working week straight into retirement, it would be more of a gentle ratcheting down over the years.

Monday, November 8th, 2021

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.

Ten episodes of the Web History podcast

For over a year now I’ve been recording the audio versions of Jay Hoffman’s excellent Web History series on CSS Tricks.

We’re up to ten chapters now. The audio version of each chapter is between 30 and 40 minutes long. That’s around 400 minutes of my voice: a good six and a half hours of me narrating the history of the web. That’s like an audio book!

The story so far covers:

  1. Birth
  2. Browsers
  3. The Website
  4. Search
  5. Publishing
  6. Web Design
  7. Standards
  8. CSS
  9. Community
  10. Browser Wars

…with more to come.

The audio is available as a podcast. You can subscribe to the RSS feed. It’s also available from Apple and Spotify.

That’ll give you plenty to listen to while you wait for the next season of the Clearleft podcast.

Friday, November 5th, 2021

Memories of Ajax

I just finished watching The Billion Dollar Code, a German language miniseries on Netflix. It’s no Halt and Catch Fire, but it combines ’90s nostalgia, early web tech, and an opportunity for me to exercise my German comprehension.

It’s based on a true story, but with amalgamated characters. The plot, which centres around the preparation for a court case, inevitably invites comparison to The Social Network, although this time the viewpoint is from that of the underdogs trying to take on the incumbent. The incumbent is Google. The underdogs are ART+COM, artist-hackers who created the technology later used by Google Earth.

Early on, one of the characters says something about creating a one-to-one model of the whole world. That phrase struck me as familiar…

I remember being at the inaugural Future Of Web Apps conference in London back in 2006. Discussing the talks with friends afterwards, we all got a kick out of the speaker from Google, who happened to be German. His content and delivery was like a wonderfully Stranglovesque mad scientist. I’m sure I remember him saying something like “vee made a vun-to-vun model of the vurld.”

His name was Steffen Meschkat. I liveblogged the talk at the time. Turns out he was indeed on the team at ART+COM when they created Terravision, the technology later appropriated by Google (he ended up working at Google, which doesn’t make for as exciting a story as the TV show).

His 2006 talk was all about Ajax, something he was very familiar with, being on the Google Maps team. The Internet Archive even has a copy of the original audio!

It’s easy to forget now just how much hype there was around Ajax back then. It prompted me to write a book about combining Ajax and progressive enhancement.

These days, no one talks about Ajax. But that’s not because the technology went away. Quite the opposite. The technology became so ubiquituous that it no longer even needs a label.

A web developer today might ask “what’s Ajax?” in the same way that a fish might ask “what’s water?”

Thursday, November 4th, 2021

Writing on web.dev

Chrome Dev Summit kicked off yesterday. The opening keynote had its usual share of announcements.

There was quite a bit of talk about privacy, which sounds good in theory, but then we were told that Google would be partnering with “industry stakeholders.” That’s probably code for the kind of ad-tech sharks that have been making a concerted effort to infest W3C groups. Beware.

But once Una was on-screen, the topics shifted to the kind of design and development updates that don’t have sinister overtones.

My favourite moment was when Una said:

We’re also partnering with Jeremy Keith of Clearleft to launch Learn Responsive Design on web.dev. This is a free online course with everything you need to know about designing for the new responsive web of today.

This is what’s been keeping me busy for the past few months (and for the next month or so too). I’ve been writing fifteen pieces—or “modules”—on modern responsive web design. One third of them are available now at web.dev/learn/design:

  1. Introduction
  2. Media queries
  3. Internationalization
  4. Macro layouts
  5. Micro layouts

The rest are on their way: typography, responsive images, theming, UI patterns, and more.

I’ve been enjoying this process. It’s hard work that requires me to dive deep into the nitty-gritty details of lots of different techniques and technologies, but that can be quite rewarding. As is often said, if you truly want to understand something, teach it.

Oh, and I made one more appearance at the Chrome Dev Summit. During the “Ask Me Anything” section, quizmaster Una asked the panelists a question from me:

Given the court proceedings against AMP, why should anyone trust FLOC or any other Google initiatives ostensibly focused on privacy?

(Thanks to Jake for helping craft the question into a form that could make it past the legal department but still retain its spiciness.)

The question got a response. I wouldn’t say it got an answer. My verdict remains:

I’m not sure that Google Chrome can be considered a user agent.

The fundamental issue is that you’ve got a single company that’s the market leader in web search, the market leader in web advertising, and the market leader in web browsers. I honestly believe all three would function better—and more honestly—if they were separate entities.

Monopolies aren’t just damaging for customers. They’re damaging for the monopoly too. I’d love to see Google Chrome compete on being a great web browser without having to also balance the needs of surveillance-based advertising.