Signed!
We, the undersigned, call on the record labels and members of the Recording Industry Association of America (RIAA)—including UMG, Capitol Records, Concord Bicycle Assets, CMGI Recorded Music Assets, Sony Music Entertainment, and Arista Music—to drop your lawsuit against the Internet Archive.
Here’s a fun account of the early days of the ARPANET.
Heydon is employing a different tactic to what I’m doing to sabotage large language model crawlers. These bots don’t respect the nofollow rel value …so now they pay the price.
Raising my own middle finger to LLM manufacturers will achieve little on its own. If doing this even works at all. But if lots of writers put something similar in place, I wonder what the effect would be. Maybe we would start seeing more—and more obvious—gibberish emerging in generative AI output. Perhaps LLM owners would start to think twice about disrespecting the
nofollowprotocol.
I really like the idea of unifying some layout values in CSS. If you’ve got any feedback, please chip in!
I’ve been banging on for a while now about how much I’d like a declarative option for the Web Share API. I was thinking that the type attribute on the button element would be a good candidate for this (there’s prior art in the way we extended the type attribute on the input element for HTML5).
I wrote about the reason for a share button type as well as creating a polyfill. I also wrote about how this idea would work for other button types: fullscreen, print, copy to clipboard, that sort of thing.
Since then, I’ve been very interested in the idea of “invokers” being pursued by the Open UI group. Rather than extending the type attribute, they’ve been looking at adding a new attribute. Initially it was called invoketarget (so something like button invoketarget="share").
Things have been rolling along and invoketarget has now become the command attribute (there’s also a new commandfor attribute that you can point to an element with an ID). Here’s a list of potential values for the command attribute on a button element.
Right now they’re focusing on providing declarative options for launching dialogs and other popovers. That’s already shipping.
The next step is to use command and commandfor for controlling audio and video, as well as some form controls. I very much approve! I love the idea of being able to build and style a fully-featured media player without any JavaScript.
I’m hoping that after that we’ll see the command attribute get expanded to cover JavaScript APIs that require a user interaction. These seem like the ideal candidates:
button command="share"button command="fullscreen"button command="print"button command="copy"button command="install"There’s also scope for declarative options for navigating the browser’s history stack:
button command="back"button command="forward"button command="refresh"Whatever happens next, I’m very glad to see that so much thinking is being applied to declarative solutions for common interface patterns.
There’s a new proposal for giving developers more control over styling form controls. I like it.
It’s clearly based on the fantastic work being done by the Open UI group on the select element. The proposal suggests that authors can opt-in to the new styling possibilities by declaring:
appearance: base;
So basically the developer is saying “I know what I’m doing—I’m taking the controls.” But browsers can continue to ship their default form styles. No existing content will break.
The idea is that once the developer has opted in, they can then style a number of pseudo-elements.
This proposal would apply to pretty much all the form controls you can think of: all the input types, along with select, progress, meter, buttons and more.
But there’s one element more that I wish were on the list:
legend
I know, technically it’s not a form control but legend and fieldset are only ever used within forms.
The legend element is notoriously annoying to style. So a lot of people just don’t bother using it, which is a real shame. It’s like we’re punishing people for doing the right thing.
Wouldn’t it be great if you, as a developer, had the option of saying “I know what I’m doing—I’m taking the controls”:
legend {
appearance: base;
}
Imagine if that nuked the browser’s weird default styles, effectively turning the element into a span or div as far as styling is concerned. Then you could style it however you wanted. But crucially, if browsers shipped this, no existing content would break.
The shitty styling situation for legend (and its parent fieldset) is one of those long-standing annoyances that seems to have fallen down the back of the sofa of browser vendors. No one’s going to spend time working on it when there are more important newer features to ship. That’s why I’d love to see it sneak in to this new proposal for styling form controls.
I was in Amsterdam last week. Just like last year I was there to help out Vasilis’s students with a form-based assignment:
They’re given a PDF inheritance-tax form and told to convert it for the web.
Yes, all the excitement of taxes combined with the thrilling world of web forms.
(Side note: this time they were told to style it using the design system from the Dutch railway because the tax office was getting worried that they were making phishing sites.)
I saw a lot of the same challenges again. I saw how students wished they could specify a past date or a future date in a date picker without using JavaScript. And I saw them lamenting the time they spent styling legends that worked across all browsers.
Right now, Mason Freed has an open issue on the new proposal with his suggestion to add some more elements to consider. Both legend and fieldset are included. That gets a thumbs-up from me.
I really like Brad’s new project, Cold Album Drumming:
Brad Frost plays drums to the albums he knows intimately, but has never drummed to before. Cover to cover. No warm-up. No prep. Totally cold. What could possibly go wrong?
I got a kick out of watching him play along to Radiohead’s In Rainbows and The Decemberist’s The Crane Wife.
I was really into The Decemberists in the first decade of the 21st Century. I remember seeing them in a long-gone Brighton venue more than twenty years ago.
But I kind of stopped paying attention to them after they released The Hazards Of Love. Not because I didn’t like that album. Quite the opposite. I love that album. I think in my mind I kind of thought “That’s it, they’ve done it, they can go home now.”
It’s exactly the kind of album I should not like. It’s a concept album. A folk-rock opera.
When I was growing up, concept albums were the antithesis of cool. Prog rock was like an insult.
You have to remember just how tribal music was back in the ’70s and ’80s. In my school, I remember the divide between the kind of people who listened to The Cure and The Smiths versus the kind of people who listened to Prince or Queen. Before that you had the the mods and the rockers, which in hindsight makes no sense—how are The Who and The Jam not rockers?
Looking back now, it’s ridiculous. I get the impression that for most people growing up in the last few decades, those kind of distinctions have been erased. People’s musical intake is smeared across all types and time periods. That is a good thing.
Anyway, a folky prog-rock opera like The Hazards Of Love is exactly the kind of thing that past me would’ve hated. Present me adores it. Maybe it’s because it’s got that folky angle. I suspect Colin Meloy listened to a lot of Horslips—heck, The Decemberists even did their own mini version of The Táin.
Speaking of mythic Irish language epics, I really like John Spillane’s Fíorusice:
Fíoruisce - The Legend of the Lough is a three-act Gaelic folk opera composed by Irish artist John Spillane. It is a macaronic or bilingual work. The work is an imagined re-Gaelicization of the Victorian Cork fairytale Fior-usga collected by Thomas Crofton Croker in the 1800’s and published in his book Fairy Legends and Traditions of the South of Ireland (1828). The story is a surreal tale culminating in a drowned kingdom, which as lore tells us, becomes The Lough in Cork city as we know it today. They say, you can see the tops of the underworld towers on a clear day and hear the music of their big party on Midsummer’s night.
Yup, it’s another concept album. And funnily enough, past me was not a fan of John Spillane either.
I first heard him when he was part of a trad band called Nomos in Cork in the early ’90s (the bódhran player’s mother was friends with my mother). I really liked their tunes but I thought the songs were kind of twee.
Over the years, the more of his songs I heard, the more I understood that John Spillane was just being completely open and honest. Past me thought that was twee. Present me really respects it. In fact, I genuinely love his songs like Johnny Don’t Go To Ballincollig and All The Ways You Wander.
And then there’s Passage West. It’s a masterpiece. I might be biased because Passage West is the next town over from Cobh, where I grew up.
So yeah, Fíorusice is something that past me would’ve disdained:
Present me is into all three.
It’s Bandcamp Friday today. I think I know what I’m going to get.
Some good—if overlong—writing advice.
- Focus on what matters to readers
- Be welcoming to everyone
- Swap formal words for normal ones
- When we have to say sorry, say it sincerely
- Watch out for jargon
- Avoid ambiguity: write in the active voice
- Use vivid words & delightful wordplay
- Make references most people would understand
- Avoid empty adjectives & marketing cliches
- Make people feel they’re in on the joke – don’t punch down
- Add a pinch of humour, not a dollop
- Smart asides, not cheap puns and cliches
- Be self-assured, but never arrogant
Here’s a post outlining all the great things you can do in mobile web browsers today: Your App Should Have Been A Website (And Probably Your Game Too):
Today’s browsers are powerhouses. Notifications? Check. Offline mode? Check. Secure payments? Yep, they’ve got that too. And with technologies like WebAssembly and WebGPU, web games are catching up to native-level performance. In some cases, they’re already there.
This is all true. But this post from John Gruber is equally true: One Bit of Anecdata That the Web Is Languishing Vis-à-Vis Native Mobile Apps:
I won’t hold up this one experience as a sign that the web is dying, but it sure seems to be languishing, especially for mobile devices.
As John points out, the problems aren’t technical:
There’s absolutely no reason the mobile web experience shouldn’t be fast, reliable, well-designed, and keep you logged in. If one of the two should suck, it should be the app that sucks and the website that works well. You shouldn’t be expected to carry around a bundle of software from your utility company in your pocket. But it’s the other way around.
He’s right. It makes no sense, but this is the reality.
Ten or fifteen years ago, the gap between the web and native apps on mobile was entirely technical. There were certain things that you just couldn’t do in web browsers. That’s no longer the case now. The web caught up quite a while back.
But the experience of using websites on a mobile device is awful. Never mind the terrible performance penalties incurred by unnecessary frameworks and libraries like React and its ilk, there’s the constant game of whack-a-mole with banners and overlays. What’s just about bearable in a large desktop viewport becomes intolerable on a small screen.
This is not a technical problem. This doesn’t get solved by web standards. This is a cultural problem.
First of all, there’s the business culture. If your business model depends on tracking people or pushing newsletter sign-ups, then it’s inevitable that your website will be shite on mobile.
Mind you, if your business model depends on tracking people, you’re more likely to try push people to download your native app. Like Cory Doctorow says:
50% of web users are running ad-blockers. 0% of app users are running ad-blockers, because adding a blocker to an app requires that you first remove its encryption, and that’s a felony (Jay Freeman calls this ‘felony contempt of business-model’).
Matt May brings up the same point in his guide, How to grey-rock Meta:
Remove Meta apps from your devices and use only the mobile web versions. Mobile apps have greater access to your personal data, provided the app requests those privileges, and Facebook and Instagram in particular (more so than WhatsApp, another Meta property) request the vast majority of those privileges. This includes precise GPS data on where you are, whether or not you are using the app.
Ironically, it’s the strength of the web—and web browsers—that has led to such shitty mobile web experiences. The pretty decent security model on the web means that sites have to pester you.
Part of the reason why you don’t see the same egregious over-use of pop-ups and overlays in native apps is that they aren’t needed. If you’ve installed the app, you’re already being tracked.
But when I describe the dreadful UX of most websites on mobile as a cultural problem, I don’t just mean business culture.
Us, the people who make websites, designers and developers, we’re responsible for this too.
For all our talk of mobile-first design for the last fifteen years, we never really meant it, did we? Sure, we use media queries and other responsive techniques, but all we’ve really done is make sure that a terrible experience fits on the screen.
As developers, I’m sure we can tell ourselves all sorts of fairy tales about why it’s perfectly justified to make users on mobile networks download React, Tailwind, and megabytes more of third-party code.
As designers, I’m sure we can tell ourselves all sorts of fairy tales about why intrusive pop-ups and overlays are the responsibility of some other department (as though users make any sort of distinction).
Worst of all, we’ve spent the last fifteen years teaching users that if they want a good experience on their mobile device, they should look in an app store, not on the web.
Ask anyone about their experience of using websites on their mobile device. They’ll tell you plenty of stories of how badly it sucks.
It doesn’t matter that the web is the perfect medium for just-in-time delivery of information. It doesn’t matter that web browsers can now do just about everything that native apps can do.
In many ways, I wish this were a technical problem. At least then we could lobby for some technical advancement that would fix this situation.
But this is not a technical problem. This is a people problem. Specifically, the people who make websites.
We fucked up. Badly. And I don’t see any signs that things are going to change anytime soon.
But hey, websites on desktop are just great!
A handy one-pager for front-end web developers:
Here are ways to keep track of what you can use, of what’s new in web browsers, and ways you can influence the development of the platform by making your voice heard.
About halfway through this talk transcript, Aaron starts dropping a barrage of truth bombs:
I understand the web, whose distinguishing characteristic is asynchronous recall on a global scale, as the technology which makes revisiting possible in a way that has genuinely never existed before the web.
What the web has made possible are the economics of keeping something, something which has not enjoyed “hockey stick growth”, around long enough for people to warm up to it. Or to survive long past the moment when people may have grown tired of it.
If your goal is to build something which is designed to flip inside of ten years, like many things in the private sector, that may not seem like a very compelling argument.
If, however, your goal is to build something to match the longevity of the cultural heritage sector, to meet the goal of fostering revisiting, or for novel ideas to outlast the reluctance of the present and to do so at a global scale, or really any scale larger than shouting distance, then I will challenge you to find a better vehicle for doing so than the internet, and the web in particular.
If you’re roughly 70% happy with a piece of writing you’ve produced, you should publish it.
Works for me!
You’re also expanding your ability to act in the presence of feelings of displeasure, worry and uncertainty, so that you can take more actions, and more ambitious actions, later on.
Crucially, you’ll also be creating a body of evidence to prove to yourself that when you move forward at 70%, the sky stubbornly fails to fall in. People don’t heap scorn on you or punish you.
This is absolutely wonderful!
There’s deep dives and then there’s Marcin’s deeeeeeep dives. Sit back and enjoy this wholesome detective work, all beautifully presented with lovely interactive elements.
This is what the web is for!
With the release of a new Salter Cane album I figured it was high time to update the design of the band’s website.
Here’s the old version for reference. As you can see, there’s a connection there in some of the design language. Even so, I decided to start completely from scratch.
I opened up a text editor and started writing HTML by hand. Same for the CSS. No templates. No build tools. No pipeline. Nothing. It was a blast!
And lest you think that sounds like a wasteful way of working, I pretty much had the website done in half a day.
Partly that’s because you can do so much with so little in CSS these days. Custom properties for colours, spacing, and fluid typography (thanks to Utopia). Logical properties. View transitions. None of this takes much time at all.
Because I was using custom properties, it was a breeze to add a dark mode with prefers-color-scheme. I think I might like the dark version more than the default.
The final stylesheet is pretty short. I didn’t bother with any resets. Browsers are pretty consistent with their default styles nowadays. As long as you’ve got some sensible settings on your body element, the cascade will take care of a lot.
There’s one little CSS trick I think is pretty clever…
The background image is this image. As you can see, it’s a rectangle that’s wider than it is tall. But the web pages are rectangles that are taller than they are wide.
So how I should I position the background image? Centred? Anchored to the top? Anchored to the bottom?
If you open up the website in Chrome (or Safari Technical Preview), you’ll see that the background image is anchored to the top. But if you scroll down you’ll see that the background image is now anchored to the bottom. The background position has changed somehow.
This isn’t just on the home page. On any page, no matter how tall it is, the background image is anchored to the top when the top of the document is in the viewport, and it’s anchored to the bottom when you reach the bottom of the document.
In the past, this kind of thing might’ve been possible with some clever JavaScript that measured the height of the document and updated the background position every time a scroll event is triggered.
But I didn’t need any JavaScript. This is a scroll-driven animation made with just a few lines of CSS.
@keyframes parallax {
from {
background-position: top center;
}
to {
background-position: bottom center;
}
}
@media (prefers-reduced-motion: no-preference) {
html {
animation: parallax auto ease;
animation-timeline: scroll();
}
}
}
This works as a nice bit of progressive enhancement: by default the background image stays anchored to the top of the viewport, which is fine.
Once the site was ready, I spent a bit more time sweating some details, like the responsive images on the home page.
But the biggest performance challenge wasn’t something I had direct control over. There’s a Spotify embed on the home page. Ain’t no party like a third party.
I could put loading="lazy" on the iframe but in this case, it’s pretty close to the top of document so it’s still going to start loading at the same time as some of my first-party assets.
I decided to try a little JavaScript library called “lazysizes”. Normally this would ring alarm bells for me: solving a problem with third-party code by adding …more third-party code. But in this case, it really did the trick. The library is loading asynchronously (so it doesn’t interfere with the more important assets) and only then does it start populating the iframe.
This made a huge difference. The core web vitals went from being abysmal to being perfect.
I’m pretty pleased with how the new website turned out.
- Springy easing with
linear()- Typed custom properties
- View transitions for page navigation
- Transition animation for
dialogandpopover- Transition animation for
details- Animated adaptive gradient text
If I was only able to give one bit of advice to any company: iterate quickly on a slow-moving platform.
Excellent advice from Harry (who first cast his pearls before the swine of LinkedIn but I talked him ‘round to posting this on his own site).
- Opt into web platform features incrementally
- Embrace progressive enhancement to build fast, reliable applications that adapt to your customers’ context
- Write code that leans into the browser, not away from it
I’m not against front-end frameworks, and, believe me, I’m not naive enough to believe that the only thing a front-end framework provides is soft navigations, but if you’re going to use one, I shouldn’t be able to smell it.
Remember when every company rushed to make an app? Airlines, restaurants, even your local coffee shop. Back then, it made some sense. Browsers weren’t as powerful, and apps had unique features like notifications and offline access. But fast-forward to today, and browsers can do all that. Yet businesses still push native apps as if it’s 2010, and we’re left downloading apps for things that should just work on the web.
This is all factually correct, but alas as Cory Doctorow points out, you can’t install an ad-blocker in a native app. To you and me, that’s a bug. To short-sighted businesses, it’s a feature.
(When I say “ad-blocker”, I mean “tracking-blocker”.)
I hold this truth to be self-evident: the larger the abstraction layer a web developer uses on top of web standards, the shorter the shelf life of their codebase becomes, and the more they will feel the churn.
Anselm isn’t talking about becoming a CSS wizard, but simply having an understanding of what CSS can do. I have had similar experiences to this:
In the past years I had various situations where TypeScript developers (they called themselves) approached me and asked whether I could help them out with CSS. I expected to solve a complex problem but for me — knowing CSS very well — it was always a simple, straightforward solution or code snippet.
Let’s face it, “full stack” usually means “JavaScript”—HTML and CSS aren’t considered worthy of consideration. Their loss.