Here’s a little snippet of CSS that solves a problem I’ve never considered:
The problem is that Live Text, “Select text in images to copy or take action,” is enabled by default on iOS devices (Settings → General → Language & Region), which can interfere with the contextual menu in Safari. Pressing down on the above link may select the text inside the image instead of selecting the link URL.
How often do we, as frontend engineers, overlook the URL as a state management tool? We reach for all sorts of abstractions to manage state such as global stores, contexts, and caches while ignoring one of the web’s most elegant and oldest features: the humble URL.
I had a very pleasant experience last week while I was reading through the RSS feeds I’m subscribed to. I came across two blog posts that were responding to blog posts of my own.
Robin Sloan wrote a post clarifying his position after I linked to him in my post about the slipperiness of the term “AI”.
Then Jim Nielsen wrote a deliciously satirical piece in response to my pithy little parable about research.
I love it when this happens!
Elizabeth Spiers recently wrote a piece called What Made Blogging Different?:
And if they wanted to respond to you, they had to do it on their own blog, and link back. The effect of this was that there were few equivalents of the worst aspects of social media that broke through.
It’s so true. I feel like a response from someone’s own website is exponentially more valuable than a response on Bluesky, Mastodon, Instagram, or any other social media platform.
Don’t get me wrong: I absolutely love the way that Brid.gy will send those social-media responses right back here to my own site in the form of webmentions. It also pings me whenever someone likes or shares a post of mine. But I’ve noticed that I’m not that interested in those anymore.
Maybe those low-investment actions were carried over from the old days of Twitter just because that’s the way things were always done, without us really asking whether they serve much purpose.
Right now I accept these likes and shares as webmentions. I display a tally of each kind of response under my posts. But I’m not sure why I’m doing it. I don’t particularly care about these numbers. I’m pretty sure no one else cares either.
If I cared, then they’d be vanity metrics. As it is they’re more like zombie metrics. I should probably just put them out of their misery.
A URL shortener that’s dodgy by design.
I was thinking about something I wrote yesterday when I was talking about styling underlines on links:
For a start, you can adjust the distance of the underline from the text using
text-underline-offset. If you’re using a generous line-height, use a generous distance here too.
For some reason, I completely forgot that we’ve got a line-height unit in CSS now: lh. So if you want to make the distance of your underline proportional to the line height of the text that the link is part of, it’s easy-peasy:
text-underline-offset: 0.15lh;
The greater the line height, the greater the distance between the link text and its underline.
I think this one is going into my collection of CSS snippets I use on almost every project.
We shouldn’t rely on colour alone to indicate that something is interactive.
Take links, for example. Sure, you can give them a different colour to the surrounding text, but you shouldn’t stop there. Make sure there’s something else that distinguishes them. You could make them bold. Or you could stick with the well-understood convention of underlying links.
This is where some designers bristle. If there are a lot of links on a page, it could look awfully cluttered with underlines. That’s why some designers would rather remove the underline completely.
I’ve done a lot of audits in the first half of this year and at this point a believe that designing links without underlines is a kink. The idea that users don’t understand that links are clickable arouses some designers. I can’t explain it any other way.
But underlining links isn’t the binary decision it once was. You can use CSS to style those underlines just as you’d style any other part of your design language.
Here’s a regular underlined link.
For a start, you can adjust the distance of the underline from the text using text-underline-offset. If you’re using a generous line-height, use a generous distance here too.
Here’s a link with an offset underline.
If you’d rather have a thinner or thicker underline, use text-decoration-thickness.
Here’s a link with a thin underline.
The colour of the underline and the colour of the link don’t need to be the same. Use text-decoration-color to make them completely different colours or make the underline a lighter shade of the link colour.
Here’s a link with a translucent underline.
That’s quite a difference with just a few CSS declarations:
text-underline-offset: 0.2em;
text-decoration-thickness: 1px;
text-decoration-color: oklch(from currentColor l c h / 50%);
If that still isn’t subtle enough for you, you could even use text-decoration-style to make the underline dotted or dashed, but that might be a step too far.
Here’s a link with a dotted underline.
Whatever you decide, I hope you’ll see that underlines aren’t the enemy of good design. They’re an opportunity.
You should use underlines to keep your links accessible. But you should also use CSS to make those underlines beautiful.
- Support open source software
- Support open web platform technology
- Distribution on the web should never be throttled
- External links should be encouraged, not de-emphasized
People spent a lot of time and energy in 2024 talking about (and on) other people’s websites. Twitter. Bluesky. Mastodon. Even LinkedIn.
I observed it all with the dispassionate perspective of Dr. Manhattan on Mars. While I’m happy to see more people abondoning the cesspool that is Twitter, I’m not all that invested in either Mastodon or Bluesky. Or any other website, for that matter. I’m glad they’re there, but if they disappeared tomorrow, I’d carry on posting here on my own site.
I posted to my website over 850 times in 2024.
I shared over 350 links.
I posted over 400 notes.
I published just one article.
And I wrote almost 100 blog posts here in my journal this year.
Here are some cherry-picked highlights:
Hypertext links are an information-density multiplier.
The way I’ve long thought about it is that traditional writing — like for print — feels two-dimensional. Writing for the web adds a third dimension. It’s not an equal dimension, though. It doesn’t turn writing from a flat plane into a full three-dimensional cube. It’s still primarily about the same two dimensions as old-fashioned writing. What hypertext links provide is an extra layer of depth. Just the fact that the links are there — even if you, the reader, don’t follow them — makes a sentence read slightly differently. It adds meaning in a way that is unique to the web as a medium for prose.
This is how I write:
As an online writer, my philosophy is link maximalism; links add another layer to my writing, whether I’m linking to an expansion of a particular idea or another person’s take, providing evidence or citation, or making a joke by juxtaposing text and target. Links reveal personality as much as the text. Linking allows us to stretch our ideas, embedding complexity, acknowledging ambiguity, holding contradictions.
David is on board. Who else?
I was having a discussion with some of my peers a little while back. We were collectively commenting on the state of education and documentation for front-end development.
A lot of the old stalwarts have fallen by the wayside of late. CSS Tricks hasn’t been the same since it got bought out by Digital Ocean. A List Apart goes through fallow periods. Even the Mozilla Developer Network is looking to squander its trust by adding inaccurate “content” generated by a large language model.
The most obvious solution is to start up a brand new resource for front-end developers. But there are two probems with that:
I actually think there are plenty of good articles and resources on front-end development being published. But they’re not being published in any one specific place. People are publishing them on their own websites.
Ahmed, Josh, Stephanie, Andy, Lea, Rachel, Robin, Michelle …I could go on, but you get the picture.
All this wonderful stuff is distributed across the web. If you have a well-stocked RSS reader, you’re all set. But if you’re new to front-end development, how do you know where to find this stuff? I don’t think you can rely on search, unless you have a taste for slop.
I think the solution lies not with some hand-wavey “AI” algorithm that burns a forest for every query. I think the solution lies with human curation.
I take inspiration from Phil’s fantastic project, ooh.directory. Imagine taking that idea of categorisation and applying it to front-end dev resources.
Whether it’s a post on web.dev, Smashing Magazine, or someone’s personal site, it could be included and categorised appropriately.
Now, there would still be a lot of work involved, especially in listing and categorising the articles that are already out there, but it wouldn’t be nearly as much work as trying to create those articles from scratch.
I don’t know what the categories should be. Does it make sense to have top-level categories for HTML, CSS, and JavaScript, with sub-directories within them? Or does it make more sense to categorise by topics like accessibility, animation, and so on?
And this being the web, there’s no reason why one article couldn’t be tagged to simultaneously live in multiple categories.
There’s plenty of meaty information architecture work to be done. And there’d be no shortage of ongoing work to handle new submissions.
A stretch goal could be the creation of “playlists” of hand-picked articles. “Want to get started with CSS grid layout? Read that article over there, watch this YouTube video, and study this page on MDN.”
What do you think? Does this one-stop shop of hyperlinks sound like it would be useful? Does it sound feasible?
I’m just throwing this out there. I’d love it if someone were to run with it.
There’s a new addition to the latest version of Chrome called speculation rules. This already existed before with a different syntax, but the new version makes more sense to me.
Notice that I called this an addition, not a standard. This is not a web standard, though it may become one in the future. Or it may not. It may wither on the vine and disappear (like most things that come from Google).
The gist of it is that you give the browser one or more URLs that the user is likely to navigate to. The browser can then pre-fetch or even pre-render those links, making that navigation really snappy. It’s a replacement for the abandoned link rel="prerender".
Because this is a unilateral feature, I’m not keen on shipping the code to all browsers. The old version of the API required a script element with a type value of “speculationrules”. That doesn’t do any harm to browsers that don’t support it—it’s a progressive enhancement. But unlike other progressive enhancements, this isn’t something that will just start working in those other browsers one day. I mean, it might. But until this API is an actual web standard, there’s no guarantee.
That’s why I was pleased to see that the new version of the API allows you to use an external JSON file with your list of rules.
I say “rules”, but they’re really more like guidelines. The browser will make its own evaluation based on bandwidth, battery life, and other factors. This feature is more like srcset than source: you give the browser some options, but ultimately you can’t force it to do anything.
I’ve implemented this over on The Session. There’s a JSON file called speculationrules.js with the simplest of suggestions:
{
"prerender": [{
"where": {
"href_matches": "/*"
},
"eagerness": "moderate"
}]
}
The eagerness value of “moderate” says that any link can be pre-rendered if the user hovers over it for 200 milliseconds (the nuclear option would be to use a value of “immediate”).
I still need to point to that JSON file from my HTML. Usually this would be done with something like a link element, but for this particular API, I can send a response header instead:
Speculation-Rules: “/speculationrules.json"
I like that. The response header is being sent to every browser, regardless of whether they support speculation rules or not, but at least it’s just a few bytes. Those other browsers will ignore the header—they won’t download the JSON file.
Here’s the PHP I added to send that header:
header('Speculation-Rules: "/speculationrules.json"');
There’s one extra thing I had to do. The JSON file needs to be served with mime-type of “application/speculationrules+json”. Here’s how I set that up in the .conf file for The Session on Apache:
<IfModule mod_headers.c>
<FilesMatch "speculationrules.json">
Header set Content-type application/speculationrules+json
</FilesMatch>
</IfModule>
A bit of a faff, that.
You can see it in action on The Session. Open up Chrome or Edge (same same but different), fire up the dev tools and keep the network tab open while you navigate around the site. Notice how hovering over a link will trigger a new network request. Clicking on that link will get you that page lickety-split.
Mind you, in the case of The Session, the navigations were already really fast—performance is a feature—so it’s hard to guage how much of a practical difference it makes in this case, but it still seems like a no-brainer to me: taking a few minutes to add this to your site is worth doing.
Oh, there’s one more thing to be aware of when you’re implementing speculation rules. You have the option of excluding URLs from being pre-fetched or pre-rendered. You might need to do this if you’ve got links for adding items to shopping carts, or logging the user out. But my advice would instead be: stop using GET requests for those actions!
Most of the examples given for unsafe speculative loading conditions are textbook cases of when not to use links. Links are for navigating. They’re indempotent. For everthing else, we’ve got forms.
Mark’s write-up of the excellent Indie Web Camp Brighton that he co-organised with Paul.
The past weekend’s Indie Web Camp Brighton was wonderful! Many thanks to Mark and Paul for all their work putting it together.
There was a great turn-out. It felt like the perfect time for an Indie Web Camp. There’s a real appetite for getting away from ever more extractive silos and staking claim to our own corners of the web. Most of the attendees were at their first ever Indie Web Camp.
Paul asked me to oversee the schedule planning on day one, which I was happy to do. We made sure that first-timers got first dibs on proposing sessions. In the end, every single session was proposed by new attendees.
Day two was all about putting ideas into practice: coding, designing, and writing on our own website. I’m always blown away by how much gets done in just one short day. Best of all is when there’s someone who starts the weekend without their own website but finishes with a live site. That happened again this time.
I spent the second day tinkering with something I started at Indie Web Camp Nuremberg in October. Back then, I got related posts working here on my journal; a list of suggested follow-up posts to read based on the tags of the current post.
I wanted to do the same for my links; show links related to the one I’m currently linking to. It didn’t take too long to get that up and running.
But then I thought about it some more and realised it would be good to also show blog posts related to the link. So I did that. Then I realised it would be really good to show related links under blog posts too.
So now, if everything’s working correctly, then at the end of this post you will not only see related blog posts I’ve previously written, but also links related to the content of this post.
It was a very inspiring weekend. There’s something about being in a room with other people working on their websites that makes me super productive.
While we were hacking away on day two, somebody mentioned that they still find hard to explain the indie web to people.
“It’s having your own website”, I said.
But surely there’s more to it than that, they wondered.
Nope. If someone has their own website, then they’re part of the indie web. It doesn’t matter if that website is made with a complicated home-rolled tech stack or if it’s a Squarespace site.
What you do with your own website is entirely up to you. The technologies are just plumbing wether it’s webmentions, RSS, or anything else. None of it is a requirement. Heck, even HTML is optional. If you want to put plain text files on your website, go for it. It’s your website.
Subvert the status quo. Own a website. Make and share links.
In the same vein as that last link, Chris says what we’re all thinking:
Most of what we build is links from one page to another, and
formsubmissions that send data from the browser to the server.
A fascinating look at the connections between hypertext and film editing. I’m a sucker for any article that cites both Ted Nelson and Walter Murch.
One of the first ever personal websites—long before the word “blog” was a mischievous gleam in Peter’s eye—was Justin Hall’s links.net. Linking was right there in the domain name.
I really enjoy sharing links on my website. It feels good to point to something and say, “Hey, check this out!”
Other people are doing it too.
Then there are some relatively new additions to the linking gang:
There are more out there for you to discover and add to your feed reader of choice. Good link hunting!
Next time you’re frustrated by a website that doesn’t provide an RSS feed, try using this tool:
Transform any old website with a list of links into an RSS Feed