A stylesheet for when you’re nostalgic for the old Mac OS.
Thursday, August 18th, 2022
Following on from that excellent blog post about removing jQuery from gov.uk, here are the performance improvements in charts and numbers.
Tuesday, August 16th, 2022
When I wrote about democratising dev, I made brief mention of the growing “no code” movement:
Personally, I would love it if the process of making websites could be democratised more. I’ve often said that my nightmare scenario for the World Wide Web would be for its fate to lie in the hands of an elite priesthood of programmers with computer science degrees. So I’m all in favour of no-code tools …in theory.
But I didn’t describe what no-code is, as I understand it.
By that definition, something like WordPress.com (as opposed to WordPress itself) is a no-code tool:
Create any kind of website. No code, no manuals, no limits.
I’d also put Squarespace in the same category:
Start with a flexible template, then customize to fit your style and professional needs with our website builder.
And its competitor, Wix:
Discover the platform that gives you the freedom to create, design, manage and develop your web presence exactly the way you want.
Webflow provides the same kind of service, but with a heavy emphasis on marketing websites:
Your website should be a marketing asset, not an engineering challenge.
Bubble is trying to cover a broader base:
Bubble lets you create interactive, multi-user apps for desktop and mobile web browsers, including all the features you need to build a site like Facebook or Airbnb.
Wheras Carrd opts for a minimalist one-page approach:
Simple, free, fully responsive one-page sites for pretty much anything.
All of those tools emphasise that don’t need to need to know how to code in order to have a professional-looking website. But there’s a parallel universe of more niche no-code tools where the emphasis is on creativity and self-expression instead of slickness and professionalism.
Create your own free website. Unlimited creativity, zero ads.
Make a website in 5 minutes. Messy encouraged.
unique tool for web publishing & internet samizdat
I’m kind of fascinated by these two different approaches: professional vs. expressionist.
I’ve seen people grapple with this question when they decide to have their own website. Should it be a showcase of your achievements, almost like a portfolio? Or should it be a glorious mess of imagery and poetry to reflect your creativity? Could it be both? (Is that even doable? Or desirable?)
Robin Sloan recently published his ideas—and specs—for a new internet protocol called Spring ’83:
It’s not a no-code tool (you need to publish in HTML), although someone could easily provide a no-code tool to sit on top of the protocol. Conceptually though, it feels like it’s an a similar space to the chaotic good of neocities.org, mmm.page, and hotglue.me with maybe a bit of tilde.town thrown in.
It feels like something might be in the air. With Spring ’83, the Block protocol, and other experiments, people are creating some interesting small pieces that could potentially be loosely joined. No code required.
My website has different themes you can choose from. I don’t just mean a dark mode. These themes all look very different from one another.
I assume that 99.99% of people just see the default theme, but I keep the others around anyway. Offering different themes was originally intended as a way of showcasing the power of CSS, and specifically the separation of concerns between structure and presentation. I started doing this before the CSS Zen Garden was created. Dave really took it to the next level by showing how the same HTML document could be styled in an infinite number of ways.
Each theme has its own stylesheet. I’ve got a very simple little style switcher on every page of my site. Selecting a different theme triggers a page refresh with the new styles applied and sets a cookie to remember your preference.
I also list out the available stylesheets in the
head of every page using
link elements that have
rel values of
stylesheet together. Each
link element also has a
title attribute with the name of the theme. That’s the standard way to specify alternative stylesheets.
In Firefox you can switch between the specified stylesheets from the
View menu by selecting
Page Style (notice that there’s also a
No style option—very handy for checking your document structure).
Other browsers like Chrome and Safari don’t do anything with the alternative stylesheets. But they don’t ignore them.
Every browser makes a network request for each alternative stylesheet. The request is non-blocking and seems to be low priority, which is good, but I’m somewhat perplexed by the network request being made at all.
I get why Firefox is requesting those stylesheets. It’s similar to requesting a print stylesheet. Even if the network were to drop, you still want those styles available to the user.
But I can’t think of any reason why Chrome or Safari would download the alternative stylesheets.
Monday, August 15th, 2022
This is kind of brilliant:
Maybe what’s needed for websites and web apps is a kind of Prepper Web Dev?
Thursday, August 11th, 2022
This is a great thorough description of the process of migrating gov.uk away from jQuery. It sounds like this guide was instrumental in the process—I love that they’re sharing it openly!
Adrian brings an excellent historical perspective to the horrifying behaviour of Facebook’s in-app browsers:
Somewhere along the way, despite a reasonably strong anti-framing culture, framing moved from being a huge no-no to a huge shrug. In a web context, it’s maligned; in a native app context, it’s totally ignored.
Yup, frames are back—but this time they’re in native apps—with all their shocking security implications:
By the way, this also explains that when you try browsing the web in an actual web browser on your mobile device, every second website shoves a banner in your face saying “download our app.” Browsers offer users some protection. In-app webviews offer users nothing but exploitation.
Wednesday, August 10th, 2022
I met up with a supersmart programmer friend of mine a little while back. He was describing some work he was doing with React. He was joining up React components. There wasn’t really any problem-solving or debugging—the individual components had already been thoroughly tested. He said it felt more like construction than programming.
My immediate thought was “that should be automated.”
Or at the very least, there should be some way for just about anyone to join those pieces together rather than it requiring a supersmart programmer’s time. After all, isn’t that the promise of design systems and components—freeing us up to tackle the meaty problems instead of spending time on the plumbing?
I thought about that conversation when I was listening to Laurie’s excellent talk in Berlin last month.
Chatting to Laurie before the talk, he was very nervous about the conclusion that he had reached and was going to share: that the time is right for web development to be automated. He figured it would be an unpopular message. Heck, even he didn’t like it.
But I reminded him that it’s as old as the web itself. I’ve seen videos from very early World Wide Web conferences where Tim Berners-Lee was railing against the idea that anyone would write HTML by hand. The whole point of his WorldWideWeb app was that anyone could create and edit web pages as easily as word processing documents. It’s almost an accident of history that HTML happened to be just easy enough—but also just powerful enough—for many people to learn and use.
Anyway, I thoroughly enjoyed Laurie’s talk. (Except for a weird bit where he dunks on people moaning about “the fundamentals”. I think it’s supposed to be punching up, but I’m not sure that’s how it came across. As Chris points out, fundamentals matter …at least when it comes to concepts like accessibility and performance. I think Laurie was trying to dunk on people moaning about fundamental technologies like languages and frameworks. Perhaps the message got muddled in the delivery.)
I guess Laurie was kind of talking about this whole “no code” thing that’s quite hot right now. Personally, I would love it if the process of making websites could be democratised more. I’ve often said that my nightmare scenario for the World Wide Web would be for its fate to lie in the hands of an elite priesthood of programmers with computer science degrees. So I’m all in favour of no-code tools …in theory.
The problem is that unless they work 100%, and always produce good accessible performant code, then they’re going to be another example of the law of leaky abstractions. If a no-code tool can get someone 90% of the way to what they want, that seems pretty good. But if that person than has to spend an inordinate amount of time on the remaining 10% then all the good work of the no-code tool is somewhat wasted.
Funnily enough, the person who coined that law, Joel Spolsky, spoke right after Laurie in Berlin. The two talks made for a good double bill.
(I would link to Joel’s talk but for some reason the conference is marking the YouTube videos as unlisted. If you manage to track down a URL for the video of Joel’s talk, let me know and I’ll update this post.)
In a way, Joel was making the same point as Laurie: why is it still so hard to do something on the web that feels like it should be easily repeatable?
He used the example of putting an event online. Right now, the most convenient way to do it is to use a third-party centralised silo like Facebook. It works, but now the business model of Facebook comes along for the ride. Your event is now something to be tracked and monetised by advertisers.
You could try doing it yourself, but this is where you’ll run into the frustrations shared by Joel and Laurie. It’s still too damn hard and complicated (even though we’ve had years and years of putting events online). Despite what web developers tell themselves, making stuff for the web shouldn’t be that complicated. As Trys put it:
We kid ourselves into thinking we’re building groundbreakingly complex systems that require bleeding-edge tools, but in reality, much of what we build is a way to render two things: a list, and a single item. Here are some users, here is a user. Here are your contacts, here are your messages with that contact. There ain’t much more to it than that.
And yet here we are. You can either have the convenience of putting something on a silo like Facebook, or you can have the freedom of doing it yourself, indie web style. But you can’t have both it seems.
This is a criticism often levelled at the indie web. The barrier to entry to having your own website is too high. It’s a valid criticism. To have your own website, you need to have some working knowledge of web hosting and at least some web technologies (like HTML).
Don’t get me wrong. I love having my own website. Like, I really love it. But I’m also well aware that it doesn’t scale. It’s unreasonable to expect someone to learn new skills just to make a web page about, say, an event they want to publicise.
That’s kind of the backstory to the project that Joel wanted to talk about: the block protocol. (Note: it has absolutely nothing to do with blockchain—it’s just an unfortunate naming collision.)
The idea behind the project is to create a kind of crowdsourced pattern library—user interfaces for creating common structures like events, photos, tables, and lists. These patterns already exist in today’s silos and content management systems, but everyone is reinventing the wheel independently. The goal of this project is make these patterns interoperable, and therefore portable.
At first I thought that would be a classic
/927 situation, but I’m pleased to see that the focus of the project is not on formats (we’ve been there and done that with microformats, RDF, schema.org, yada yada). The patterns might end up being web components or they might not. But the focus is on the interface. I think that’s a good approach.
That approach chimes nicely with one of the principles of the indie web:
UX and design is more important than protocols, formats, data models, schema etc. We focus on UX first, and then as we figure that out we build/develop/subset the absolutely simplest, easiest, and most minimal protocols and formats sufficient to support that UX, and nothing more. AKA UX before plumbing.
That said, I don’t think this project is a cure-all. Interoperable (portable) chunks of structured content would be great, but that’s just one part of the challenge of scaling the indie web. You also need to have somewhere to put those blocks.
Convenience isn’t the only thing you get from using a silo like Facebook, Twitter, Instagram, or Medium. You also get “free” hosting …until you don’t (see GeoCities, MySpace, and many, many more).
Wouldn’t it be great if everyone had a place on the web that they could truly call their own? Today you need to have an uneccesary degree of technical understanding to publish something at a URL you control.
I’d love to see that challenge getting tackled.
Wednesday, August 3rd, 2022
Much as I appreciate the optimism of this evaluation, I don’t hold out much hope that people’s expectations are going to change any time soon:
Indeed, when given a choice, users will opt for the [native] app version of a platform because it’s been considered the gold standard for reliability. With progressive web apps (PWAs), that assumption is about to change.
Nonetheless, this is a level-headed look at what a progressive web app is, mercifully free of hand-waving:
- App is served through HTTPS.
- App has a web app manifest with at least one icon. (We’ll talk more about the manifest shortly.)
- App has a registered service worker with a fetch event handler. (More on this later too.)
Tuesday, August 2nd, 2022
Are you a web dev that’s into progressive enhancement, accessibility, design systems, and all that good stuff?
You should come and work with me at Clearleft.
Wednesday, July 27th, 2022
The day we started to allow email clients to be full-blown web browsers (but without the protections of browsers) was the day we lost — time, security, privacy, and effectiveness. Now we spend all our time fighting with the materials of an email (i.e. color and layout) rather than refining its substance (i.e. story and language).
I really, really enjoyed this deep dive into practical HTML semantics. Sit back and enjoy!
The algorithm I’m going after is pretty simple: If the grid of items has an odd number of items, then make the first item full-width. But CSS can’t do logic… right? Well… hold my proverbial beer.
Tuesday, July 26th, 2022
Prompted by my recent post about using native
button elements, Trys puts forward a simple explanation for why someone would choose to use a
The one common feature between every codebase I’ve encountered on that doesn’t use
buttons well, is a bad CSS reset. Developers try to use a
button, and find that it still looks like a native browser button, so they grab a plain old, blank canvas
div, and build from there.
Occam’s Razor makes Trys’s explanation the most likely one.
Monday, July 25th, 2022
- a button,
- a dropdown, and
- a datepicker.
In each case you could use native HTML elements:
Or you could use
In the case of a dropdown, it’s less clear-cut. Personally, I’d use a
select element. While it’s currently impossible to style the open state of a
select element, you can style the closed state with relative ease. That’s good enough for me.
Personally, I think chasing pixel-perfect consistency across platforms isn’t even desirable, but I get it. I too would like to have more control over styling
select elements. That’s one of the reasons why the work being done by the Open UI group is so important.
But there’s one more component: a button.
Again, you could use the native
button element, or you could use a
div or a
Now, in this case, I must admit that I just don’t get it. Why wouldn’t you just use the native
button element? It has no styling issues and the browser gives you all the interactivity and accessibility out of the box.
I’ve been trying to understand the mindset of a developer who wouldn’t use a native
button element. The easy answer would be that they’re just bad people, and dismiss them. But that would probably be lazy and inaccurate. Nobody sets out to make a website with poor performance or poor accessibility. And yet, by choosing not to use the native HTML element, that’s what’s likely to happen.
I think I might have finally figured out what might be going on in the mind of such a developer. I think the issue is one of control.
When I hear that there’s a native HTML element—like
select—that comes with built-in behaviours around interaction and accessibility, I think “Great! That’s less work for me. I can just let the browser deal with it.” In other words, I relinquish control to the browser (though not entirely—I still want the styling to be under my control as much as possible).
But I now understand that someone else might hear that there’s a native HTML element—like
select—that comes with built-in behaviours around interaction and accessibility, and think “Uh-oh! What if there unexpected side-effects of these built-in behaviours that might bite me on the ass?” In other words, they don’t trust the browsers enough to relinquish control.
I get it. I don’t agree. But I get it.
But I don’t think it’s a great mindset for the web. The web is filled with uncertainties—browsers, devices, networks. You can’t possibly account for all of the possible variations. On the web, you have to relinquish some control.
Still, I’m glad that I now have a bit more insight into why someone would choose to attempt to retain control by using
Monday, July 18th, 2022
I really enjoyed Laurie’s talk in Berlin a few weeks back. I must blog my thoughts on it.
But I must admit that something didn’t sit quite right about the mocking tone he took on the matter of “the fundamentals” (whatever that may mean). Chris shares my misgivings:
Those websites that don’t load on slow connections, or break completely when a JS file fails to load, or don’t work for people with visual or physical impairments?
That’s not an issue of time. It’s an issue of fundamentals.
I think I agree with Laurie that there’s basically no such thing as fundamental technologies (and if there is such a thing, the goalposts are constantly moving). But I agree with Chris with that there is such a thing as fundamental concepts. On the web, for example, accessibility is a core principle of its design that should, in my opinion, be fundamental.
Do I wanna see teenagers building frivolous websites? Absolutely. But when people are getting paid well to build our digital world, they have a responsibility to ensure the right to engage with that world for everyone.
Sunday, July 17th, 2022
Thursday, July 14th, 2022
I love this kind of spelunking into the history of why things are they way they are on the web!
Here, Detective Chief Inspector Suzanne tries to get to the bottom of why every browser has eight pixels of margin applied to the
body element in the user-agent stylesheet.
Wednesday, July 13th, 2022
If only all thinkpieces on complexity in software development were written in such an entertaining style! (Although, admittedly, that would get very old very fast.)
A layman’s guide to thinking like the self-aware smol brained
Tuesday, July 12th, 2022
The headline is clickbaity, but the advice is solid. Use progressive enhancement and don’t worry about polyfilling.
When I say ‘Stop supporting IE’ it means to me that I won’t go the extra mile to get unsupported features working in Internet Explorer, but still make sure Internet Explorer users get the basics, and can use the site.