Archive: On this day

February 26th, 2020

Checked in at Jolly Brewer. 🎻🎶 — with Jessica map

Checked in at Jolly Brewer. 🎻🎶 — with Jessica

Today I helped a colleague with some JavaScript (DOM scripting), did some proofreading and copy-editing on an excellent article written by another colleague, and made some progress on a new conference talk I’m working on.

A good day!

Roam Research – A note taking tool for networked thought.

This looks like an interesting hypertexty tool.

Picture 1 Picture 2 Picture 3 Picture 4

A feast of fish finery.

The Markup

A new online publication from Julia Angwin:

Big Tech Is Watching You. We’re Watching Big Tech.

…and they’re not going to track you.

Software and Home Renovation | Jim Nielsen’s Weblog

Lessons for web development from a home renovation project:

  • Greenfield Projects Are Everyone’s Favorite
  • The Last Person’s Work Is Always Bewildering
  • It’s All About the Trade-Offs
  • It ALWAYS Takes Longer Than You Think
  • Communication, Communication, Communication!

And there’s this:

You know those old homes people love because they’re unique, have lasted for decades, and have all that character? In contrast, you have these modern subdivision homes that, while shiny and new, are often bland and identical (and sometimes shoddily built). node_modules is like the suburbia/subdivision of modern web development: it seems nice and fancy today, and most everyone is doing it, but in 30 years everyone will hate the idea. They’ll all need to be renovated or torn down. Meanwhile, the classical stuff that’s still standing from 100 years ago lives on but nobody seems to be building houses that way anymore for some reason. Similarly, the first website ever is still viewable in all modern web browsers. But many websites built last year on last year’s bleeding edge tech already won’t work in a browser.

February 26th, 2019

The CSS mental model - QuirksBlog

PPK looks at the different mental models behind CSS and JavaScript. One is declarative and one is imperative.

There’s a lot here that ties in with what I was talking about at New Adventures around the rule of least power in technology choice.

I’m not sure if I agree with describing CSS as being state-based. The example that illustrates this—a :hover style—feels like an exception rather than a typical example of CSS.

Systems Thinking, Unlocked – Airbnb Design

Some useful lessons here for strengthening a culture of sustained work on a design system.

Creating and maintaining a design system is like planting a tree—it has to be nurtured and cared for to reap the benefits. The seed of our design system has been planted, and now our teams are working together to maintain and grow it. Our new way of working supports gives people recognition, facilitates trust, and creates strong partnerships.

Reading Binti by Nnedi Okorafor.

Buy this book

February 26th, 2018

Ends and means

The latest edition of the excellent History Of The Web newsletter is called The Day(s) The Web Fought Back. It recounts the first time that websites stood up against bad legislation in the form of the Communications Decency Act (CDA), and goes to recount the even more effective use of blackout protests against SOPA and PIPA.

I remember feeling very heartened to see WikiPedia, Google and others take a stand on January 18th, 2012. But I also remember feeling uneasy. In this particular case, companies were lobbying for a cause I agreed with. But what if they were lobbying for a cause I didn’t agree with? Large corporations using their power to influence politics seems like a very bad idea. Isn’t it still a bad idea, even if I happen to agree with the cause?

Cloudflare quite rightly kicked The Daily Stormer off their roster of customers. Then the CEO of Cloudflare quite rightly wrote this in a company-wide memo:

Literally, I woke up in a bad mood and decided someone shouldn’t be allowed on the Internet. No one should have that power.

There’s an uncomfortable tension here. When do the ends justify the means? Isn’t the whole point of having principles that they hold true even in the direst circumstances? Why even claim that corporations shouldn’t influence politics if you’re going to make an exception for net neutrality? Why even claim that free speech is sacrosanct if you make an exception for nazi scum?

Those two examples are pretty extreme and I can easily justify the exceptions to myself. Net neutrality is too important. Stopping fascism is too important. But where do I draw the line? At what point does something become “too important?”

