I’ve done this quite a bit: using ARIA attributes as “hooks” for styling and behaviour. It’s a way of thinking of accessibility as the baseline to build upon rather than something that can sprinkled on top later.
Tuesday, October 4th, 2022
I get it. React feels good and it’s sticky. But all frameworks eventually fizzle out.
Thanks to Web Components, large companies are realizing you don’t need to rebuild buttons and other UI primitives every few years. Teams don’t need to argue about frameworks anymore. You can have your cake and eat it too!
I think this may be the best long-term argument for web components:
Any org that goes all in on a single framework will eventually find themselves swimming upstream to hire talent to maintain legacy code and avoid framework rot. But you can reduce this burden (and the associated costs) by using Web Components in your design system.
Wednesday, September 21st, 2022
Spoiler: the answer to the question in the title is a resounding “hell yeah!”
Scott brings receipts.
Wednesday, September 14th, 2022
Matcalfe’s Law in action:
Companies keep choosing React because they know there’s a massive pool of candidates who know it; candidates keep learning React because they know companies are hiring for it. It’s a self-sustaining cycle.
But the problem is:
React isn’t great at anything except being popular.
Sunday, September 11th, 2022
Giving your future self a little credit with progressive enhancement - Blog - Pixo | Apps, websites, and software development
We often talk about technical debt — the costs we’ll need to pay in the future when we make short-term compromises. Progressive enhancement is the opposite of that — a sort of technical credit that will make things easier for us in the future.
A good explanation of how progressive enhancement works perfectly with the idea of a minimal viable product:
We focus first on a core experience that delivers what your users are looking for, and then we start adding enhancements that will delight them.
Tuesday, September 6th, 2022
The obvious answer to why you should build a website that doesn’t need
jsis… because some people don’t use
js. But how many?!
Tuesday, August 30th, 2022
A handy little script from Aaron to improve the form validation experience.
Wednesday, August 24th, 2022
New from Mr. Vanilla JS himself, Chris Ferdinandi:
A learning space for people who hate the complexity of modern web development.
It’ll be $29 a month or $299 a year (giving you two months worth for free).
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.
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!
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
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.
Thursday, June 30th, 2022
While I’ve always been bothered by the downsides of SPAs, I always thought the gap would be bridged sooner or later, and that performance concerns would eventually vanish thanks to things like code splitting, tree shaking, or SSR. But ten years later, many of these issues remain. Many SPA bundles are still bloated with too many dependencies, hydration is still slow, and content is still duplicated in memory on the client even if it already lives in the DOM.
Yet something might be changing: for whatever reason, it feels like people are finally starting to take note and ask why things have to be this way.
Interesting to see a decade-long perspective. I especially like how Sacha revisits and reasseses design principles from ten years ago:
- Data on the Wire. Don’t send HTML over the network. Send data and let the client decide how to render it.
It’s since become apparent that you often do need to send HTML over the network, and things seem to be moving back towards handling as much as possible of your HTML compilation on the server, not on the client.
Wednesday, June 29th, 2022
That’s the way to do it!
Concepts like progressive enhancement allow us to deliver the best experience possible to the majority of customers, while delivering a useful experience to those using older browsers.
Read on for the nitty-gritty details…
Monday, June 27th, 2022
Some thoughts—and kind words—prompted by my recent talk, In And Out Of Style.
Sunday, May 15th, 2022
Image previews with the FileReader API
I added a “notes” section to this website eight years ago. I set it up so that notes could be syndicated to Twitter. Ever since then, that’s the only way I post to Twitter.
A few months later I added photos to my notes. Again, this would get syndicated to Twitter.
Something’s bothered me for a long time though. I initially thought that if I posted a photo, then the accompanying text would serve as a decription of the image. It could effectively act as the
alt text for the image, I thought. But in practice it didn’t work out that way. The text was often a commentary on the image, which isn’t the same as a description of the contents.
I needed a way to store
alt text for images. To make it more complicated, it was possible for one note to have multiple images. So even though a note was one line in my database, I somehow needed a separate string of text with the description of each image in a single note.
I eventually settled on using the file system instead of the database. The images themselves are stored in separate folders, so I figured I could have an accompanying
alt.txt file in each folder.
Take this note from yesterday as an example. Different sizes of the image are stored in the folder
/images/uploaded/19077. Here’s a small version of the image and here’s the original. In that same folder is the
This means I’m reading a file every time I need the
alt text instead of reading from a database, which probably isn’t the most performant way of doing it, but it seems to be working okay.
Here’s another example:
In order to add the
alt text to the image, I needed to update my posting interface. By default it’s a little
textarea, followed by a file upload
input, followed by a toggle (a checkbox under the hood) to choose whether or not to syndicate the note to Twitter.
The interface now updates automatically as soon as I use that
input type="file" to choose any images for the note. Using the
FileReader API, I show a preview of the selected images right after the file input.
Here’s the code if you ever need to do something similar. I’ve abstracted it somewhat in that gist—you should be able to drop it into any page that includes
input type="file" accept="image/*" and it will automatically generate the previews.
I was pleasantly surprised at how easy this was. The
FileReader API worked just as expected without any gotchas. I think I always assumed that this would be quite complex to do because once upon a time, it was quite complex (or impossible) to do. But now it’s wonderfully straightforward. Story of the web.
My own version of the script does a little bit more; it also generates another little
textarea right after each image preview, which is where I write the accompanying
I’ve also updated my server-side script that handles the syndication to Twitter. I’m using the
/media/metadata/create method to provide the
alt text. But for some reason it’s not working. I can’t figure out why. I’ll keep working on it.
In the meantime, if you’re looking at an image I’ve posted on Twitter and you’re judging me for its lack of
alt text, my apologies. But each tweet of mine includes a link back to the original note on this site and you will most definitely find the
alt text for the image there.
Wednesday, May 11th, 2022
Broadly, these are websites which are still web pages, not web applications; they’re pages of essentially static information, personal websites, blogs, and so on, but they are slightly dynamic. They might have a style selector at the top of each page, causing a cookie to be set, and the server to serve a different stylesheet on every subsequent page load.
This rings sadly true to me:
Also, I never thought about “serverless” like this:
Recently we’ve seen the rise in popularity of AWS Lambda, a “functions as a service” provider. From my perspective this is literally a reinvention of CGI, except a) much more complicated for essentially the same functionality, b) with vendor lock-in, c) with a much more complex and bespoke deployment process which requires the use of special tools.
Wednesday, May 4th, 2022
This is a great case study of switching from a framework mindset to native browser technologies.
Though this is quite specific to Jack’s own situation, I do feel like there’s something in the air here. The native browser features are now powerful and stable enough to make the framework approach feel outdated.
And if you do want to use third-party dependencies, Jack makes a great case for choosing smaller single-responsibility helpers rather than monolithic frameworks.
Replacing lit-html would be an undertaking but much less so than replacing React: it’s used in our codebase purely for having our components (re)-render HTML. Replacing lit-html would still mean that we can keep our business logic, ultimately maintaining the value they provide to end-users. Lit-Html is one small Lego brick in our system, React (or Angular, or similar) is the entire box.
Tuesday, May 3rd, 2022
A while back I wrote a blog post called Web Audio API weirdness on iOS. I described a bug in Mobile Safari along with a hacky fix. I finished by saying:
If you ever find yourself getting weird but inconsistent behaviour on iOS using the Web Audio API, this nasty little hack could help.
Thanks so much for your post, this was a truly pernicious problem!
That warms the cockles of my heart. It’s very gratifying to know that documenting the bug (and the fix) helped someone out. Or, as I put it:
Yay for bugblogging!
Forgive the Germanic compound word, but in this case I think it fits.
Bugblogging doesn’t need to involve a solution. Just documenting a bug is a good thing to do. Recently I documented a bug with progressive web apps on iOS. Before that I documented a bug in Facebook Container for Firefox. When I documented some weird behaviour with the Web Share API in Safari on iOS, I wasn’t even sure it was a bug but Tess was pretty sure it was and filed a proper bug report.
I’ve benefited from other people bugblogging. Phil Nash wrote Service workers: beware Safari’s range request. That was exactly what I needed to solve a problem I’d been having. And then that post about Phil solving my problem helped Peter Rukavina solve a similar issue so he wrote Phil Nash and Jeremy Keith Save the Safari Video Playback Day.
Again, this warmed the cockles of my heart. Bugblogging is worth doing just for the reward of that feeling.
There’s a similar kind of blog post where, instead of writing about a bug, you write about a particular technique. In one way, this is the opposite of bugblogging because you’re writing about things working exactly as they should. But these posts have a similar feeling to bugblogging because they also result in a warm glow when someone finds them useful.
Here are some recent examples of these kinds of posts—tipblogging?—that I’ve found useful:
- Eric wrote about flexibly centering an element with side-sligned content using CSS.
- Rich documented how to subset a variable font on a Mac.
- Stephanie wrote about a CSS technique for animating in a newly added element.
Sunday, May 1st, 2022
Robin adds a long-zoom perspective on my recent post: