📝 CSS-Tricks 206: CSS Flexbox Poster and the 13th Fourth

View this newsletter on the web.

Now available: CSS Flexbox and Grid Posters

Our complete guide to flexbox is something I use on a weekly basis and it’s saved me so much confusion and heartache over the years. But now I won’t even have to go to the guide at all because we just started printing our very own poster all about flexbox:

Designed by the ever-so-talented Lynn Fisher, this poster is a handy reminder how to layout elements on a page in a flash. So if you find yourself looking up these properties and values then it’s safe to say you ought to go and pick one up. There is a poster for grid too!

📝 CSS-Tricks 205: Poster Effects with CSS, Checking Accessibility with :not, and Fussy Web Design

View this newsletter on the web.

A Mad Magazine Fold-In Effect with just CSS

Thomas Park made this lovely fold-in effect that relies on no JavaScript whatsoever and only a single image:

I love posts like this that reveal something that looks super complicated but is actually remarkably simple in the end. Also, Thomas has quite a lot of great examples of this sort of work, with one being that old iTunes expanding album effect that was always kinda neat.

Also! On a similar note, Lynn Fisher just made a neat Codepen example where she creates this ruffled poster effect: the original image is on the left and her example is on the right.

Then Lynn got on a roll a bit and kept going with the effects!

📝 CSS-Tricks 204: Patterns, Developer Experience, and Complex CSS Animations

View this newsletter on the web.

Howdy folks!

[Robin]: This week I’ve been working on a number of refactoring projects at Sentry, where I work as a designer/front-end engineer person. The first job was focused entirely on our colors, as over the years a certain amount of debt had been accrued until we had a ton of random hex values everywhere and horrid variable names such as offWhite2.

I’m not dunking on anyone. We have all written code like this. In our darkest moments, we all have to admit that we’ve actually written worse code than this.

In fact, tech debt is a good sign: your team built a thing that customers use and pay for, but now we have to think about scale rather than panic code just to make ends meet. The way I’ve started to think about tech debt is that the problem isn’t necessarily the debt itself, all codebases are bad, and getting used to that fact is the difference between being a junior and senior engineer in my opinion. The real problem is the conversation, or the lack thereof about that tech debt, and making a viable plan for the future.

All these variable names and confusing color schemes had become a running gag at the company. We all dunked on them because we knew they’re not part of an organized system and we all knew it had to be fixed. Some day at least. Well, the time had come. I had finally had enough and was going to fix this dang thing. Thankfully an audit had already been made of our colors—matching our completely bonkers older variables with a new color palette made in a Figma doc.

So I did what I do with all refactor projects now: I made a new a spreadsheet and started documenting things. I made a list of every existing color variable in the app today and paired that with the colors in our new palette from Figma:

The columns on the left signify the two codebases that we have and if an instance of a variable had been removed (Done) or if that variable had been removed entirely (Removed). It’s a pretty nasty spreadsheet, please do not @ me. The important thing about this is that I could understand the system and how much work was left to be done.

Next up, I added all our new variables into our theme.tsx file. We use emotion at Sentry and our theme file is where all our common variables live. Then I started removing the instances from both codebases and then removing the variable itself, updating the spreadsheet as I went. This stuff is long and tedious work but thankfully we had Percy setup so that with each commit I could see the impact that the color swaps had on our components.

Now, after a week or so of work, we finally have a brief list of variables to use everywhere and we can see them in the codebase, in Figma, and also in Slack. But to make a rather long story short, I think the moral of this story is that all design systems projects should begin and end with a spreadsheet. Boy, I love spreadsheets.

📝 CSS-Tricks 203: Responsive Images Guide, custom select elements, and CUBE CSS

View this newsletter on the web.

Our Guide to Responsive Images Syntax in HTML

Here’s one for your bookmarks: if you’ve ever wondered if you’re using the correct responsive images syntax in HTML then our guide was made just for you. In the intro, Chris writes:

This guide is about the HTML syntax for responsive images (and a little bit of CSS for good measure). The responsive images syntax is about serving one image from multiple options based on rules and circumstances. There are two forms of responsive images, and they’re for two different things:

1) If your only goal is performance, then what you need is…<img srcset="" src="" alt="">
2) If you also need design control, then what you need is… <picture>

Check out the “Only View Code Snippets” button if you’re there just to snag some code quick.

The syntax for getting responsive images right can be tricky sometimes and so I’m extremely glad that now I have a resource I can return to again and again whenever I need it.

📝 CSS-Tricks 202: How to Improve Site Performance & Tricks for Using CSS variables

View this newsletter on the web.

Looking at inline CSS and performance

In this post, Timothy Vernon has a lot of smart things to say about taking your styles out of CSS file and moving them into the HTML for performance reasons:

CSS is treated as a render-blocking resource — that is, if you include any form <link href="style.css" rel="stylesheet"> of in the document’s <head>, the browser will trigger an additional request to the server to retrieve that stylesheet before even beginning to render your page for the user.

While our internet providers, infrastructure, and servers are all getting faster every year, there is no such thing as a free lunch. Every network request to the server has a time cost, and the requests required to complete before the browser begins rendering the page are the most expensive.

There are some trade-offs with this, as Timothy mentions. For example: now those styles are in your HTML, the download is certainly larger than before. It follows then makes to only serve the CSS that’s being used on that page and that’s commonly referred to as Critical CSS. Timothy mentions a few tools to help with that, such as Addy Osmani’s Critical project.