Bootstrap CSS coding specification

This section describes the CSS encoding specification in Bootstrap.

Grammar

  • Replace tabs (tabs) with two spaces -- the only way to ensure consistent presentation in all environments.

  • When grouping selectors, separate selectors are placed on a single row.

  • For the readability of the code, add a space before the opening braces of each declaration block.

  • The closing braces of the declaration block should be in separate lines.

  • Each declared : space should be inserted after that.

  • For more accurate error reporting, each declaration should have a single line.

  • All declaration statements should end with a sign. The sign after the last declaration statement is optional, but if you omit it, your code may be more error-prone.

  • For comma-separated property values, each comma should be followed by a space (for example, box-shadow

  • Do not insert spaces behind commas inside the rgb() rgba() hsla() or rect() values. hsl() This helps distinguish between multiple color values (only commas, no spaces) from multiple property values (both commas and spaces).

  • For property values or color parameters, omit 0 before a number less than 1 (for example, .5 0.5 -.5px -0.5px

  • He heteens should be all smaller, for example, #fff When scanning a document, small-case characters are easier to distinguish because their form is easier to distinguish.

  • Try to use he he heteen values in short form, for example, #fff #ffffff

  • Add double quotes to the properties in the selector, for input[type="text"] Only in some cases is optional, but double quotes are recommended for code consistency.

  • Avoid specifying units for a value of 0, for margin: 0; Instead margin: 0px;

Have questions about the terminology used here? Refer to the Cascade Style Sheet - Syntax on Wikipedia.

/* Bad CSS */.selector, .selector-secondary, .selector[type=text] {
  padding:15px;
  margin:0px 0px 15px;
  background-color:rgba(0, 0, 0, 0.5);
  box-shadow:0px 1px 2px #CCC,inset 0 1px 0 #FFFFFF}/* Good CSS */.selector,.selector-secondary,.selector[type="text"] {
  padding: 15px;
  margin-bottom: 15px;
  background-color: rgba(0,0,0,.5);
  box-shadow: 0 1px 2px #ccc, inset 0 1px 0 #fff;}

The order in which the declarations are made

The related property declarations should be grouped and arranged in the following order:

  1. Positioning

  2. Box model

  3. Typographic

  4. Visual

Because positioning removes elements from a normal document flow and overrides box model-related styles, it comes first. The box model comes in second place because it determines the size and position of the components.

Other properties only affect the inside of the component or do not affect the first two sets of properties, and therefore rank second.

For a complete list of properties and their order, refer to Recess.

.declaration-order {
  /* Positioning */
  position: absolute;
  top: 0;
  right: 0;
  bottom: 0;
  left: 0;
  z-index: 100;

  /* Box-model */
  display: block;
  float: right;
  width: 100px;
  height: 100px;

  /* Typography */
  font: normal 13px "Helvetica Neue", sans-serif;
  line-height: 1.5;
  color: #333;
  text-align: center;

  /* Visual */
  background-color: #f5f5f5;
  border: 1px solid #e5e5e5;
  border-radius: 3px;

  /* Misc */
  opacity: 1;}

Do not @import

The @import directive <link> much slower @import which not only increases the number of additional requests, but also causes unforeseen problems. There are several alternatives:

  • Use more than one <link>

  • Multiple CSS files are compiled into one file through a Similar CSS preprocessor like Sass or Less

  • CSS file merge is available through Rails, Jekyll, or other systems

Please refer to Steve Souders' article for more information.

<!-- Use link elements --><link rel="stylesheet" href="core.css"><!-- Avoid @imports --><style>
  @import url("more.css");</style>

The location of the Media query

Place media queries near as relevant a rule as possible. D on't package them in a single style file or at the bottom of the document. I f you separate them, you will only be forgotten in the future. A typical example is given below.

.element { ... }.element-avatar { ... }.element-selected { ... }@media (min-width: 480px) {
  .element { ...}
  .element-avatar { ... }
  .element-selected { ... }}

Properties with prefixes

When using prefixed properties from a particular vendor, the values of each property are aligned vertically by indentation, making it easy to edit multiple rows.

In Textmate, use Text → Edit Line in Selection (⌃⌘A). In Sublime Text 2, you can use The → Line (⌃⇧) and the → Add Next Line ⌃⇧.

/* Prefixed properties */.selector {
  -webkit-box-shadow: 0 1px 2px rgba(0,0,0,.15);
          box-shadow: 0 1px 2px rgba(0,0,0,.15);}

A one-line rule declaration

For styles that contain only one declaration, it is recommended that statements be placed on the same line for ease of reading and for quick editing. For styles with multiple declarations, you should still divide the declarations into multiple lines.

The key factor in this is error detection -- for example, the CSS checker indicates that there are syntax errors on row 183. If it's a one-line statement, you won't ignore the error, and if it's a one-line, multiple-statement, you'll need to analyze carefully to avoid missing the error.

/* Single declarations on one line */.span1 { width: 60px; }.span2 { width: 140px; }.span3 { width: 220px; }/* Multiple declarations, one per line */.sprite {
  display: inline-block;
  width: 16px;
  height: 15px;
  background-image: url(../img/sprite.png);}.icon           { background-position: 0 0; }.icon-home      { background-position: 0 -20px; }.icon-account   { background-position: 0 -40px; }

A property declaration in short form

Where all values need to be set in a display, you should try to limit property declarations in short form. Common abuse of short-form property declarations is as follows:

  • padding

  • margin

  • font

  • background

  • border

  • border-radius

In most cases, we don't need to specify all the values for a property declaration in short form. F or example, the heading element of HTML only needs to set the values of the top and bottom margins, so you only need to override both values when necessary. Overuse of property declarations in short form can lead to code confusion and unnecessary overwriting of property values, causing unexpected side effects.

A very good article on Mozilla Developer Network about shorthand properties is useful for users who are not familiar with shorthand property declarations and their behavior.

/* Bad example */.element {
  margin: 0 0 10px;
  background: red;
  background: url("image.jpg");
  border-radius: 3px 3px 0 0;}/* Good example */.element {
  margin-bottom: 10px;
  background-color: red;
  background-image: url("image.jpg");
  border-top-left-radius: 3px;
  border-top-right-radius: 3px;}

Nesting in Less and Sass

Avoid non-essential nesting. T his is because while you can use nesting, it does not mean that nesting should be used. Nesting is used only if the style must be limited to the parent element (that is, the descendant selector) and there are multiple elements that need to be nested.

// Without nesting.table > thead > tr > th { … }.table > thead > tr > td { … }// With nesting.table > thead > tr {
  > th { … }
  > td { … }}

Comments

Code is written and maintained by people. M ake sure your code is self-describing, well annotated, and easy for others to understand. G ood code annotations convey context and code purposes. Do not simply reiterate the component or class name.

For longer notes, be sure to write complete sentences, and for general annotations, you can write concise phrases.

/* Bad example *//* Modal header */.modal-header {
  ...}/* Good example *//* Wrapping element for .modal-title and .modal-close */.modal-header {
  ...}

Class is named

  • Only lowercase characters and dashes (not underlined or hump nomenclales) appear in the class name. Dashes should be used for the naming of related classes (similar to namespaces) (for example, .btn .btn-danger

  • Avoid overly arbitrary short errations. .btn for button, but .s does not mean anything.

  • The class name should be as short and meaningful as possible.

  • Use meaningful names. Use an organized or purposeful name, not a presentational name.

  • Prefix the new class based on the nearest parent class or base class.

  • Use .js-* class to identify behavior (as compared to styles) and do not include these classes in CSS files.

In naming Sass and Less variables is also possible to refer to the specifications listed above.

/* Bad example */.t { ... }.red { ... }.header { ... }/* Good example */.tweet { ... }.important { ... }.tweet-header { ... }

Selector

  • Use class for common elements to optimize rendering performance.

  • For components that occur frequently, avoid using a property selector [class^="..."] example, . The performance of the browser is affected by these factors.

  • The selector should be as short as possible and limit the number of elements that make up the selector as much as possible, and it is not recommended to exceed 3.

  • Limit class only when necessary within the nearest parent element (that is, the descendant selector) (for example, when class with a prefix is not used -- the prefix is similar to a namespace).

Extended reading:

/* Bad example */span { ... }.page-container #stream .stream-item .tweet .tweet-header .username { ... }.avatar { ... }/* Good example */.avatar { ... }.tweet-header .username { ... }.tweet .avatar { ... }

Code organization

  • Organize code snippts as components.

  • Develop consistent annotation specifications.

  • Use consistent blank characters to separate code into blocks, which helps scan larger documents.

  • If more than one CSS file is used, split it as a component rather than a page because the page is reorganized and the component is only moved.

/*
 * Component section heading
 */.element { ... }/*
 * Component section heading
 *
 * Sometimes you need to include optional context for the entire component. Do that up here if it's important enough.
 */.element { ... }/* Contextual sub-component or modifer */.element-heading { ... }

The editor configuration

Set up your editor to avoid common code inconsecency and differences by following the configuration below:

  • Replace tabs with two spaces (soft-tab means tab).

  • When you save a file, remove the blank character from the tail.

  • Set the file code to UTF-8.

  • Add a blank line at the end of the file.

Refer to the documentation and add this configuration information to .editorconfig file. E xample: The .editorconfig instance in Bootstrap. For more information, please refer to About EditorConfig.