This week we cover GIF-making, clever CSS animations, and the languages which almost became CSS. So let’s begin!

From the blog

Ana Tudor recreates the Twitter heart animation with the checkbox hack. But what’s super interesting here is the way in which Ana builds the particles that surround the heart animation. The heart is a unicode heart in a label. The circle is a pseudo element on that label. ALL the particles are box shadows on the other psuedo element. Fannnncy.

✻ Vikas Lalwani shows us how to build a word counter app that calculates the number of characters, words, sentences and paragraphs as we type. Vikas also explores how to use an API in order to test the readability of our text:

✻ Chris shows us a couple of ways to make a GIF:

Sometimes for blog posts. Sometimes for tweets. Sometimes for documentation. Sometimes for fun. GIFs can be tremendously useful and communicate better than a still image or even video in some circumstances.

✻ Yaphi Berhanu looks at the potential dangers of third-party scripts:

The web is full of third-party scripts. Sites use them for ads, analytics, retargeting, and more. But this isn’t always the whole story. Scripts can track your behavior, your preferences, and other information.

✻ Over the last nine months, Aydin Hassan has helped build PHP School which is a free and open source platform for learning the language. Just like Node School, you learn via the command line by actually writing code.

What we’ve been reading, listening and watching

Earlier this week Zack Bloom wrote about some of the languages which almost became CSS, the early predecessors that were in the running for the same job. And it’s so interesting to see the ways in which other languages influenced the design of CSS itself:

Compared to many of the other proposals, one notable fact of CSS is its simplicity. It can be easily parsed, easily written, and easily read. As with many other examples over the history of the Internet, it was the technology which was easiest for a beginner to pick up which won, rather than those which were most powerful for an expert. It is itself a reminder of how incidental much of this innovation can be.

Also, the details element can be quite useful in GitHub issues to hide blocks of text until needed. It might be helpful to think of details as a collapsed accordion that works without any CSS or JS:

And finally, Tim Kadlec reminded us about a neat trick in Chrome’s DevTools which is very much like Sublime’s Command Palette. When you hit CMD+SHIFT+P then you can jump to ‘Resources’ or ‘Console’ or the ‘Network’ tab. So now you don’t have to move your mouse to navigate DevTools.

A note from the archives

A couple of months ago, Dee and Chris sat down to talk about some ways in which to style a particular component on a website. It’s super neat to see the two think their way through layout questions and whether or not to use Flexbox depending on the circumstances.

Laying Things Out (HTML & Flexbox) with Dee Gill

What have you learnt this week?

Robin Rendle: I’ve just started work on the largest, most complex CSS codebase that I’ve ever encountered. It’s quite scary. The rules that worked so well in freelance life, the rules that I could depend upon to write CSS, no longer apply here. This is because the team can’t simply get every developer to start writing BEM or using CSS Modules or thinking about immutable CSS.

These tricks don’t take long to master but their implementation can’t be allowed to be half baked. In many instances, using these techniques would actually damage the current state of things, as there would be yet another standard with which we have to adhere to when we write code.

So I’m wondering where to start; how should I organise hundreds of people to think about CSS in the right way? And subsequently, what is “the right way” to think about CSS when I’m only used to “the right way” for a single developer?

I think the solution to this problem, of writing maintainable CSS in a large organization, requires just as much time looking at the codebase as it does speaking to designers and developers about their expectations. After interviews and research I think I’ve boiled it down to this: how much of the current CSS is predictable? When a designer or a developer writes some code, which is the part that they have complete confidence in? And which are the parts that make them nervous, or makes them break out in a sweat?

I think those are the parts to focus on first because removing the whole codebase, and painting all the problems with the same brush, would in fact cause more instability and unpredictability.

And as a designer that’s the worst outcome I can imagine.

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