[Robin]: Here’s a smart take from Eric Bailey: just because we have evergreen browsers doesn’t mean we can use the latest features. “Evergreen browsers” here meaning browsers like Chrome and Firefox that update automatically without you having to do anything. Except, well, Eric shows how folks might not restart their machine or the browser itself and so they might not be getting the latest features:
Support from all evergreen browsers on caniuse.com does not necessarily mean support exists on the device a person is using—updates that have been “pushed” out don’t automatically get instantly applied.
[…] I advocate for tempering your excitement with some restraint. It can be very tempting to rush and use the new and the shiny. Believe me, I’m not exempt from this urge—CSS is about to go from great to amazing, and the urge to use new features is very real.
Instead, wait a bit. Work with the platform’s ability to create progressively enhanced experiences with CSS and JavaScript.
This sounds like a sad thing that we all should lament, but I think that this is perhaps one of the best things about working on the web. For example, Eric argues that we can use feature detection to detect if a browser can use the latest features in CSS like the upcoming subgrid…
.component {
/* Base appearance */
}
@supports (grid-template-columns: subgrid;) {
.component {
/* Styling and positioning enhancement tweaks if subgrid is supported */
}
}A lot of folks might feel annoyed that they have to build two interfaces here: one for the old way of doing things, and one for the new. But by progressively enhancing our interfaces ensures that we can provide the best experience to the highest number of users. We never have to leave folks behind.
All this is super interesting though because I’ve taken evergreen browsers for granted and never really thought about all the reasons why they might not update as magically as you think. Jim Nielsen wrote about this just the other day when he talked about a problem he discovered thanks to his mom. It’s a real interesting story but this was the takeaway for me:
In my brain, I always thought of Safari and Chrome as “modern” browsers. But even Chrome, an “evergreen” browser, failed because it wasn’t on an “evergreen” operating system (or hardware).
So what Eric and Jim’s posts remind me here is that even folks on the best hardware running the most up-to-date software benefit from progressive enhancement. And the more resiliency we build into our websites then the better off everyone is for it.
Scroll ’til you drop
The other day Michelle Barker made this scrollable and draggable timeline of Radiohead’s discography and dang it feels swish as all heck. At the top of this page you can scroll left or right and the content beneath will scroll up and down in response.
Michelle then wrote about how she built it which shows just how much time was spent thinking about accessibility alongside these fancy animations. Each time you get to a new section, the text floats up slightly and the album art rotates but it doesn’t feel janky like some similar animations I’ve seen before. Instead, it’s effortlessly smooth.
Speaking of scrolling, Mary Lou made a lovely scrolling demo where each column in the interface below scrolls in different directions. It feels unfamiliar but also extremely cool at the same time.
This demo is built on Locomotive Scroll, a library that helps us do weird things with scrolling. You can animate elements at different speeds or stagger elements to pop out at different times. It’s pretty neat. On that note, King Nelson wrote about how to get started with that library and all the possibilities it unlocks.
These demos use a third-party library, but what if it was possible to control regular ol’ CSS animations just by scrolling natively? What if browsers let us link animations with scrolling? Well! Bramus wrote about this new and upcoming feature coming to a browser near you called Scroll-Linked Animations. Earlier this year, he also went ahead and rebuilt Mary Lou’s demo above just using this scroll-linked animations feature which is pretty darn neat.
I am in one of two minds about this. The examples here are super interesting but with everything when it comes to scrolling and animations, we have to be careful. It’s really, really easy to get this stuff wrong and make a wretched website experience.
So I like this suggestion from Chris where he checks first to see if users have turned animations off, and then does the fancy stuff after the fact:
@media (prefers-reduced-motion: no-preference) {
@supports (animation-timeline: works) {
/* Do fancy stuff */
}
}One block to rule them all
One design pattern that is almost not worth mentioning these days because it’s like oxygen to the modern web is this: blocks. Ganesh Dahal wrote a deep-dive into the WordPress site editor which is built entirely on the concept of blocks.
A block could be anything; text, an image, a table. Notion is built on this concept, too. When you’re in a document, just hit / and a whole world of possibilities open up. You can make a database! Or create a whole new page! And then you can move these things around to your heart’s content.
The interesting thing about this design pattern is that it’s entirely custom. There’s no “blocks standard” written in a spec somewhere deep on the W3C website, or documented officially as part of a standards body or anything. Notion has its idea of blocks, and WordPress has theirs. Two separate systems which do kinda the same thing under the hood.
Well, that could change soon, as Joel Spolsky introduced the Block protocol the other day:
I thought, wouldn’t it be cool if blocks were interchangeable and reusable across the web?
Until now, every app that wants blocks has to implement them from scratch. Want a calendar block? Some kind of fancy Kanban board? Something to embed image galleries? Code it up yourself, buddy.
As a result of the non-standardization of blocks, our end-users suffer. If someone is using my blog engine, they can only use those blocks that I had time to implement. Those blocks may be pretty basic or incomplete. Users might want to use a fancier block that they saw in WordPress or Medium or Notion, but my editor doesn’t have it. Blocks can’t be shared or moved around very easily, and our users are limited to the features and capabilities that we had time to re-implement.
The Block protocol asks that we make the data that we pipe into these blocks similar so that we can all benefit from an enormous library of them in the future. It’s a really neat idea that I’m entirely onboard with.
Will developers use this standard when they’re making block patterns? And is this really going to help users in the end or is this just going to speed up developers? I’m interested to see how this shakes out.
Sponsor
Astra DB
Build ecommerce, crypto and gaming apps. Ops on us. Do more with Astra DB, the only database-as-a-service that helps developers build Apache Cassandra™ apps faster—without the cost of self-managed operations. Get started today.
Sponsor
Real-Time Backups For All
Jetpack now includes comprehensive, real-time backups for your WordPress site in each of our Backup and Security plans. Don’t pay for storage space you don’t need — instead, pay based on the size of your site.
[Chris]: There is some degree of pushback and classic tech drama around the Block Protocol stuff Robin talked about above. There is positive stuff. Like hey, I love blocks! I love the concept of blocks in WordPress’ Block Editor. I love the concept of blocks in Notion. I feel like blocks have been a real sea change for the better in how content is created and managed. A natural evolution of the rich text area.
The friction comes in because there a lot of people who have been working on an API surface for “blocks” for the web for a long time. As Dave put it in our ShopTalk Discord:
It has been 0️⃣ days since people invented Web Components.
Which elicits certain auditory cues from people involved with those. The docs suggest:
Blocks are web components. We suggest writing them using React, a ready-made framework for writing web components.
Justin says this in response to that:
One of the team members replied to me that they didn’t want to dictate how you implement a block, so they didn’t want to require WCs – but that indicates that they think a WC is the implementation rather than the interface and they said they could provide a library to abstract over embedding blocks built with different frameworks – but that’s what web components already do!
The model for these blocks is clearly inspired by WordPress, as the intro blog post makes clear in the first paragraph. And WordPress blocks are React components, so clearly there is some synergy there. Part of me doesn’t blame either of them, as the DX story of web components has been rough. That synergy clearly has some legs:
Sounds like the Blocks Protocol people are up for considering Web Components more seriously, which I would think would be at least worth exploring. These are all people involved who have hugely benefited from open source and open platform work their entire careers, seems like that would be a strong long-term move here.