#230: Animate Everything by 1%

[Robin]: Animations are important, but deadly. They can focus our attention on certain bits of information at just the right time, they can be for fun when you’ve hit a button, and animations can also be used to make you trust a website, app, video game, or bit of software even more than if they weren’t there are at all.

When the animations are smooth and don’t get in the way, that’s the sign of a truly outstanding website (to me).

But! When I use a site with too many animations I feel like it slows me down and I start to distrust it all. Video games do this too—the character crouches to pick up an item, reaches out to grab it, then they look at it, then stash it away. It’s exhausting! Just let me have fun!

Web designers like us can learn a lot about animations from video games, especially because a lot of these animations are unnecessary and feel just like load screens to me. As I’ve been thinking about all this, it’s sort of led me to this completely un-researched and un-scientific conclusion: I feel like we should animate absolutely everything, but only by 1%.

Take big swooshy animations that pop up when a page loads. Those are extremely distracting to me—I begin to notice the animation instead of the content—and it feels like a barrier to entry. But a tiny swoosh that animates in or out quickly? That’s extremely elegant and my attention is drawn to the content more so than how cool the developer was when they wrote that complex SVG animation.

Subtlety is important when it comes to animation design because otherwise they can get in the way and frustrate folks. It only takes a tiny bit of movement for your eye to notice it too, and just because we can animate everything on a webpage in and out, doesn’t necessarily mean we should.

(Except by 1%.)

Animation is like typography in that way: you can make a big and bold declaration with a flash of something interesting but you can’t keep doing it over and over again. It gets both boring and annoying. So I’ve been trying to keep this in mind whenever I crack open my text editor and jump into @keyframes and the like.

When it comes to animations, subtlety is the key.

Hell Yes! CSS!

Julia Evans wrote this fantastic zine all about how her approach to writing CSS changed over time. That’s partly due to so much to learn beyond just the syntax of the language; you need to understand stacking contexts and how certain properties affect other properties.

Julia writes:

Once you learn some of the basic weird things, it’s much easier to approach your CSS problems with the confidence that you can actually understand them. And then you can start learning from your CSS bugs (“oh, margin: auto behaves differently depending on whether the parent is a flexbox? Ok, good to know!!“), which means that every weird CSS situation you run into will make you a little bit better at CSS.

The examples she set up on the site to support the zine are really great, too.

On this note, Tim Severien wrote about why he believes CSS is difficult to master and, much like Julia, he breaks down each part of the language that he finds particularly odd.

I think Tim nails it: it’s not just memorizing the properties of CSS (although there’s a lot to remember if you want to build a modern website), it’s the hidden relationships between these properties that makes the language so difficult. And this is what I sort of make reference to when I looked into the flex-grow, flex-shrink, and flex-basis properties not so long ago.

So I’d say that CSS isn’t particularly difficult to grasp, but the relationships we build on top of it can be extremely complex and difficult to understand. Or maybe another way to put it is this: the language is easy but the system is hard.

End of Year Thoughts

We continue to publish end of year thoughts from a ton of interesting front-end folks and I enjoyed this one especially from Manuel Matuzovic about keeping up with technology:

At some point, I surrendered. I decided for myself that I can’t keep up. Professionally it changed nothing for me because, in reality, no one expected me to know everything and this impression I had was only happening in my bubble anyway. Slowing down was a brilliant decision because it wasn’t just a mental relief, it also helped me focus on the things I actually wanted to learn. I still read newsletters, blogs and Twitter, and I still take some time to try something new every now and then, but I do it without pressure. I try to keep up-to-date but I don’t feel the urge to know everything.

I struggle with this a lot still, wanting to be on the bleeding edge of all things web development but finding myself slipping up in lots of areas; I haven’t played around with Next.js yet, I haven’t built anything with Gatsby, I haven’t experimented with Vue, or with lots of features of CSS Grid. There’s so much to learn and so little time!

After stressing myself out thoroughly, I began reading Cassidy Williams’s great post about how everything old is new again, and how a lot of web development skills last for a pretty long time. I especially loved this bit:

