Responsible Web Applications
An excellent collection of advice and examples for making websites responsive and accessibile (responsive + accessible = responsible).
An excellent collection of advice and examples for making websites responsive and accessibile (responsive + accessible = responsible).
Huh. I don’t think I ever thought about nesting media queries …and yet I’m pleasantly surprised that it works!
Remember when I wrote about Web Audio weirdness on iOS? Well, this is a nice little library that wraps up the same hacky solution that I ended up using.
It’s always gratifying when something you do—especially something that feels so hacky—turns out to be independently invented elsewhere.
Removing
media
support from HTML video was a mistake.
Damn right! It was basically Hixie throwing a strop, trying to sabotage responsive images. Considering how hard it is usually to remove a shipped feature from browsers, it’s bizarre that a good working feature was pulled out of production.
This is a useful technique that future me is almost certainly going to need at some point.
This is a very thoughtful and measured response to Alex’s post Platform Adjacency Theory.
Unlike Alex, the author doesn’t fire off cheap shots.
Also, I’m really intrigued by the idea of certificate authorities for hardware APIs.
A minimal style sheet that applies some simple rules to HTML elements so you can take a regular web page and drop in this CSS to spruce it up a bit.
Heydon’s newest short video is right up my alley.
My stack requires no maintenance, has perfect Lighthouse scores, will never have any security vulnerability, is based on open standards, is portable, has an instant dev loop, has no build step and… will outlive any other stack.
I like this proposal for a declarative Ajax pattern. It’s relatively straightforward to polyfill, although backward-compatibility is an issue because of existing browser behaviour with the target
attribute.
This is great! The folks at Basecamp are releasing the front-end frameworks they use to build Hey. There’s Turbo—the successor to Turbolinks:
It offers a simpler alternative to the prevailing client-side frameworks which put all the logic in the front-end and confine the server side of your app to being little more than a JSON API.
With Turbo, you let the server deliver HTML directly, which means all the logic for checking permissions, interacting directly with your domain model, and everything else that goes into programming an application can happen more or less exclusively within your favorite programming language. You’re no longer mirroring logic on both sides of a JSON divide. All the logic lives on the server, and the browser deals just with the final HTML.
Yes, this is basically Hijax (which is itself simply a name for progressive enhancement applied to Ajax) and I’m totally fine with that. I don’t care what it’s called when the end result is faster, more resilient websites.
Compare and contrast the simplicity of the Hotwire/Turbo approach to the knots that React is tying itself up in to try to get the same performance benefits.
It started using the magic spell of prominent results page display to get authors to use it. Nothing is left of the original lure of raising awareness for web performance, and nothing convincing is there to confirm it was, indeed, a usable “web component framework.”
This is a good round-up of APIs you can use to decide if and how much JavaScript to load. I might look into using storage.estimate()
in service workers to figure out how much gets pre-cached.
I really like the way that Amber doesn’t go straight to the end solution but instead talks through her thought process when adding a feature to her site.
I spent most of the weekend reading through this and I’ve still barely scratched the surface—a lot of work has gone to the analyses and write-ups!
The sections on accessibility and performance get grimmer each year but the raw numbers on framework adaption are refreshingly perspective-setting.
Find out how much smaller your JavaScript could be.
A reminder that the contens of custom properties don’t have to be valid property values:
From a syntax perspective, CSS variables are “extremely permissive”.
You’re not going to get a Webby Award or thousands of views on Codepen for how amazingly crafted your HTML is. You’ll need to be OK going unrecognized for your work. But know that every time I use a screen reader or keyboard on a site and it works correctly, I have a little spark of joy.
Chris is gathering end-of-year thoughts from people in response to the question:
What is one thing you learned about building websites this year?
Here’s mine.
In 2020, I rediscovered the enjoyment of building a website with plain ol’ HTML, CSS, and JavaScript — no transpilin’, no compilin’, no build tools other than my hands on the keyboard.
If we, as a community, start to appreciate the complexity of writing CSS, perhaps we can ask for help instead of blaming the language when we’re confused or stuck. We might also stop looking down on CSS specialists.