Tags: toc



Thursday, May 12th, 2022

Cautionary Tales from Cryptoland

This quote from the brilliant Molly White is about web3/blockchain/cryptobollocks but it applies to evaluating technology in general (like, say, JavaScript frameworks):

I firmly believe that companies first need to identify and research the problem they are trying to solve, and then select the right technology to do it. Those technologies may not be the latest buzzword, and they may not cause venture capitalists to come crawling out of the woodwork, but choosing technologies with that approach tends to be a lot more successful in the long run — at least, assuming the primary goal is to actually solve a problem rather than attract VC money.

Thursday, May 5th, 2022

Notes from a gopher:// site - daverupert.com

The result of adding more constraints means that the products have a broader appeal due to their simple interface. It reminds me of a Jeremy Keith talk I heard last month about programming languages like CSS which have a simple interface pattern: selector { property: value }. Simple enough anyone can learn. But simple doesn’t mean it’s simplistic, which gives me a lot to think about.

Sunday, January 16th, 2022

It’s not still the early days

If you’re interested in so-called web3, you should definitely follow Molly White.

How long can it possibly be “early days”? How long do we need to wait before someone comes up with an actual application of blockchain technologies that isn’t a transparent attempt to retroactively justify a technology that is inefficient in every sense of the word? How much pollution must we justify pumping into our atmosphere while we wait to get out of the “early days” of proof-of-work blockchains? How many people must be scammed for all they’re worth while technologists talk about just beginning to think about building safeguards into their platforms? How long must the laymen, who are so eagerly hustled into blockchain-based projects that promise to make them millionaires, be scolded as though it is their fault when they are scammed as if they should be capable of auditing smart contracts themselves?

The more you think about it, the more “it’s early days!” begins to sound like the desperate protestations of people with too much money sunk into a pyramid scheme, hoping they can bag a few more suckers and get out with their cash before the whole thing comes crashing down.

Thursday, January 6th, 2022

On a long bet – A Whole Lotta Nothing

Matt’s thoughts on that bet. Not long now…

Thursday, December 23rd, 2021

Brian Eno on NFTs and Automaticism

Much of the energy behind crypto arises from the very strong need that some people feel to operate outside of a state, and therefore outside of any sort of democratic communal overview. The idea that Ayn Rand, that Nietzsche-for-Teenagers toxin, should have had her whacky ideas enshrined in a philosophy about money is what is terrifying to me.

Tuesday, December 7th, 2021

The Case Against Crypto | Pervasive Media Studio

The underlying technology of cryptocurrency is based on a world without trust. Its most ardent proponents want to demolish institutions and abolish regulation, reducing the world to a numbers game which they believe they can win. If the wildest fantasies of cryptocurrency enthusiasts were to come true, if all the environmental and technical objections were to fall away, the result would be financial capitalism with all the brakes taken off.

The promotion of cryptocurrencies is at best irresponsible, an advertisement for an unregulated casino. At worst it is an environmental disaster, a predatory pyramid scheme, and a commitment to an ideology of greed and distrust. I believe the only ethical response is to reject it in all its forms.

Tuesday, October 5th, 2021

Build a Better Mobile Input

This is such a handy tool for building forms! Choose different combinations of type, inputmode, and autocomplete attributes on input elements and see how that will be conveyed to users on iOS and Android devices.

Tuesday, August 10th, 2021

HTTP/3 From A To Z: Core Concepts (Part 1) — Smashing Magazine

I spend most of my time in the application layers—HTML, CSS, and JavaScript—so I fascinating to dive below the surface and learn about the upcoming HTTP/3. Sounds like it’s really more of a change to how things have always worked with the TCP protocol, still chugging away since it was created by Bob Kahn and Vint Cerf.

Sunday, August 8th, 2021

Chromium Blog: Increasing HTTPS adoption

At some point, you won’t be able to visit the first web page ever published without first clicking through a full-page warning injected by your web browser:

Chrome will offer HTTPS-First Mode, which will attempt to upgrade all page loads to HTTPS and display a full-page warning before loading sites that don’t support it. Based on ecosystem feedback, we’ll explore making HTTPS-First mode the default for all users in the future.

Tuesday, April 27th, 2021

Cryptocurrency is an abject disaster