There are more subtle examples of corporations wielding their power. Google are constantly using their monopoly position in search and browser marketshare to exert influence over website-builders. In theory, that’s bad. But in practice, I find myself agreeing with specific instances. Prioritising mobile-friendly sites? Sounds good to me. Penalising intrusive ads? Again, that seems okey-dokey to me. But surely that’s not the point. So what if I happen to agree with the ends being pursued? The fact that a company the size and power of Google is using their monopoly for any influence is worrying, regardless of whether I agree with the specific instances. But I kept my mouth shut.

Now I see Google abusing their monopoly again, this time with AMP. They may call the preferential treatment of Google-hosted AMP-formatted pages a “carrot”, but let’s be honest, it’s an abuse of power, plain and simple.

By the way, I have no doubt that the engineers working on AMP have the best of intentions. We are all pursuing the same ends. We all want a faster web. But we disagree on the means. If Google search results gave preferential treatment to any fast web pages, that would be fine. But by only giving preferential treatment to pages written in a format that they created, and hosted on their own servers, they are effectively forcing everyone to use AMP. I know for a fact that there are plenty of publications who are producing AMP content, not because they are sold on the benefits of the technology, but because they feel strong-armed into doing it in order to compete.

If the ends justify the means, then it’s easy to write off Google’s abuse of power. Those well-intentioned AMP engineers honestly think that they have the best interests of the web at heart:

We were worried about the web not existing anymore due to native apps and walled gardens killing it off. We wanted to make the web competitive. We saw a sense of urgency and thus we decided to build on the extensible web to build AMP instead of waiting for standard and browsers and websites to catch up. I stand behind this process. I’m a practical guy.

There’s real hubris and audacity in thinking that one company should be able to tackle fixing the whole web. I think the AMP team are genuinely upset and hurt that people aren’t cheering them on. Perhaps they will dismiss the criticisms as outpourings of “Why wasn’t I consulted?” But that would be a mistake. The many thoughtful people who are extremely critical of AMP are on the same side as the AMP team when it comes the end-goal of better, faster websites. But burning the web to save it? No thanks.

Ben Thompson goes into more detail on the tension between the ends and the means in The Aggregator Paradox:

The problem with Google’s actions should be obvious: the company is leveraging its monopoly in search to push the AMP format, and the company is leveraging its dominant position in browsers to punish sites with bad ads. That seems bad!

And yet, from a user perspective, the options I presented at the beginning — fast loading web pages with responsive designs that look great on mobile and the elimination of pop-up ads, ad overlays, and autoplaying videos with sounds — sounds pretty appealing!

From that perspective, there’s a moral argument to be made for wielding monopoly power like Google is doing. No doubt the AMP team feel it would be morally wrong for Google not to use its influence in search to give preferential treatment to AMP pages.

Going back to the opening examples of online blackouts, was it morally wrong for companies to use their power to influence politics? Or would it have been morally wrong for them not to have used their influence?

When do the ends justify the means?

Here’s a more subtle example than Google AMP, but one which has me just as worried for the future of the web. Mozilla announced that any new web features they add to their browser will require HTTPS.

The end-goal here is one I agree with: HTTPS everywhere. On the face of it, the means of reaching that goal seem reasonable. After all, we already require HTTPS for sensitive JavaScript APIs like geolocation or service workers. But the devil is in the details:

Effective immediately, all new features that are web-exposed are to be restricted to secure contexts. Web-exposed means that the feature is observable from a web page or server, whether through JavaScript, CSS, HTTP, media formats, etc. A feature can be anything from an extension of an existing IDL-defined object, a new CSS property, a new HTTP response header, to bigger features such as WebVR.

Emphasis mine.

This is a step too far. Again, I am in total agreement that we should be encouraging everyone to switch to HTTPS. But requiring HTTPS in order to use CSS? The ends don’t justify the means.

If there were valid security reasons for making HTTPS a requirement, I would be all for enforcing this. But these are two totally separate areas. Enforcing HTTPS by withholding CSS support is no different to enforcing AMP by withholding search placement. In some ways, I think it might actually be worse.

There’s an assumption in this decision that websites are being made by professionals who will know how to switch to HTTPS. But the web is for everyone. Not just for everyone to use. It’s for everyone to build.

