LiveWhale CMS

Welcome, Guest Login

Support Center

Our documentation is moving:

Please check for the most up-to-date LiveWhale CMS and LiveWhale Calendar documentation. The below legacy documentation will remain available as a reference until the documentation migration is complete.

Styleguide: CSS

Last Updated: Nov 04, 2014 03:19PM PST

Basic Coding Style

Use the following list as a guide when writing your CSS.

  • Use a single tab per level of indent.
  • Put spaces after : in property declarations.
  • Put spaces before { in rule declarations.
  • Don’t do single-line rule declarations even for just one property.
  • When assigning multiple rules the same style (e.g. comma-separated), put each rule name on new line.
  • Zero is zero, it never needs units.
  • Style names are lowercase dashed or underscored (e.g. lw_styles, never camelcase.
  • Use hex color codes #000 unless using rgba(0, 0, 0, 0).
  • Use /* */ for comments.
  • Order property declarations either alphabetically or by position, font styles, and container styles.
  • These days it’s almost impossible to get by without using some vendor prefixes. When you do, write for as many vendor prefixes as reasonable and and/or allow for graceful degradation. Always include the non-vendor prefixed rule for long-term support.


Just do it. Consider Eric Meyer’s Reset CSS to zero out all styles and be able to define them yourself from the ground up or better yet, Nicolas Gallager’s popular normalize.css to keep some browser styles with added consistency.

Print, IE Stylesheets

Build print and IE specific stylesheets when appropriate or needed.

In general, you should attempt to minimize the need for IE (or other browser-specific) stylesheets by coding in a manner that does not require an IE-specific correction. Do allow for graceful design degradation — most CSS-made rounded corners do not need to have an IE fallback. Where the project/design permits, you may even choose to remove non-essential elements.

Specificity (tags vs. classes vs. ids)

Elements that occur exactly once inside a page should use IDs, otherwise, use classes. When in doubt, use a class name.

  • Good candidates for ids: header, footer, modal popups.

  • Bad candidates for ids: navigation, item listings, item view pages (ex: issue view).

When styling a component, start with a class namespace (prefer class names over ids or tags), prefer direct descendant selectors by default, and use as little specificity as possible so that the design well abstracted from the structure of the HTML, or even the tags used. Here is an example:

<!-- the html -->
<ul class="category-list">
  <li class="item">Category 1</li>
  <li class="item">Category 2</li>
  <li class="item">Category 3</li>

/* a poor example */
#main ul.category-list {
  margin: 0;
  padding: 0;
  list-style-type: none;
#main ul.category-list li.item {
  color: #333;
  font-weight: 400;

/* a good example */
.category-list {
  margin: 0;
  padding: 0;
  list-style-type: none;
.item {
  color: #333;
  font-weight: 400;

/* also good if more specificity is needed */
.category-list .item {
  color: #333;
  font-weight: 400;

Naming Conventions

Choose style names that generally reflect the type of content being styled and less the actual style. As hard as it is, resist the temptation name a style by color like <tag class="pulled-quote blue"> even when a blue background is the only style change, because someday, you’ll want that blue background to be green and you’ll have to change the entire site.

  • Good candidates for styles: links, news, main-copy, sign-up-link, main-image, or lead
  • Poor candidates for styles: color names, font style or family names

If in doubt, consult Bootstrap as a reasonable guide to the naming of styles. For specificity, you may want to prepend/append styles as they do in tabletable-borderedtable-alternating, etc.

When possible, do not use existing CSS classes as functional hooks. Use prepended classes specifically for javascript, or consider using data-attributes as noted in the javascript guide.

Pixels vs. Ems (vs. Rems)

When defining font-size, use px for font-size where possible, because it offers absolute control over text. However, worthwhile exceptions exist, particularly when creating device-responsive stylesheets where you might wish to adjust the type size from a single change on the body. So, choose wisely.

Additionally, unit-less line-height is preferred because it does not inherit a percentage value of its parent element, but instead is based on a multiplier of the font-size.

When possible, use rems in place of ems, unless you desire relative-to-parent sizing.

Width-responsive Styles 

Always build and test responsive designs for your work. Design for the primary viewport size and then use @media queries in your stylesheets to handle both larger and smaller viewports.
seconds ago
a minute ago
minutes ago
an hour ago
hours ago
a day ago
days ago
Invalid characters found