? A few notes about complexity in CSS
[ROBIN]: Last week Charlie Gerard wrote about some things that no one taught her about CSS which I thought was pretty dang interesting. She digs into the terminology around CSS, such as what paint and composite mean and what effect they should have on how we write CSS.
Much like Charlie, I didn’t study web design in school either and I’m also uncertain of how schools go about teaching CSS these days – but I expect that most folks today still learn about this language whilst on the job. For me that meant making fan websites and creating blogs but most of what I know really comes from my first job working as a web designer at a small agency.
I would pester one particular engineer, Will, endlessly. What does this mean? How does that work? How do I style this thing like that other thing? What is the command line? Oh neat it can do that, huh? Why would I want it to do that? What’s a Sass? Why do we use this flavor of it? What is Grunt and why do we need it to process our CSS?
At one point or another he looked at me and said very slowly: Not. Cool. Buddy.
So I began to bug Will less and to try and tackle all my problems without rushing for help right away. I’d dig into the MDN docs, read a ton of blog posts on whatever subject it was that I was struggling with and make small demos to try and figure out how CSS worked under the hood (although today I still feel as if I’m trying to understand how CSS works and I will never really stop).
This had me thinking though: what did no-one teach me about CSS? Once I started to become more of an independent developer what did I learn that no-one could have taught me? Well, I think the most important thing I learned – slowly and painfully over many years – is this: try to write your CSS as simply as possible.
Don’t try to be clever with loops or targeting weird selectors. If you have to write an elaborate comment to explain something then maybe you can change the design instead. Perhaps you can avoid writing all of this really fragile code entirely.
But especially try to avoid writing code like this:
I honestly believe that the first step to writing good CSS is to reduce the amount of nesting that you do. You could write the above like this instead:
Imagine all of these nested selectors in your code as if they were
if statements and you’ll suddenly see that your code is pretty complicated. Add thirty lines of code to each selector with several media queries and even more styles between them and all of a sudden you have a vast and complicated machine that you’ve built just to style this one, tiny thing.
Writing CSS in an easy to read format will provide you with a number of benefits. It will be easier to add new styles to your design. It will be easier to refactor and change in the future. You’ll spend way less time asking how this code you wrote six months ago works. And new employees or designers will be able to navigate your work without wasting a whole bunch of time, too.
I guess this rant can be boiled down to this: if you’re trying to do something smart or clever with CSS, delete your code and try again. I promise it will save you a whole bunch of time and money in the long run.
? From the ol’ Blog
Simple & Boring: Chris wrote all about how many folks have been talking about simplicity in the design of websites lately and I really like this part in particular where Chris writes:
… our job is managing the level of complexity so it’s valuable while still manageable.
This is such a wonderful description of what design systems and good front-end development is, I reckon. Complexity well-managed.
All about mailto: links: In this post Chris digs into some of the surprising issues that pop up when we want to add a link to an email address or a phone number on a website:
we immediately run into a handful of UX issues. One of them is that clicking that link surprises some people in a way they don’t like. Sort of the same way clicking on a link to a PDF opens a file instead of a web page.
I wonder if this is the fault of browser design though. I don’t believe I’ve ever clicked a mailto link or a link to a phone number and expected my browser to behave in that particular way. But perhaps whatever browser we’re using could set those expectations by presenting some kind of popover or something, some affordance to tell us that the thing we’re about to click isn’t a link to a website at all.
(Really hate those mailto links? This is a pretty nice Chrome Extension for that plops the email address onto your clipboard instead, while telling you what it is doing.)
It’s pretty cool how Netlify CMS works with any flat file site generator: In this one Chris walks through how to use Netlify CMS (which happens to be a CMS that’s built into your Git workflow). All Chris had to do is add two files to his repo and then he shows us how he has this wonderful interface to add content to his site that uses 11ty.
Here’s an example of the UI that Chris uses to add content to the Upcoming Conferences site:
Pretty neat, huh? I can see myself using this to make our internal tools at the company I work for more accessible – often folks that are unfamiliar with using GitHub want to add new content but it’s then up to a developer to do that work for them. So I love how simple it is to add Netlify CMS to a static site generator and get things working quickly.
Caleb Williams just finished publishing a 5-part series on Web Components on the site. We’ve packaged that up, along with some other good articles and links, into a Web Components Guide.
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.
- Boston (May 6-8)
- Washington DC (July 29-31)
- Chicago (August 26-28)
- Denver (October 28-30)
- San Francisco (December 9-11)