One of my greatest fears for the web is that building it becomes the domain of a professional priesthood. Anything that raises the bar to writing some HTML or CSS makes me very worried. Usually it’s toolchains that make things more complex, but in this case the barrier to entry is being brought right into the browser itself.

I’m trying to imagine future Codebar evenings, helping people to make their first websites, but now having to tell them that some CSS will be off-limits until they meet the entry requirements of HTTPS …even though CSS and HTTPS have literally nothing to do with one another. (And yes, there will be an exception for localhost and I really hope there’ll be an exception for file: as well, but that’s simply postponing the disappointment.)

No doubt Mozilla (and the W3C Technical Architecture Group) believe that they are doing the right thing. Perhaps they think it would be morally wrong if browsers didn’t enforce HTTPS even for unrelated features like new CSS properties. They believe that, in this particular case, the ends justify the means.

I strongly disagree. If you also disagree, I encourage you to make your voice heard. Remember, this isn’t about whether you think that we should all switch to HTTPS—we’re all in agreement on that. This is about whether it’s okay to create collateral damage by deliberately denying people access to web features in order to further a completely separate agenda.

This isn’t about you or me. This is about all those people who could potentially become makers of the web. We should be welcoming them, not creating barriers for them to overcome.

Reliable Experiences - PWA Roadshow - YouTube

A good hands-on introduction to service workers from Mariko.

Reliable Experiences - PWA Roadshow

Tips for Running Workshops -

I’ve just come back from running a workshop at Webstock in New Zealand, followed by another one in Hong Kong. I heartily concur with Tim’s advice here. I’ve certainly migrated to having a more modular approach to workshops. In fact, these days I have little to no slides. Instead, it’s all about being flexible.

You can spend forever carefully crafting and refining your workshop and coming up with solid exercises but at the end of the day, you need to be ready to go with the flow.

Some sections you wanted to cover you may not get to. Some topics you hadn’t allotted a lot of time to may need to become more detailed. That’s all fine because the workshop is about helping them, not yourself.

The Internet Isn’t Forever

A terrific piece by Maria Bustillos on digital preservation and the power of archives, backed up with frightening real-world examples.

Because history is a fight we’re having every day. We’re battling to make the truth first by living it, and then by recording and sharing it, and finally, crucially, by preserving it. Without an archive, there is no history.

as days pass by — Collecting user data while protecting user privacy

Really smart thinking from Stuart on how the randomised response technique could be applied to analytics. My only question is who exactly does the implementation.

The key point here is that, if you’re collecting data about a load of users, you’re usually doing so in order to look at it in aggregate; to draw conclusions about the general trends and the general distribution of your user base. And it’s possible to do that data collection in ways that maintain the aggregate properties of it while making it hard or impossible for the company to use it to target individual users. That’s what we want here: some way that the company can still draw correct conclusions from all the data when collected together, while preventing them from targeting individuals or knowing what a specific person said.

Last night’s rib. Because it was my birthday, that’s why.

Last night’s rib. Because it was my birthday, that’s why.

February 26th, 2017

Hello, hydrant.

Hello, hydrant.

Silent Running.

Silent Running.

Accessible HAL: audio output with text fallback.

Accessible HAL: audio output with text fallback.

Edge of darkness: looking into the black hole at the heart of the Milky Way | Science | The Guardian

Building a planet-sized telescope suggests all sorts of practical difficulties.

February 26th, 2016

Eating toast. In Ipswich.

Morning coffee.

Morning coffee.

February 26th, 2015



Steak and truffles.

Steak and truffles.

Seabass ceviche.

Seabass ceviche.

February 26th, 2014

Platformed. — Unstoppable Robot Ninja

The importance of long-term thinking in web design. I love this description of the web:

a truly fluid, chaotic design medium serving millions of imperfect clients