Cryptocurrency is one of the worst inventions of the 21st century. I am ashamed to share an industry with this exploitative grift. It has failed to be a useful currency, invented a new class of internet abuse, further enriched the rich, wasted staggering amounts of electricity, hastened climate change, ruined hundreds of otherwise promising projects, provided a climate for hundreds of scams to flourish, created shortages and price hikes for consumer hardware, and injected perverse incentives into technology everywhere. Fuck cryptocurrency.

Monday, March 29th, 2021

Chromium Blog: A safer default for navigation: HTTPS

Just over a year ago, I pondered some default browser behaviours and how they might be updated.

The first one is happening: Chrome is going to assume https before checking for http.

Now what about the other default behaviour that’s almost 15 years old now? When might a viewport width value of device-width become the default?

Sunday, March 14th, 2021

Solar Protocol

This website is hosted across a network of solar powered servers and is sent to you from wherever there is the most sunshine.

Sunday, August 30th, 2020

The land before modern APIs – Increment: APIs

This is a wonderful tale of spelunking into standards from Darius Kazemi—I had no idea that HTTP status codes have their origin in a hastily made decision in the days of ARPANET.

20 people got together at MIT in 1972 for a weekend workshop. On the second day, a handful of people in a breakout session decided it would be a good idea to standardize error messages between two services for transferring data, even though those two services had not necessarily planned to speak to one another. One thing led to another, and now 404 is synonymous with “I can’t find the thing.”

This story is exactly the kind of layering of technologies that I was getting at in the first chapter of Resilient Web Design.

HTTP status codes are largely an accident of history. The people who came up with them didn’t plan on defining a numerical namespace that would last half a century or work its way into popular culture. You see this pattern over and over in the history of technology.

Wednesday, August 26th, 2020

Submitting a form with datalist

I’m a big fan of HTML5’s datalist element and its elegant design. It’s a way to progressively enhance any input element into a combobox.

You use the list attribute on the input element to point to the ID of the associated datalist element.

<label for="homeworld">Your home planet</label>
<input type="text" name="homeworld" id="homeworld" list="planets">
<datalist id="planets">
 <option value="Mercury">
 <option value="Venus">
 <option value="Earth">
 <option value="Mars">
 <option value="Jupiter">
 <option value="Saturn">
 <option value="Uranus">
 <option value="Neptune">

It even works on input type="color", which is pretty cool!

The most common use case is as an autocomplete widget. That’s how I’m using it over on The Session, where the datalist is updated via Ajax every time the input is updated.

But let’s stick with a simple example, like the list of planets above. Suppose the user types “jup” …the datalist will show “Jupiter” as an option. The user can click on that option to automatically complete their input.

It would be handy if you could automatically submit the form when the user chooses a datalist option like this.

Well, tough luck.

The datalist element emits no events. There’s no way of telling if it has been clicked. This is something I’ve been trying to find a workaround for.

I got my hopes up when I read Amber’s excellent article about document.activeElement. But no, the focus stays on the input when the user clicks on an option in a datalist.

So if I can’t detect whether a datalist has been used, this best I can do is try to infer it. I know it’s not exactly the same thing, and it won’t be as reliable as true detection, but here’s my logic:

  • Keep track of the character count in the input element.
  • Every time the input is updated in any way, check the current character count against the last character count.
  • If the difference is greater than one, something interesting happened! Maybe the user pasted a value in …or maybe they used the datalist.
  • Loop through each of the options in the datalist.
  • If there’s an exact match with the current value of the input element, chances are the user chose that option from the datalist.
  • So submit the form!

Here’s how that translates into DOM scripting code:

