Ethan, eloquent as always, on the inaccessibly of AMP Stories:
Conjecture aside, here’s what I do know: the AMP team decided that each of these Story demos was worth showcasing on the official page for AMP Stories. And that sends a powerful signal about where the priorities for AMP Story sit. The content in each AMP Story is wonderful, the visual designs are effective—but if you use a screen reader, each Story is an assault on your senses. And by showcasing these demos, the AMP team is signaling that’s entirely acceptable.
It reminds me of Surma’s comments about JS frameworks and performance:
Unless a globally launched framework labels itself as exclusively targeting the users of the Wealthy Western Web, it has a responsibility to help developers target every phone on The Widening Performance Gap™️ spectrum.
It’s a big responsibility, but if you’re shipping something that will be this widely used, you’ve got a responsibility to make the default state as secure, accessible and performant as possible.
That’s particularly true for something that makes as bold a claim, as aggressively, as AMP has always done.
Remy building on someone else’s (smart!) post about lazy-loading YouTube embeds.
Gosh I miss when this “someone blogs and then someone else iterates on that on their own blog” thing was more common.
Surma argues, compellingly, for why web workers need to take a more prominent role in JS-based applications. It’s not just about the raw performance benefits, but the inclusivity that good performance brings.
Unless a globally launched framework labels itself as exclusively targeting the users of the Wealthy Western Web, its has a responsibility to help developers target every phone on The Widening Performance Gap™️ spectrum.
I always associated prefers-reduced-motion with CSS, but of course the picture element accepts media queries!
A quick post from Brad showing how you can use the picture element to serve up a static image instead of an animated gif when the “reduce motion” preference is enabled.
Examples like this are why I love how the whole suite of responsive images standards (srcset, sizes and picture) turned out. I know some weren’t as pleased with the final product, but there’s so much darn flexibility (ahem) here to enable us to account for scenarios, like this, that only really emerged after those standards were created.
For government, GOV.UK is often the only place a user can get information. If the website were to perform badly, we become a single point of failure.
Great rundown of why performance is so important to GOV.UK and how the context of their visitors can vary dramatically, even within the same city.
In this post, we’ll look at the new loading attribute which brings native <img> and <iframe> lazy-loading to the web!
Exciting to finally see this ship! Folks have been asking for a standards-based way to support lazy-loading images for years.
Gives me hope that maybe, someday, we’ll have element queries.
When we’re evaluating technologies for appropriateness, I hope that we will do so through the lens of what’s best for users, not what we feel compelled to use based on a gnawing sense of irrelevancy driven by the perceived popularity of newer technologies.
I always like seeing how other folks handle performance audits. Here, Jake walks through 10 F1 sites, auditing them primarily with WebpageTest and a smattering of Chrome Dev Tools.
Academic background or not, technical education doesn’t stop once you get a job. On the contrary: nothing in tech stays in one place, and the single most valuable skill you can possess to remain employable over time is learning how to learn.
Some great advice here from Sarah on learning.
Handy little reference from Addy Osmani showing how Chrome handles JavaScript scheduling.