Stop me if you’ve heard this one before. You’re reading an article on Smashing Magazine or A List Apart or some other publication. The article is about a specific feature of CSS, or maybe JavaScript, or perhaps it’s exploring some of the newer additions to HTML. The article is good. It explains how to use this particular feature in your work. Then you read the comments. The first comment is inevitably from someone bemoaning the fact that they can’t use this feature because it isn’t supported in every browser. Specifically, it isn’t supported in some older version of Internet Explorer that they have to support. Therefore the entire article is rendered null and void.

That attitude infuriates and depresses me. It seems to me that it demonstrates a fundamental mismatch between how that person views the job of web development and the way the web actually works.

It is entirely possible—nay, desirable—to use features long before they are supported in every browser. That’s how we move the web forward. If we waited until there was universal support for a feature before we used it, we’d still be using CSS 1.0 and HTML 2.0.

If you use a CSS feature that isn’t supported in a particular browser—like, say, an older version of Internet Explorer—that browser will simply ignore that CSS rule. So you don’t get that rounded corner, or text shadow, or whatever it was. Browsers have the same error-handling mechanism for HTML: if they see something they don’t understand, they just ignore it. The browser will not throw an error. The browser will not stop rendering the page. Browsers are very liberal in what they accept.

It’s a bit trickier with JavaScript: browsers will throw an error; browsers will stop processing the script. That’s why it’s important to use feature detection. That’s also why you definitely don’t want to rely on JavaScript for rendering your content—it’s the most fragile layer of the front-end stack. Note, I’m not saying don’t use JavaScript; I’m saying don’t rely on JavaScript. Otherwise you’ve got yourself a SPOF.

Anyway, my point is—and I can’t believe I still have to repeat this after all these years—websites do not need to look exactly the same in every browser.

“But my client!”, cries the Smashing Magazine commenter, “But my boss!”

If your client or boss expects that a website will look and behave the same in every browser on every device, then where did they get those expectations from? And rather than spending your time trying to meet those impossible expectations, I think your time would be better spent explaining why those expectations don’t match the reality of the web.

It’s like Mike Monteiro says about clients: if they just don’t get something about your design, that’s not their fault; it’s yours. Explaining your design work is part of your design work. It’s the same with web development. It’s our job to explain how the web works …and how the unevenly-distributed nature of browser capabilities is not a bug, it’s a feature.

That was true fourteen years ago when John Allsopp wrote A Dao Of Web Design, and it’s still true today. Back then, designers and developers were comparing the web to print and finding it wanting. These days, designers and developers are comparing the web to native and finding it wanting. In both cases, I feel like they’re missing the fundamental point of the web: you can provide universal access to content and tasks without providing exactly the same experience for every single browser or device. That’s not a failing of the web—that’s its killer app.

Paul Kinlan published a post called This Is the Web Platform where he tabulates the current state of browser support for various features. “Pretty damning” he says:

the feature support that is ubiquitous across the web is actually pretty small especially if you are supporting IE8.

That’s true …from a certain point of view. But it depends on your definition of “support”. If your definition of “support” is “must look and work identically to the latest version of Chrome”, then yes, you’re going to have a smaller set of features you can use (you’re also going to live a miserable existence). But if your definition of “support” is “must be able to access the content and accomplish the task”, then as long as you’re using progressive enhancement, you can use all the features you want and support Internet Explorer 8, 7, 6, 5 …you can support every browser capable of connecting to the internet.

Like Brad said:

There is a difference between support and optimization.

I think part of the problem may be with the language we use. We talk about “the browser” when we should be talking about the browsers. I’m guilty of this. I’ll use phrases like “designing in the browser” or talk about “what we can do in the browser”, when really I should be talking about designing in the browsers and what we can do in the browsers.

It’s a subtle Lakoffian thing, but when we talk about “the browser” as if it were a single entity we might be unconsiously reinforcing the expectation that there is one Platonic ideal of browser rendering and that’s what we’re designing for.

There’s another phrase that bothers me, and it’s the phrase that Paul used in the title of his article: “the web platform”. This is something I talked about back in November in my presentation The Power of Simplicity:

But this idea of the web as a platform, I get why from a marketing perspective, we’d want to use that phrase, because it puts the web on equal footing with genuine platforms.