I’m very optimistic about the future of web development right now. There are a lot of smart brains experimenting with these technologies, and there’s a lot of education happening in the space right now. It reminds me of the phrase, “a rising tide lifts all boats.” We’re all trying to build the best websites we can right now, and though it might seem like it’s competitive, I’m very hopeful about how much we can be “lifted” together by collective learning.

Heck yeah! I feel the same way. But also: double heck! Even container queries are being seriously discussed today which is perhaps the last thing on my web design bucket list.

Completely unrelated—but just as interesting—is this post by Eric Portis about why security on the web is pretty great:

Browsing the web is basically going around running other people’s untrusted and potentially malicious code, willy-nilly, all day long. The principles that underly web security and privacy — including the Same-Origin Policy — enable this safety, and must be defended absolutely.

I’ve never really understood the Same Origin Policy before and I think this post clarifies a ton of questions I had about them.

Finally, I read this piece from Ire Aderinokun who wrote about what she’s been up to this year and she admits: not much. “[U]ltimately,” Ire writes, “I’ve found that my way of building websites hasn’t changed all that much this year. And more importantly, it didn’t have to.”

I love this sentiment! Just because we’re building websites doesn’t mean we have to build things with the latest tech to make ourselves feel powerful and strong. But the other part that caught my attention is this bit of the post:

I also trialed Tailwind to see what a radically different way of writing CSS (or in this case, not writing CSS) could be like. This was a really fun trial and although I’ve gone back to my good-ole-SCSS, I have taken with me the idea of utility CSS classes. For example, I now create utility classes for things like aligning text, so the line text-align: center; is only written once in my CSS file.

This has me thinking, I’m not sure I agree that everything should be built with utility classes like Tailwind. I’ve tried systems like that in the past and it just… doesn’t work for me. I’d prefer to create a component and see all the styles listed clearly rather than in a shorthand syntax in the markup that both I and another developer in the future have to learn. But! There’s a lot of times we want to modify a component in this way. Using CSS helpers, or utility classes, is great because it means you can make very specific components that do one thing and then modify them after the fact for that edge case.

Merico Build

Like a fitness tracker for your code. Our analytics empower developers by letting your code speak for itself with metrics, badges, and dashboards for self-improvement and career growth. See how you measure up and translate commits into insights, for free.

WooCommerce Mobile App: Create and Sell Products Anywhere

WooCommerce just shipped an update to its mobile app. Until now, the app has always been a great way to keep tabs on your WordPress e-commerce shop. But with the latest release, it’s possible to create products directly in the app! This is the most holistic WooCommerce experience yet, giving you more ways to create and sell products from anywhere.

Get the app →

Psst… Automattic is hiring! If you’ve been hunting for a new job, there are tons of openings and one of them might just have your name written all over it. Check them out!

[Chris]: The spec CSS Inline Layout Module Level 3 has some really interesting properties in it related to typesetting. Particularly, these beauties:

h1 { 
  text-edge: cap alphabetic;
  leading-trim: both;

Ethan Wang for Microsoft:

Just as the name suggests, it works like a text box scissor. You can trim off all the extra space from reference points of your choice with just two lines of CSS.

Robin mentioned this a while ago, and pointed out Caleb Williams article about all this that demonstrates the extreme hoops we need to jump through today if we want this behavior. Once we have it, we can align type with other visual element much more naturally:

But no hoop-jumping once we get the native CSS stuff.

I wonder if Mark here is right?

Calling it now. Once we have 'leading-trim' in CSS, it'll be the new 'box-sizing: border-box' — something everyone manually applies to every element on every site, leaving us to wonder why it wasn't the default from the beginning.

Assuming there aren’t like weird bad performance implications to this (there rarely are in CSS), he might be right. We still get the benefit of what line-height does, only more intuitively (space between lines), but the weird half of it on top and bottom are gone, alone with the extra-weird random space that fonts apply that we have no control over. Knowing that we’ll have the ability to do better alignment (“the most underrated design skill”) is highly appealing and I can imagine all of us wanting it everywhere all the time.