[Robin]: I still haven’t found myself reaching for Web Components yet and I’m not sure why. I assume because most of my time is spent with either Static Site Generators or very large Single Page Applications written in React. But the idea makes a ton of sense to me, as Caleb Williams describes in An Introduction to Web Components:
The shadow DOM is an encapsulated version of the DOM. This allows authors to effectively isolate DOM fragments from one another, including anything that could be used as a CSS selector and the styles associated with them. Generally, any content inside of the document’s scope is referred to as the light DOM, and anything inside a shadow root is referred to as the shadow DOM.
Later Caleb writes that “the shadow DOM works sort of like an <iframe>” where you don’t have to worry about any of the styles within it conflicting with anything outside of it and vice versa. Or, to put it another way: browser-native encapsulation like CSS modules. But I’ve been thinking about this stuff because I really enjoyed this other piece by Richard MacManus about How Web Components Are Used at GitHub and Salesforce. For example, it’s interesting to hear that the reason why the front-end team at GitHub reached for web components (they now have more than 50!) is because they don’t use a JavaScript framework like React or Vue.
The GitHub team built components such as the tab-container element and it looks like there’s a great list called github-elements which captures most of them. I’ve been flipping through these and it seems like there’s a ton of stuff to learn here about building great Web Components.
Scroll-Linked Animations with @scroll-timeline
This post is called “The Future of CSS: Scroll-Linked Animations with @scroll-timeline” and I’d normally roll my eyes at being told what the future is, but dang this really does feel like something magical, like something that CSS hasn’t been able to do before. Like this:
Isn’t that remarkable? Here’s the gist: changing CSS when a user scrolls has basically been impossible to do in the past without JavaScript. You’d have to detect the event and then change the DOM or add a class somewhere.
But now with the Scroll-linked Animations Specification—which is an experimental feature only available in Chromium 89 right now—we can detect when a user scrolls and then animate elements accordingly. Like I said: magic.
Bramus Van Damme writes exhaustively in this post about how to get started and what’s possible. Here are two examples. The first is where you might want to animate content in…
…and the second is one where you might want to animate a scrollbar at the top of the page…
To make the scrollbar example, we first need to tell the browser the length of the scrolling duration. We can do that with this new CSS @scroll-timeline property and give it a name (like “progress-timeline” below):
@scroll-timeline progress-timeline {
time-range: 1s;
}Next up, we need to create our plain ol’ CSS animation and apply them both to the element that we want to animate:
@keyframes adjust-progressbar {
from {
transform: scaleX(0);
}
to {
transform: scaleX(1);
}
}
#progressbar {
animation: 1s linear forwards adjust-progressbar;
animation-timeline: progressbar-timeline;
}That last line there feels really weird but it’s where all the magic is. You can do a lot more complex things than this but it’s a good starting place to get an idea of how these CSS properties will replace a whole bunch of JavaScript for us in the future.
I’m really excited for this to land in browsers without any flags.
Exploring @property and its Animating Powers
Speaking of exciting new CSS features that haven’t quite landed in browsers, here’s one more: @property. Jhey Tomkins has the scoop:
[…] perhaps the most interesting thing is that it provides a way to specify a type for custom CSS properties. A type provides more contextual information to the browser, and that results in something cool: We can give the browser the information it needs to transition and animate those properties!
In short: Because we can tell the browser what type of property something is we can now animate a whole bunch of things that we were never able to before. Not so long ago, Una Kravets wrote about how we can animate gradients using @property. Take a look:
Impressive huh? In Jhey’s post, he shows that animating colors doesn’t have to be subtle; they can be absolutely gobsmacking and utterly striking:
You can also animate number counters with @property too which is neat.
But I have a feeling that we’ve only begun to scratch the surface of what’s possible with @property, and even trying to figure out what we can do with it makes my head spin. For example, with nothing but CSS and HTML, we can now create an actual honest-to-goodness stopwatch:
Sponsor
Fauna
Jamstack needs a serverless database! Fauna helps you simplify code, reduce costs, and ship faster, by delivering powerful database capabilities as a data API with support for GraphQL and custom business logic.
Sponsor
Netlify
Most CDN services will have you choose between caching aggressively and having to wait for updates to go live, or do no caching on your HTML files — which mean you’re not benefitting from the CDN layer at all for those files. With Netlify, you get the best of both worlds. Once your build is uploaded, we flip the switch and it goes live — the changes in your build are instantly pushed to our global CDN.
[Chris]: Blogging is the coolest. I like doing it and even more I like reading yours. You can blog any dang ol’ thing you want, from long-form dissertations to one-sentence quips, from tutorials to photographs, and even from recipes to link posts to other blog posts. But, lately, I have been thinking a bit about what makes a really good blog post.
This occured to me when Andrew Walpole’s Through the pipeline: An exploration of front-end bundlers. It’s full of typos, unfinished thoughts, and really could have used a good edit (sorry, Andrew). But still, I love it because it’s the kind of blog post I like to read. I wrote:
I really like the kind of tech writing where a fellow developer lays out some specific needs, tries out different tech to fulfill those needs, and documents how it went for them.
I think people really connect with Dan Abramov’s writing for that same reason. Even though Dan is often the face of React, Dan doesn’t always go for the latest news or get into the deepest technical nitty-gritty, which would be a tempting lure for blog posts. His post “Before you memo()” is about performance optimization. He acknowledges that there is a sea of posts about this topic and summarizes them. Then he lays out an understandable situation and applies performance tweaks to them through architecture alone without reaching for more complex tools. It makes for a satisfying read. Like: “this is a good thought that went through my mind and I’m going to lay it out here.” It’s also not-too-long and not-too-short, so it has a baby bear thing going on.
Jeremy Keith has a knack for this, too. Sometimes Jeremy will go on little benders about something. I think the term “Design Engineer” got in his head the other week. When that happens, you’ll get a little flurry of links about the topic, and then usually a culminating journal entry, like this.
I also love a good blog post that makes me green with envy. I love reading about CSS, of course, and nobody is blogging about CSS better than Stephanie Eckles, Michelle Barker, and Ahmad Shadeed these days. I gotta up my game, people!