10 Simple Tips for Front-end Developers

Table of Contents

1. Commit compiled CSS as one standalone commit
2. Write your code mobile first
3. Group Media Queries with Selectors
4. Avoid Nesting in SASS/SCSS
5. Automate the Coding Standards
6. Use CSS Features that You Need: Part 1
7. Use CSS Features that You Need: Part 2
8. Test Your Code
9. Start Finishing, Stop Starting
10. Componentise Your Code
11. Use Visual Regression Testing Tools
12. Don't Follow These Guidelines

1) Commit compiled CSS as one standalone commit

Commit compiled CSS as one commit separate to the rest of your commits. If not, it's almost impossible to read what has changed in a commit since all the sass maps will be bundled up in it. If the compiled code is committed in one commit (hopefully with the exact same message 'Adding compiled files' or something like that), it's easy to scan through a git log and ignore the complied files commits while focussing on what code a developer changed.

2) Write your code mobile first

This means we write code that is for small screens and/or common to all screen sizes first, then (min-width not max-width) media queries after it.

Avoid this:

  .card { 
  background-color: #ff0000; 
  font-size: 2rem; 
} 

@media (max-width: 40em) { 
  .card { 
    font-size: 1rem; 
  } 
} 

Write this:

  .card { 
  background-color: #ff0000; 
  font-size: 1rem; 
} 

@media (min-width: 40em) { 
  .card { 
    font-size: 2rem; 
  } 
} 

3) Group Media Queries with Selectors

Keep the media query with the selector you are writing about, not at the bottom of the file.

Avoid this:

.class { 
  // Code here 
} 
.class2 { 
  // Code here 
} 
.class3 { 
  // Code here 
} 
@media (min-width: 40em) { 
  .class { 
    // Code here 
  } 
  .class2 { 
    // Code here 
  } 
  .class3 { 
    // Code here 
  } 
} 

Write this:

.class { 
  // Code here 
} 
@media (min-width: 40em) { 
  .class { 
    // Code here 
  } 
} 

.class2 { 
  // Code here 
} 
@media (min-width: 40em) { 
  .class2 { 
  // Code here 
  } 
} 

.class3 { 
  // Code here 
} 
@media (min-width: 40em) { 
  .class3 { 
  // Code here 
  } 
} 

You'll probably be using sass, which makes this even easier.

4) Avoid Nesting in SASS/SCSS

Do not nest classes in SASS if possible. It's very hard when you are 400 lines into a file to figure out exactly what is being affected when the nesting gets very deep.

Avoid this:

.content { 
  margin: auto; 
  .search { 
    background: green; 
    .form { 
      color: red; 
      .input { 
        padding: 1rem; 
        .button { 
          background-color: blue; 
          .button::after { 
            border: 2px solid black; 
            .text { 
              text-decoration: underline; 
            } 
          } 
        } 
      } 
    } 
  } 
} 

Write this:

.content { 
  margin: auto; 
} 
.content .search { 
  background: green; 
} 
.search .form { 
  color: red; 
} 
.search .input { 
  padding: 1rem; 
} 
.search .button { 
  background-color: blue; 
} 
.search .button::after { 
  border: 2px solid black; 
} 
.search .button-text { 
  text-decoration: underline; 
} 

Even better, use BEM classes to make your code much easier to understand, like so:

.content { 
  margin: auto; 
} 
.search { 
  background: green; 
} 
.search__form { 
  color: red; 
} 
.search__input { 
  padding: 1rem; 
} 
.search__button { 
  background-color: blue; 
} 
.search__button::after { 
  border: 2px solid black; 
} 
.search__button-text { 
  text-decoration: underline; 
} 
.search__button-text--large { 
  font-size: 1.5rem; 
} 

5) Automate the Coding Standards

Use CSScomb to auto format your SASS each time you save a file. This will ensure we are all following the exact same (Drupal, in my case) coding standards and makes it easier for us to compare our code. If only one person on your team uses CSSComb, it means when that person edits one of your files and clicks save, much of the commit changes may just be code reformatting. What I do in this case is open a file, save it, add a commit message "running CSSComb" (so I know I can ignore the contents of that commit), then make my changes and commit those. This means that my commit is the meaningful one where future-me can see exactly what I had changed. If everyone uses CSSComb (or  other auto linter type tool) it'll save this effort.

6) Use CSS Features that You Need: Part 1

Do not use CSS grid unless necessary - IE11 does not support it very well. I know, this is controversial, but most of the layouts we are working on these days (for better or worse) are perfectly achievable by flexbox. If you need to use grid, by all means use it - along with the IE11 autoprefixer. However, I did find on a project recently that the autoprefixer broke more than it fixed. Failing this, if you really want to use grid, campaign for IE11 to be shut down, locked up, and never seen again.

7) Use CSS Features that You Need: Part 2

Do not use custom CSS properties unless necessary. IE11 does not support it. Use $variables in sass instead. Yes, another controversial one and I'm sure I'll be told there's so much more you can do with custom properties. If they fit your use case, use them. They are great. But if it's just for declaring colours as variables, I find sass variables work perfectly and I don't need an IE11 fallback. Failing this, if you really want to use custom properties, campaign for IE11 to be shut down, locked up, and never seen again.

8) Test Your Code

Please test your code in (at least) Chrome, Firefox, Safari, and IE11, as well as mobile devices/browers. Just because your code works in one place does not mean it will work in another. Test early, test often; it'll save you a lot of work in the end - believe me, your client will be testing in more than one browser.

9) Start Finishing, Stop Starting

Complete your tasks first time around. Re-work costs time and money, and makes us go over budget and not have the projects completed on time. We have to get it right eventually, so let’s just get it right first time.

10) Componentise Your Code

Separate your sass partials. We should not have styling for .card in .teaser.

11) Use Visual Regression Testing Tools

I use BackstopJS for my visual regression. It means I can change some CSS in one file and easily check it doesn't break something else. I'll write up a longer post on this soon. But please, start using regression testing.

12) Don't Follow These Guidelines

If these guidelines do not suit you, don't follow them. If you can improve upon them, do so (and write a blog post about it so we can all learn from it).

Following the above 10 points, means we will work faster, smarter, and better.  
(And hopefully soon I'll be writing up a similar post saying USE GRID, USE CUSTOM PROPERTIES. (I'm looking forward to that day.))

Filed Under:

1. Frontend Development
2. Design in Browser
3. Web Design