I would say Flash is a platform, and native: iOS and Android and these things. They are platforms, in that it’s all one bundle. And the web isn’t like that.

What I mean is, if you use the Flash platform, then anyone with the Flash plug-in can get your content. It’s on or off. It’s one or zero; it’s binary. Either they have the platform or they don’t. Either they get all your content, or none of your content.

And it’s similar with native apps. If you’ve got the right phone, you can get my app. All of my app. You don’t get bits of my app, you get all my app. Or you get none of it because you don’t have that particular phone that I’m supporting.

And the web is not like that. The web is not binary, one or zero, on or off. It’s not a platform where you get one hundred per cent or zero per cent. It’s this continuum.

The web is not a platform. It’s a continuum.

February 26th, 2013

Responsive day soon

This is shaping up to be a fun week. I’m off to Altitude down the coast in Portsmouth tomorrow. If you’re going to be there, come and say hello. Then just two days after that it’ll be the Responsive Day Out here in Brighton. Squee!

If you’re coming to Brighton the day before the conference, I recommend heading along to Thursday’s Async event on building HTML5 games. I won’t be able to make it, alas—I’ll be whisking the speakers off to an undisclosed location for a nice evening out.

I have a favour to ask of you if you’re coming along to the Responsive Day Out on Friday. If you have any web-related books that you no longer need, please bring them along with you. I want to support Scrunchup’s initiative to distribute materials to schools.

I’ll also be bringing some books along, thanks to sponsors A Book Apart. If you ask a question during the discussion portions of the day, you can claim a book: either Ethan’s, or Luke’s, or Karen’s.

If you’re coming along to the Responsive Day Out, please get there nice and early for registration. Doors open at 9am and everything kicks off at 10am. There will be coffee. Good coffee.

Here’s the plan. It may change…

9:00 – 10:00Registration
10:00 – 10:20Sarah Parmenter
10:20 – 10:40David Bushell
10:40 – 11:00Tom Maslen
11:00 – 11:15Chat with Sarah, David, and Tom
11:15 – 11:45Break
11:45 – 12:05Richard Rutter and Josh Emerson
12:05 – 12:25Laura Kalbag
12:25 – 12:45Elliot Jay Stocks
12:45 – 13:00Chat with Richard, Josh, Laura, and Elliot
13:00 – 14:30Lunch break
14:30 – 14:50Anna Debenham
14:50 – 15:10Andy Hume
15:10 – 15:30Bruce Lawson
15:30 – 15:45Chat with Anna, Andy, and Bruce
15:45 – 16:15Break
16:15 – 16:35Owen Gregory
16:35 – 16:55Paul Lloyd
16:55 – 17:15Mark Boulton
17:15 – 17:30Chat with Owen, Paul, and Mark

Alice and Bob in Cipherspace

A clear explanation of the current state of homomorphic encryption.

February 26th, 2012 · Blog · The Responsive Process

Josh goes through the talking points from the recent Responsive Summit he attended. Sounds like it was a great get-together.

A better responsive image format - Stuff in my head

Here’s a new angle on tackling the responsive image problem: what if the file format itself could specify multiple image sizes?

» 24 February 2012, baked by Ben Ward @ The Pastry Box Project

A beautiful reminder from Ben of the scale-free nature of the web.

We must recover our sanity where 100 million users does not represent the goal criteria of every new service. We must recover the mindset where a service used by 10,000 users, or 1,000 users, or 100 users is admired, respected, and praised for its actual success. All of those could be sustainable, profitable ventures. If TechCrunch doesn’t care to write about you, all the better.

If you are fortunate enough to work on your own product, with your own idea, and build it, and ship it, and reach enough people willing to sustain you financially for that immense amount of work, you should be applauded. You have poured in inordinate effort, and succeeded in making something that improved lives.

Responsive Design: Why You’re Doing It Wrong | Design Shack

A rallying cry for a content-focused—rather than device-focused—approach to responsive design. Despite the awful title and occasionally adversarial tone, this article is making a very good point about being future friendly.

