SharePoint Information Site > Technical Guides > DePaul CSS Coding Guide

DePaul CSS Coding Guide

The easiest way to remember all this is to look at the responsive.debug.css file and just be consistent with how existing code is formatted, then everything falls into place. We wish our CSS to look like a single person authored it.  This has a huge impact on code readability and efficiency.  So please read on for details on how to keep our CSS optimized.

General Rules

  • Know when to use the height property. Heights on elements in responsive designs will become problematic because the viewport will shrink and expand and those heights won't be relevant at every page width. Height can be used when you are including outside elements (such as images), otherwise use line-height for more flexibility.
  • Avoid redundancy by knowing the code. If in doubt when deciding upon a style, find and use existing patterns instead of reinventing the wheel by writing redundant code.
  • Avoid CSS hacks except for IE when absolutely necessary.  Star and underscore hacks are fine for development purposes but should be a rarity and heavily scrutinized before going into production.  ​If a feature can degrade gracefully without hacks, especially for really old browsers, that is the ideal alternative.  Also, note that IE8 thru IE11 specific CSS is handled with our custom-created IE prefix classes:  .ie8, .ie9, .ie10 and .ie11.
  • !important is intended to be a purposeful override as in the case of something like this, where you absolutely must employ such a method:
    .criticalerror { background: red!important; color: white!important;}
  • If you find yourself using !important repeatedly your css code has specificity issues that need to be resolved.
  • If you are attempting to fix an issue, attempt to remove code before adding more.
  • Magic Numbers are unlucky. These are numbers that are used as quick fixes on a one-off basis. If you're doing these kinds of patches repeatedly, then you're fighting against something. Think about how this property could be globalized or how a global property causing you to repeat this code needs to be reconsidered.
  • The DOM will change over time, target the element you want to use as opposed to finding it through its parents. Example: Use .highlight on the element as opposed to .highlight a (where the selector is on the parent). The more qualified or chained the selector, the less flexible the code, try to avoid this by adding classes to elements.
  • Do not restate default property & value combinations (for instance display: block; on block-level elements).

CSS Anatomy and Terms​

selector { (anything between these braces is called a ruleset)

   property: value/unit; (this line is called a declaration)

  • You should be able to build anything with the CSS you already have in the responsive.debug.css file. If not, then we build for reuse with abstraction in mind. If you find yourself making something that everyone might benefit from, let's discuss.
  • The responsive.debug.css file is really well documented and noted - please read it.
  • If you find yourself writing something really simple, chances are it already exists. Examples: rounded corners, float, block.

Notes on Units

  • Pixel size an element relative to a particular resolution
  • Ems size an element relative to its font size;  rems size it relative to the document's base font size
  • Percentages size an element relative to its container
  • Ems size an element relative to its font size
  • Rems size it relative to the documents base font size
  • We're using the EM unit instead of PX to maintain consistency with the rest of our relative units

How to Use %, EM and Unitless

  • Use percentages for structural elements (sidebars, headers, footers, main content)
  • Use ems for type-related properties like margins, padding
  • Use unit-less values for line-height so elements don't inherit a computed style but rather are able to compute line-height in proportion to their font-size

CSS Formatting Conventions

  • Each selector should be on it's own line
  • End every declaration with a semi-colon, no exceptions ever.
  • Place comments on a new line above their subject.
  • Use lowercase and shorthand hex values, e.g., #aaa.
  • Use double quotes consistently.
  • Camelcase is fine, but we generally haven't used it.
  • When spaces are needed use "-" instead of "_"
  • Quote attribute values in selectors, e.g., input[type="checkbox"]
  • Use shorthand hex notation when possible
  • Where allowed, avoid specifying units for zero-values, e.g., margin: 0 - all you need here is zero, no units required.
  • Use a dollar sign $ to denote sections of the css
  • Use a carat ^ to denote sub sections of the css.
  • For test code added by developers, please use the "Developer Additions / testing" section at the bottom of this document.
  • @media query selectors and rulesets are indented one tab each.
  • Mark todo's, ticketed fixes with TODO(your dpu ID): forms or TICKET(dpu ID / ticket #):
  • Logically separate distinct pieces of code in to sections or subsections as required.
  • h1, .h1  > this separates code semantics from visual semantics so that we can have an h3, look like an h1 should the need arise. The heading and small elements also have classes that help abstract the use of those elements.

CSS Whitespace and Indentation Conventions

  • Use one level of indentation for each declaration.
  • Always put a single line between rules.
  • Always start a new line for each declaration.
  • Always use a single space between property and value (but no space between property and colon) for consistency.
  • Include a space after each comma in comma-separated property or function values.
  • The closing brace of your ruleset should use the same level of indentation as the opening selector.
  • Include a single space before the opening brace of a ruleset.
  • Vendor prefixes should always come before the final w3c declaration. 
  • Vendor prefixes should be indented one tab each.
  • Large blocks of single declarations can use a slightly different, single-line format.
  • Separate clusters of rulesets (sections of the css) by three blank lines.
  • All prefixes and fallbacks should be indented one tab space under the non-prefixed or primary property.
  • Where appropriate, or to convey complex rulesets, indent rulesets to mirror the DOM.






Tips for Naming CSS Classes

  • Be specific and describe the purpose of the element
  • Using classes named after the site should never be done as site styles are often copied and pasted into other sites. Be as general as you reasonably can.
  • Use class names that are as short as possible and long as necessary
  • Avoid systematic use of abbreviated class names. Don't make things difficult to understand.
  • Use clear, thoughtful, and appropriate names for classes.
  • See how other classes are named, follow those patterns.
  • Selectors for components should use class names; avoid the use of generic tags and unique ids.
  • Avoid overly specific classes. Be abstract. Just use ".vehicle" over ".1993lebaron"
  • Try to avoid singletons wherever possible unless the code is dynamic in some respect.

HTML Rules

  • Although fine with HTML/XHTML, with HTML5 we do not close void elements
  • Alt and title all images
  • No need to use entity references like & if the document encoding is UTF-8

Exceptions to These Rules

  • While we should strive to make classes really general and reusable anywhere there are going to be exceptions. The site skins are a big one. In the body tag of responsive sites will be the name of the skin the site uses, the properties involved with that class are all qualified or chained selectors. This makes it really easy for us to swap that skin name out for another and have the whole site change at once. The same principal can apply for widgets, panels and objects.
  • The ".active" class. This is always a contextual selector and is never defined alone. This allows us to use a consistent name for an active link that's easy to remember. This class is intended to live on the LI or A of a selected menu item in a navigation, slideshow or tabbed interface.
  • alt and title all images
  • no need to use entity references like & if the document encoding is UTF-8
  • note ending of elements that span a long part of the dom with  

Some Inspiration for these Rules