document.querySelectorAll('input[list]').forEach( function (formfield) {
  var datalist = document.getElementById(formfield.getAttribute('list'));
  var lastlength = formfield.value.length;
  var checkInputValue = function (inputValue) {
    if (inputValue.length - lastlength > 1) {
      datalist.querySelectorAll('option').forEach( function (item) {
        if (item.value === inputValue) {
    lastlength = inputValue.length;
  formfield.addEventListener('input', function () {
  }, false);

I’ve made a gist with some added feature detection and mustard-cutting at the start. You should be able to drop it into just about any page that’s using datalist. It works even if the options in the datalist are dynamically updated, like the example on The Session.

It’s not foolproof. The inference relies on the difference between what was previously typed and what’s autocompleted to be more than one character. So in the planets example, if someone has type “Jupite” and then they choose “Jupiter” from the datalist, the form won’t automatically submit.

But still, I reckon it covers most common use cases. And like the datalist element itself, you can consider this functionality a progressive enhancement.

Wednesday, August 5th, 2020

The Resiliency of the Internet | Jim Nielsen’s Weblog

An ode to the network architecture of the internet:

I believe the DNA of resiliency built into the network manifests itself in the building blocks of what’s transmitted over the network. The next time somebody calls HTML or CSS dumb, think about that line again:

That simplicity, almost an intentional brainlessness…is a key to its adaptability.

It’s not a bug. It’s a feature.

Yes! I wish more web developers would take cues from the very medium they’re building atop of.

Monday, April 20th, 2020

Better Form Inputs for Better Mobile User Experiences | CSS-Tricks

Here’s one simple, practical way to make apps perform better on mobile devices: always configure HTML input fields with the correct type, inputmode, and autocomplete attributes. While these three attributes are often discussed in isolation, they make the most sense in the context of mobile user experience when you think of them as a team.

This is an excellent deep dive with great advice:

You may think that you are familiar with the basic autocomplete options, such as those that help the user fill in credit card numbers or address form fields, but I’d urge you to review them to make sure that you are aware of all of the options. The spec lists over 50 values!

Wednesday, March 11th, 2020

The History of the URL

This is a wonderful deep dive into all the parts of a URL:


There’s a lot of great DNS stuff about the host part:

Root DNS servers operate in safes, inside locked cages. A clock sits on the safe to ensure the camera feed hasn’t been looped. Particularily given how slow DNSSEC implementation has been, an attack on one of those servers could allow an attacker to redirect all of the Internet traffic for a portion of Internet users. This, of course, makes for the most fantastic heist movie to have never been made.

Saturday, January 25th, 2020

HTML attributes to improve your users’ two factor authentication experience - Twilio

The many ways of improving a single form field in HTML.

I love these kinds of deep dives into markup!

Wednesday, January 22nd, 2020

28c3: The Science of Insecurity - YouTube

I understand less than half of this great talk by Meredith L. Patterson, but it ticks all my boxes: Leibniz, Turing, Borges, and Postel’s Law.

(via Tim Berners-Lee)

28c3: The Science of Insecurity

Monday, January 6th, 2020

Browser defaults

I’ve been thinking about some of the default behaviours that are built into web browsers.

First off, there’s the decision that a browser makes if you enter a web address without a protocol. Let’s say you type in example.com without specifying whether you’re looking for http://example.com or https://example.com.

Browsers default to HTTP rather than HTTPS. Given that HTTP is older than HTTPS that makes sense. But given that there’s been such a push for TLS on the web, and the huge increase in sites served over HTTPS, I wonder if it’s time to reconsider that default?

Most websites that are served over HTTPS have an automatic redirect from HTTP to HTTPS (enforced with HSTS). There’s an ever so slight performance hit from that, at least for the very first visit. If, when no protocol is specified, browsers were to attempt to reach the HTTPS port first, we’d get a little bit of a speed improvement.

But would that break any existing behaviour? I don’t know. I guess there would be a bit of a performance hit in the other direction. That is, the browser would try HTTPS first, and when that doesn’t exist, go for HTTP. Sites served only over HTTP would suffer that little bit of lag.

Whatever the default behaviour, some sites are going to pay that performance penalty. Right now it’s being paid by sites that are served over HTTPS.

Here’s another browser default that Rob mentioned recently: the viewport meta tag:

I thought I might be able to get away with omitting meta name="viewport". Apparently not! Maybe someday.

This all goes back to the default behaviour of Mobile Safari when the iPhone was first released. Most sites wouldn’t display correctly if one pixel were treated as one pixel. That’s because most sites were built with the assumption that they would be viewed on monitors rather than phones. Only weirdos like me were building sites without that assumption.

So the default behaviour in Mobile Safari is assume a page width of 1024 pixels, and then shrink that down to fit on the screen …unless the developer over-rides that behaviour with a viewport meta tag. That default behaviour was adopted by other mobile browsers. I think it’s a universal default.

But the web has changed since the iPhone was released in 2007. Responsive design has swept the web. What would happen if mobile browsers were to assume width=device-width?

The viewport meta element always felt like a (proprietary) band-aid rather than a long-term solution—for one thing, it’s the kind of presentational information that belongs in CSS rather than HTML. It would be nice if we could bid it farewell.