Webstock: Jeremy Keith | Flickr - Photo Sharing!

I love these sketchnotes from my presentation at Webstock.

Webstock: Jeremy Keith

February 26th, 2010

Design discussions: Paul Shaw and the NYC Subway: idsgn (a design blog)

"There is a common misbelief that Helvetica is the signage typeface of the New York City subway system. In this ‘Design discussions’, we talk to the author who has uncovered the truth (maybe) behind the story."

February 26th, 2009

February 26th, 2004

Futurlab shindig

I’m down at the Sussex Arts Club enjoying the hospitality of new web kids on the block, Futurlab ("we got rid of the ‘e’ and passed the savings on to you").

Any party that supplies free Wi-Fi is a winner in my (i)book.

Here are (some of) the hosts for the evening: Andy (a fellow standards compliance bod) and James.

Andy and James

The big smoke

Yesterday was my birthday (discretion prevents me from revealing my current age).

Handily enough, there was a pre-planned shindig happening: a concert featuring Salter Cane and three other bands (not in my honour, you understand). Less handy was the fact that the concert took place in London.

Much driving and map reading was involved once we had crammed ourselves and our instruments into our little transportation device. We were like the country bumpkins heading off to the Capitol City to gape at its high-falutin’ modern ways.

The concert went okay. One of the other bands, The Shout Out Louds, who were great, came all the way from Sweden. That made the drive up from Brighton seem like a bit less of an odyssey.

My birthday celebrations had to wait until after we had played: despite being a common rock’n’roll combination, alcohol and music don’t mix. Our drummer, Catherine, brought along a bottle of fine champagne to toast my birthday and she managed to blag some glasses from the bar staff.

Driving back through London, crossing the Thames over Tower Bridge, I was struck as always by the sheer weight of history pressing down on almost every inch of the city.

Then again, that might just be because I’m in the middle of reading Neal Stephenson’s Quicksilver, set largely in 17th century London.

It’s an amazing city although I’m not sure I’d want to live there; it felt awfully nice to get back to the relative tranquility of Brighton. Still, I really need to make an effort to get up there more often.

February 26th, 2003


Before I discovered the web (heck, before the web was even invented), I was a busker.

I played mandolin and, later, bouzouki from Ireland to Canada and all across Europe.

In all that time, I never once played in London.

Reading this account of seven Guardian journalists who did, I think I made the right choice.

You can read their field reports, find out how much each one made and, at the end, listen to a sound sample of each.

I can relate to a lot of the experiences:

"Income is provided almost entirely by toddlers mesmerised by such a silly thing. A tug at mum’s sleeve and she, wanting to bring up a nice boy, coughs up (although one child actually removes money. Should be a critic)."

Jeremy the bear

When I was growing up in Ireland, this television programme used to be on.

The show’s opening had the title character singing the theme song. This theme song was in turn sung to me, the only Jeremy in my town, by all the jocks as they tormented me:

“I’m a bear called Je-re-my,

I can do most an-y-thing,

I can dance and I can sing…”


Y’know, it’s great that you can find just about anything on the internet but some things are best left forgotten.

February 26th, 2002

Mac OS X Roadshow

Jessica and I spent the day at the Mac OS X Roadshow which came to town today. Overall, it was pretty good.

The morning session called "Ten on X" was a chance for some of the big software companies to show their flagship products for OS X. The big announcement was from Adobe. They premiered Photoshop 7.It looks like it has some nifty new features. I’ll definitely be making the upgrade anyway.

We were nicely fed with a buffet lunch. Afterwards, we sat in on a couple of seminars. One was on web publishing and the other on audio. The web publishing seminar was basically Adobe and Connectix showing off their stuff - nothing I didn’t already know.

The audio seminar was kind of interesting because it involved somebody plugging a guitar into a Mac to play along to some songs. It’s all powered by some very powerful software that’s out of my league and not really what I need for trying to record a band in a practice room. It was still fun to see how the professionals do it.

All in all, it was an interesting day. I got to play with one of the new iMacs and being inside the Metropole hotel was certainly better than being outside in the howling wind and driving rain.