CSE 154 Code Quality Guide(CSS) {

NOTE: All CSS Code should validate. Check to see if your code validated by looking for a green check mark in your repo. The validators will automatically run and email you a report if your code does not validate.

Table of Contents

1. Ordering
2. Redundancy
3. Vendor-Prefix CSS
4. Comments
5. Whitespace & Indentation
6. Good CSS Design

Ordering

• 1.1 Always order CSS in a logical way that makes it easy to read. The recommended strategy would be to put “generic” selectors at the top, such as the body, followed by context selectors, classes then IDs.

  Why? It is important to make our CSS files easy to read and update in the future. Creating a simple convention such as this makes the file a bit easier to process. Another common convention would be to organize CSS in order of when items appear on the HTML page. However, this convention is not as scalable, since it begins to associate a particular stylesheet with a single HTML page rather than a larger website.

  /* bad */
  .dog-images {
    /* ... */
  }
  
  body {
    /* ... */
  }
  
  #jumping-dog {
    /* ... */
  }
  
  header h1 {
    /* ... */
  }
  
  h1 {
    /* ... */
  }
  

  /* good */
  body {
    /* ... */
  }
  
  h1 {
    /* ... */
  }
  
  header h1 {
    /* ... */
  }
  
  .dog-images {
    /* ... */
  }
  
  #jumping-dog {
    /* ... */
  }
  

⬆ back to top

Redundancy

• 2.1 Avoid writing redundant rules if they appear for the same reason. For example, if you want to make all headings red, use a single rule. However, if two unrelated elements are set to have 5px margin, there is no need to factor that out. The general rule here is only group them together if changing one would always mean wanting to change both.

  Why? The goal here is to create readable and scalable CSS. In the example given, if we had a separate rule for each heading it would be confusing to read. This way, it is very clear that all headings have this same color. Additionally, if we ever decide to change the color in the future, we only need to change it in one place. However, in the case of unrelated styles, it could actually make our code harder to update in the future!

  /* bad */
  h1 {
    color: red;
  }
  
  h2 {
    color: red;
  }
  
  h3 {
    color: red;
  }
  
  nav {
    margin-bottom: 5px;
  }
  
  #dog-image {
    margin-bottom: 5px;
  }
  

  /* good */
  h1, h2, h3 {
    color: red;
  }
  
  nav {
    margin-bottom: 5px;
  }
  
  #dog-image {
    margin-bottom: 5px;
  }
  

⬆ back to top

Vendor-Prefix CSS

• 3.1 Never use vendor-prefix CSS rules for homework assignments in this class unless explicitly told otherwise. You may however use them in your creative project if necessary and the code lints/validates.

  What’s this? Some major browsers have created nonstandard CSS properties that can be used with browser-specific prefixes. These are generally experimental and we will avoid them in this course (although they can be very powerful and could be worth learning about after 154). More on these here.

  /* bad */
  div {
    -webkit-border-radius: 10px;
  }
  
  /* good */
  div {
    border-radius: 10px;
  }
  

⬆ back to top

Comments

• 4.1 Similar to HTML, there isn’t really any need to make inline comments in CSS, and they can actually make your code less readable. However, you could make some simple comments related to your ordering or if you have some complex CSS animations (we won’t get to these in lecture, but feel free to use them on the creative projects).

⬆ back to top

Whitespace & Indentation

• 5.1 Place 1 space before the leading brace to begin a rule set.

  /* bad */
  div{
    margin: auto;
  }
  
  /* good */
  div {
    margin: auto;
  }
  

• 5.2 Place each rule on its own line. Do not place any rules on the same line as a curly brace.

  /* bad */
  div { border: 5px solid black;
    background-color: PapayaWhip; margin: auto;
  }
  
  /* good */
  div {
    border: 5px solid black;
    background-color: PapayaWhip;
    margin: auto;
  }
  

• 5.3 Place one space after each colon in a ruleset and none before them.

  /* bad */
  h1 {
    color : Gainsboro;
    text-align :center;
    text-decoration:underline;
  }
  
  /* good */
  h1 {
    color: Gainsboro;
    text-align: center;
    text-decoration: underline;
  }
  

• 5.4 Place exactly one blank line between rule sets. Place no blank lines between rules.

  /* bad */
  h1 {
    color: LavenderBlush;
    text-decoration: underline;
  
    text-align: center;
  }
  h2 {
    color: Chartreuse;
  }
  

  /* good */
  h1 {
    color: LavenderBlush;
    text-decoration: underline;
    text-align: center;
  }
  
  h2 {
    color: Chartreuse;
  }
  

• 5.5 Indent exactly one time for rules. Do not indent anywhere else in CSS.

  /* bad */
  div {
   font-size: 18pt;
    color: #222222;
  }
  
    img {
  width: 50%;
    }
  
  p {
  font-family: Helvetica, Arial, sans-serif;
  font-size: 14pt;
  }
  

  /* good */
  div {
    font-size: 18pt;
    color: #222222;
  }
  
  img {
    width: 50%;
  }
  
  p {
    font-family: Helvetica, Arial, sans-serif;
    font-size: 14pt;
  }
  

⬆ back to top

Good CSS Design

• 6.1 Never apply styles to all elements using the * or html selectors. Prefer styling body.

  NOTE: Not all elements inherit from their parent, so you might need to use a comma separated selector rather than just body. For example, button elements do not inherit font information by default.

  Why? Using the * selector applies styles to every single element, even the ones that don’t need the style such as those in the head. Similarly, html contains the head, where we don’t want to apply styles as they have no meaning. As a note, there are actually some very specific cases where styling the html element is the only solution, but you should not run into them in this class.

⬆ back to top

};