An Interactive Guide to Flexbox in CSS
This is a superb explanation of flexbox—the interactive widgets sprinkled throughout are such a great aid to learning!
This is a superb explanation of flexbox—the interactive widgets sprinkled throughout are such a great aid to learning!
Reminder:
em
andrem
work with the user’s font size;px
completely overrides it.
I appreciate Hidde’s reluctance to participate in anything that looks like a pile-on, but in this case, it’s important to call out the bad behaviour so it doesn’t happen again.
The specific issues I’ve put in this post cross the line between honest mistakes and bad behaviour. They cross the line, because they consistute fraud (the livestream) and because they impact attendees, sponsors and speakers. The front-end community doesn’t deserve this, and I’m worried for people new to the industry, who get may assume this is normal or ok. It’s not normal.
It sounds like Remix takes a sensible approach to progressive enhancement.
More on that shitshow of an event that Jo wrote about, this time from Cassie.
I’ve heard from multiple people about how much of a shitshow this event was. Worth remembering in case they try to pull the same shit again.
What happens if the ‘pace layers’ get out of sync?
A very thoughtful post by Miriam on how tools can adversely affect the pace of progress in the world of web standards.
When tools intervene between you and your access to the web platform, proceed with caution. Ask not only: How well does it work? But also: How well does it fail? Not only: What features do they provide? But also: What features do they prevent?
Here’s a remarkably in-depth timeline of the web’s finest programming language, from before it existed to today’s thriving ecosystem. And the timeline is repsonsive too—lovely!
A good ol’ rant by Vasilis on our design tools for the web.
Here’s a short fifteen minute video (and transcript) of an interview I did about accessibility and inclusive design. I quite like how it turned out!
When I wrote about my hopes and fears for the View Transitions API, a few people latched on to this sentiment:
If the View Transitions API only works for single page apps, it could be the single worst thing to happen to the web in years.
But I also wrote:
If the View Transitions API works across page navigations, it could be the single best thing to happen to the web in years.
I think it’s worth focusing on that.
Part of the problem is that I gave my hopes and fears an equal airing. But they’re not equally likely.
Take the possibility that the View Transitions API only ships for single page apps, but never ships for regular page transitions. The consequences of that would be big—the API would act as an incentive to build single page apps. But the likelihood of that happening is small. In fact, according to Jake, there’s already an implemention for page transitions in the works at Chrome.
Now what if the View Transitions API ships for pages? The consequences would be equally big—the API would act as an incentive to ditch single page apps and build in a more performant, resilient way. Best of all, the chances of that happening are very large indeed (pretty much a certainty now, given Jake’s update).
So I made a comparison between both of the consequences, which are equally large, but I didn’t make a corresponding comparison of the likelihoods, which are not equally large. Mea culpa!
I should’ve made it clearer that, although the consequences would be really bad if the View Transitions API only supports single page apps, the actual likelihood of that is pretty slim.
That’s probably my negativity bias showing through. (The reason I have a negativity bias is because I am a human. Like, have you ever noticed that if you get feedback on something and 98% of it is positive, you inevitably fixate on the 2%?)
Anyway, the real takeaway here is that if the View Transitions API ships for pages, then the consequences will be really, really good! It would be another nail in the coffin for monolithic JavaScript frameworks slowing down the web. And best of all, the likelihood of this happening is very high!
So let me amend my closing sentences from my previous post:
If the View Transitions API only works for single page apps—which is very unlikely—it could be the single worst thing to happen to the web in years.
If the View Transitions API works across page navigations—which is very, very likely—it could be the single best thing to happen to the web in years.
The glass is half full and it’s only going to get fuller. Time to start planning for a turbo-charged web now.
If you’ve got a website with full page navigations, start thinking about how you’ll be able to apply the View Transitions API as a progressive enhancement to improve the user experience.
If you’ve got a single page app, start thinking about how to ditch a whole bunch of uneccessary dependencies to make a more lightweight foundation of HTML instead of JavaScript, and still get all those slick transitions you get in a single page app!
I am simultaneously very excited and very nervous about the View Transitions API.
You may know it by its former name—Shared Element Transitions. The name change is very recent.
I’ve been saying for years that some kind of API like this would be brilliant:
I honestly think if browsers implemented this, 80% of client-rendered Single Page Apps could be done as regular good ol’-fashioned websites.
Miriam Suzanne describes the theory of View Transitions succinctly:
Shared-element transitions are designed to work with standard web navigation across multiple page loads, as well as page transitions in ‘single-page’ apps (often called SPAs).
This all sounds brilliant. But the devil is in the implementation details. Right now, the API only works for single page apps. This is totally understandable. For purely pragmatic reasons, single page apps are a simple use case to solve for. It’s going to take a lot more work to get this API to work for multi-page apps (or as we used to call them, websites).
If we get a View Transitions API that works across page navigations, it could potentially turbo-charge the web. It will act as a disencentive to building single page apps—you’d be able to provide swish transitions without sacrificing performance or resilience at the alter of a heavy-handed JavaScript-only architecture.
But if the API only ever works for single page apps (which is the current situation), then it will act as an incentive to make any kind of website into a single page app, regardless of whether it’s actually the appropriate architecture.
That prospect has me very worried indeed.
I’m making my feelings on this known just in case any of the implementators out there are thinking, “Hey, maybe it’s fine that this API only works for single page apps—I’m sure most people would be happy with that.”
If the View Transitions API works across page navigations, it could be the single best thing to happen to the web in years.
If the View Transitions API only works for single page apps, it could be the single worst thing to happen to the web in years.
Update: Jake says:
We’re currently landing code in Chrome for the MPA version.
Very happy to hear that! It’s already in the spec, but it’s good to hear that the implementation isn’t going to lag too much.
Also, read this follow-up.
I think this might be the most excited I’ve been in quite some time about an update to browser support, which probably says a lot about my priorities:
Support for the
avoid
value of the CSS fragmentation propertiesbreak-before
,break-after
, andbreak-inside
when printing.
Finally!
It’s been almost two years since I added audio playback on The Session. The interface is quite straightforward. For any tune setting, there’s a button that says “play audio”. When you press that button, audio plays and the button’s text changes to “pause audio.”
By updating the button’s text like this, I’m updating the button’s accessible name. In other situations, where the button text doesn’t change, you can indicate whether a button is active or not by toggling the aria-pressed
attribute. I’ve been doing that on the “share” buttons that act as the interface for a progressive disclosure. The label on the button—“share”—doesn’t change when the button is pressed. For that kind of progressive disclosure pattern, the button also has an aria-controls
and aria-expanded
attribute.
From all the advice I’ve read about button states, you should either update the accessible name or change the aria-pressed
attribute, but not both. That would lead to the confusing situation of having a button labelled “pause audio” as having a state of “pressed” when in fact the audio is playing.
That was all fine until I recently added some more functionality to The Session. As well as being able to play back audio, you can now adjust the tempo of the playback speed. The interface element for this is a slider, input type="range"
.
But this means that the “play audio” button now does two things. It plays the audio, but it also acts as a progressive disclosure control, revealing the tempo slider. The button is simultaneously a push button for playing and pausing music, and a toggle button for showing and hiding another interface element.
So should I be toggling the aria-pressed
attribute now, even though the accessible name is changing? Or is it enough to have the relationship defined by aria-controls
and the state defined by aria-expanded
?
Based on past experience, my gut feeling is that I’m probably using too much ARIA. Maybe it’s an anti-pattern to use both aria-expanded
and aria-pressed
on a progressive disclosure control.
I’m kind of rubber-ducking here, and now that I’ve written down what I’m thinking, I’m pretty sure I’m going to remove the toggling of aria-pressed
in any situation where I’m already toggling aria-expanded
.
What I really need to do is enlist the help of actual screen reader users. There are a number of members of The Session who use screen readers. I should get in touch and see if the new functionality makes sense to them.
I’ve smelt the same change in the wind that Chris describes here—there’s finally a reckoning happening in the world of JavaScript frameworks and single page apps.
I’ve seen the pendulum swing back and forth many times over my years building on the web. I too feel like there’s something in the air right now, and people are finally acknowledging that most single page apps are crap.
But Brad makes the interesting point that, because they were incubated when profligate client-side JavaScript was all the rage, web components may have ended up inheriting the wrong mindset:
So now the world of web components has egg on its face because the zeitgeist at the time of its design didn’t have such a strong focus on SSR/HTML-first/ progressive enhancement. Had web components been designed in the current zeitgeist, things would almost certainly be different.
A recurring theme in my writing and talks is “lay off the JavaScript, people!” But I have to make a conscious effort to specify that I mean client-side JavaScript.
I thought it would be obvious from the context that I was talking about the copious amounts of JavaScript being shipped to end users to download, parse, and execute. But nothing’s ever really obvious. If I don’t explicitly say JavaScript in the browser, then someone inevitably thinks I’m having a go at JavaScript, the language.
I have absolutely nothing against JavaScript the language. Just like I have nothing against Python or Ruby or any other language that you might write with on your machine or your web server. But as soon as you deliver bytes over the wire, I start having opinions. It just so happens that JavaScript is the universal language for client-side coding so that’s why I call for restraint with JavaScript specifically.
There was a time when JavaScript only existed in web browsers. That changed with Node. Now it’s possible to write code for your web server and code for web browsers using the same language. Very handy!
But just because it’s the same language doesn’t mean you should treat it the same in both circumstance. As Remy puts it:
There are two JavaScripts.
One for the server - where you can go wild.
One for the client - that should be thoughtful and careful.
I was reading something recently that referred to Eleventy as a JavaScript library. It really brought me up short. I mean, on the one hand, yes, it’s a library of code and it’s written in JavaScript. It is absolutely technically correct to call it a JavaScript library.
But in my mind, a JavaScript library is something you ship to web browsers—jQuery, React, Vue, and so on. Whereas Eleventy executes its code in order to generate HTML and that’s what gets sent to end users. Conceptually, it’s like the opposite of a JavaScript library. Eleventy does its work before any user requests a URL—JavaScript libraries do their work after a user requests a URL.
To me it seems obvious that there should an entirely different mindset for writing code intended for a web browser. But nothing’s ever really obvious.
I remember when Node was getting really popular and npm
came along as a way to manage all the bundles of code that people were assembling in their Node programmes. Makes total sense. But then I thought I heard about people using npm
to do the same thing for client-side code. “That can’t be right!” I thought. I must’ve misunderstood. So I talked to someone from npm
and explained how I must be misunderstanding something.
But it turned out that people really were treating client-side JavaScript no different than server-side JavaScript. People really were pulling in megabytes of other people’s code to ship to end users so that they could, I dunno, left pad numbers or something.
Listen, I don’t care what you get up to in the privacy of your own codebase. But don’t poison the well of the web with profligate client-side JavaScript.
A demonstration of how even reinventing a relatively simple wheel takes way more effort than it’s worth when you could just use what the brower gives you for free.
If, like me, you despair at the tech stacking and JavaScriptification of everything, shut that out and pay attention to those who understand the material of the web, its inherent resilience and efficiency. We’re lucky that principled voices still advocate for simple and inclusive methods because building with efficiency and a lightness of touch makes the work feel meaningful and, sometimes, fun.
There are two JavaScripts.
One for the server - where you can go wild.
One for the client - that should be thoughtful and careful.
Yes! This! I’m always astounded to see devs apply the same mindset to backend and frontend development, just because it happens to be in the same language. I don’t care what you use on your own machine or your own web server, but once you’re sending something down the wire to end users, you need to prioritise their needs over your own.
It’s the JavaScript on the client side that’s the problem. What’s given to the visitor.
I’d ask you, if you’re still reading, that you consider a separation of JavaScript between client and server. If you’re a dev, consider the payload, your bundle and work to reduce the cost to your visitor. Heck, think progressive enhancement.