✻ Marcus Tisäter on how to make a PostCSS plugin. And how to do a good job while you're at it.

✻ Sarah Drasner on choosing animation technologies. She compares various approaches that she’s had experience with and breaks down the pros/cons of each method:
Having worked with a slew of them, I can tell you there is no right answer. It's a complicated question and complicated answer. This post serves to clarify what to use, and when, to get you working with the right tool for the job.
✻ Sarah has also dug into the history of visual regression testing and how, with CSS blend modes, it’s possible to compare two similar images in order to spot all the differences between them.

✻ Chris Coyier asks how front-end developers talk to designers when it comes to prepping their assets in Icons and Teams.

✻ Aleks Hudochenkov looks at how PostCSS can help us with images in CSS:
We all work with images in our CSS. Routine stuff. We may not even realize it, but there may be a lot of manual work involved that could be made a lot easier. I'm going to be showing you a variety of PostCSS plugins that are specifically designed to help with working with images in CSS.

What we’ve been reading, listening and watching

Nathan Curtis has some really good advice about making buttons in design systems:
Buttons are arguably a design system’s most important component. Devilishly simple, they offer a simple label in a defined region I can press. As such, buttons are where you apply a design language’s base attributes in ways that’ll ripple throughout more complex component later. Here’s 12 lessons I’ve learned when working the primary button, secondary buttons, and a whole host of other button types in an emerging system.
 
In other news around the web
 
A note from the archives

There are three properties required to truncate a single line of text with ellipsis. You know, like...

███  Don't feed gremlins after mi...  ███

It's easy to forget them. Good thing we have a reference snippet!

.truncate {
  white-space: nowrap;
  overflow: hidden;
  text-overflow: ellipsis;
}

 
❥ Sponsor: Great teams use HipChat
 
Stop losing momentum with reply-to-all wars and buried email messages. Cut to the chase with @mentions and get the answer you need. Try HipChat for free today!


What have you learnt this week?

Robin Rendle: A couple of years ago I wrote about the “other interface”, the one that developers and designers are constantly building for themselves—an interface made up of CSS classes that they have to navigate on a daily basis. I gave some thought as to how we might organise that CSS in order to make it more interface-like, by categorising each section into quarks, atoms and molecules.

In this way a developer would see how complex a particular bit of the codebase was and how far-reaching its effects would be too. At the time, I thought this was a really effective approach to writing CSS for large scale websites with lots of moving parts. But now my opinions have shifted dramatically.

Now I tend to build websites with a much greater number of smaller, interrelated bits in the style of Tachyons or BassCSS. In this fashion the author adds a class like .red or .border-top instead of making a much larger component like .profile-widget or something. This gives us lots of benefits, for example we can tell what’s going on just by looking at the markup instead of trawling through dozens of CSS files. However, many developers I’ve talked to despise this idea because they see it as if we’re writing inline styles again.

I just find it really interesting how many approaches to writing CSS are out there, and how quickly we’re willing to drop modern day “best-practices” in exchange for something else.

Until next time!
Team CSS-Tricks
Want to change how you receive these emails?
You can update your preferences or unsubscribe from this list.