The Flip Flop Rule
Robin: Earlier today, Brad Frost asked what makes good CSS. Although I think the answer to that question is probably a rant worthy of a whole book or two, there is one thing I’ve been thinking about lately as I refactor a giant project with tens of thousands of lines of CSS.
And it’s this: Try to write CSS so that you can visualize the markup (or component structure) as you scan the file. Why is this? Well, I think most CSS is completely unreadable if you don’t have the markup opened up along next to it. Whenever I look at particularly difficult CSS it means I have to constantly flip-flop between the CSS file and the markup or I have to try and guess that the HTML works in a certain way.
This way leads to madness though.
BEM is one solution to this problem and we wrote a whole post about what BEM stands for and how it works a while back. So too I think is styled components where you can store all of your CSS literally inside the component file.
I hereby call this The Flip Flop Rule. The less flip-flopping between files you need to do, the better your code will be.
If you find yourself constantly switching back and forth between files, then maybe you need to add a lot of comments to the CSS! Maybe you can make the structure of the markup less complicated! Try removing those wrapper classes around things or perhaps change the design ever so slightly to make the styles less complicated.
If you can scan a CSS file and the markup or structure of that component is obvious from just a glance, then you’ve finally beaten the odds; you’ll have written some mighty fine lookin’ CSS.
From The Blog
Boy is layout jank annoying. But wait! Before we get angry about it, let’s wait until Chris has described how it applies to web design:
A web page isn’t locked in stone just because it has rendered visually. Media assets, like images, can come in and cause the layout to shift based on their size, which typically isn’t known in fluid layouts until they do render. Or fonts can load and reflow layout. Or XHRs can bring in more content to be placed onto the page. We’re always doing what we can to prevent the layout from shifting around — that’s what I mean by layout jank. It’s awkward and nobody likes it. At best, it causes you to lose your place while reading; at worst, it can mean clicking on something you really didn’t mean to.
This happened to me earlier today on a bank website I was using when – unbeknownst to me – a giant image was loading in the background. Just before I clicked a link, the image loaded, pushed all the content around and I went to a page that was not the one I expected.
There are ways to solve this today and tools to fight it are coming down the pipeline – like the
intrinsicsize HTML attribute and the Layout Instability API. Go team!
I haven’t seen many folks complimenting the design of Netlify but in this blogger’s opinion I think it’s as good as the features of the tools themselves. Everything is super easy to scan and read at a glance or access help or more information.
position: sticky first launched, the very first place I wanted to try it out on was table headers because I reckon they’re often a pretty bad experience — especially in tables with lots of data. I always wanted the header to stick to the top so everything is labelled and easier to read.
Chris digs into just that! There’s a few tricky things about setting up sticky tables that are worth keeping in mind.
This post is super interesting as the list of ways to load CSS has only expanded in recent years and Dominic Magnifico has done a great job outlining them and exploring the pros and cons of each.
I also like what he has to say here:
I want to preface this post with a disclaimer: There is no hard and fast rule that establishes one method of handling CSS in a React, or Vue, or Angular application as superior. Every project is different, and every method has its merits! That may seem ambiguous, but what I do know is that the development community we exist in is full of people who are continuously seeking new information, and looking to push the web forward in meaningful ways.
When it comes to loading CSS – and changing the way you’re doing that in your organization – you have to ask yourself one question: what is the downside of this? Writing CSS will always come with trials and tribulations and so before you make a big switch to change the way your org writes CSS you have to be comfortable with the weaknesses of that approach, too.
What’s your career worth to you? If you’re like most of us, you’re too busy working to think about your career. But while you’re heads-down getting stuff done, the web races forward. How you can keep up and stay inspired? That’s where we come in. Level up your skills while learning from 17 brilliant speakers over 3 days of delightfully curated sessions.
- Washington DC (July 29-31)
- Chicago (August 26-28)
- Denver (October 28-30)
- San Francisco (December 9-11)