4.3 Bootstrap CSS Coding Specifications


Bootstrap CSS Coding Guidelines

insert image description here

grammar

  • Use two spaces instead of tabs (tab) - this is the only way to guarantee a consistent display in all environments.
  • When grouping selectors, place individual selectors on their own line.
  • For code readability, add a space before the opening curly brace of each declaration block.
  • Closing curly braces for declaration blocks should be on their own lines.
  • A space should be inserted after the : of each declaration statement.
  • For more accurate error reporting, each statement should be on its own line.
  • All declaration statements should end with a semicolon. The semicolon after the last declaration statement is optional, but if you omit it, your code may be more error-prone.
  • For comma-separated attribute values, a space (for example, box-shadow) should be inserted after each comma.
  • Do not insert spaces after commas inside rgb(), rgba(), hsl(), hsla()or rect()values. This helps to distinguish multiple color values ​​(only commas, no spaces) from multiple attribute values ​​(commas and spaces).
  • For attribute values ​​or color parameters, omit leading zeros for decimals less than 1 (eg, .5 for 0.5; -.5px for -0.5px).
  • Hexadecimal values ​​should be all lowercase, for example, #fff. When scanning documents, lowercase characters are easier to distinguish because their form is easier to distinguish.
  • Use shorthand hexadecimal values ​​whenever possible, for example, #fffreplace with #ffffff.
  • Add double quotes around attributes in the selector, for example, input[type="text"]. It is only optional in some cases, but, for code consistency, it is recommended to include double quotes.
  • Avoid specifying units for 0 values, for example, use margin: 0;instead margin: 0px;.

Questions about the terminology used here? See Cascading Style Sheets - 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;
}

declaration order

Related property declarations should be grouped together in the following order:

  1. Positioning
  2. Box model
  3. Typographic
  4. Visual

Positioning comes first because it removes elements from the normal document flow and also overrides box model-related styles. The box model comes second because it determines the size and placement of components.

The other properties only affect the inside of the component (inside) or do not affect the first two sets of properties, so they are ranked later.

See Recess for a complete list of properties and their order.

.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 use @import

Compared with <link>tags, @importinstructions are much slower, not only increase the number of additional requests, but also cause unpredictable problems. Alternatives are the following:

  • Using multiple <link>elements
  • Compile multiple CSS files into one file via a CSS preprocessor like Sass or Less
  • CSS file merging provided by Rails, Jekyll or other systems

Please refer to Steve Souders' article to learn more.

<!-- 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 as close to relevant rules as possible. Don't bundle them in a single stylesheet or at the bottom of the document. If you separate them, you will only be forgotten by everyone in the future. A typical example is given below.

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

Attributes prefixed with

When using vendor-specific prefixed properties, use indentation to align the value of each property vertically, which facilitates multi-line editing.

In Textmate, use Text → Edit Each Line in Selection (⌃⌘A) . In Sublime Text 2, use Selection → Add Previous Line (⌃⇧↑) and Selection → 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);
}

one-line rule statement

For a style that contains only one statement, for readability and quick editing, it is recommended to put the statements on the same line. For styles with multiple declarations, the declarations should still be broken into multiple lines.

The key factor in doing this is for error detection – for example, the CSS validator pointed out a syntax error on line 183. If it is a single-line single statement, you will not ignore this error; if it is a single-line multiple statement, you have to analyze it carefully to avoid missing errors.

/* 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; }

Shorthand for property declarations

In cases where explicit setting of all values ​​is required, the use of shorthand property declarations should be limited as much as possible. Common misuse of shorthand 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 shorthand property declarations. For example, the HTML heading element only needs to set the top and bottom margin values, so you only need to override these two values ​​when necessary. Excessive use of shorthand property declarations can clutter code and cause undesired side effects by unnecessarily overriding property values.

There is a very good article on shorthand properties on MDN (Mozilla Developer Network), 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 unnecessary nesting. This is because although you can use nesting, it doesn't mean you should. Nesting is only used when styling must be restricted to the parent element (that is, descendant selectors), 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 { … }
}

note

Code is written and maintained by people. Make sure your code is self-describing, well-commented, and easy for others to understand. Good code comments convey the context and purpose of the code. Don't simply reiterate component or class names.

For longer notes, be sure to write complete sentences; for general notes, short phrases are fine.

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

class naming

  • Only lowercase characters and dashes (not underscores and not camelCase) may appear in class names. Dashes should be used for related class names (similar to namespaces) (for example, .btn and .btn-danger).
  • Avoid overly arbitrary shorthand. .btn stands for button, but .s doesn't mean anything.
  • Class names should be as short as possible and unambiguous.
  • Use meaningful names. Use organized or purposeful names rather than presentational names.
  • Based on the nearest parent class or basic (base) class as the prefix of the new class.
  • Use .js-* classes to identify behavior (as opposed to styling), and don't include these classes in CSS files.

You can also refer to the specifications listed above when naming Sass and Less variables.

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

Selector

  • Use class for common elements, which is conducive to the optimization of rendering performance.
  • Avoid using attribute selectors (for example, [class^="…"] ) for frequently occurring components. Browser performance can be affected by these factors.
  • The selector should be as short as possible, and try to limit the number of elements that make up the selector. It is recommended not to exceed 3.
  • Only restrict classes to the nearest parent element (aka descendant selector) when necessary (for example, when not using a prefixed class – prefixes are similar to namespaces).

Further 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 snippets in units of components.
  • Develop a consistent annotation specification.
  • Use consistent whitespace to separate code into blocks, which facilitates scanning of larger documents.
  • If using multiple CSS files, split them into components rather than pages, as pages will be reorganized and components will only be 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 { ... }

editor configuration

Set up your editor with the following configuration to avoid common code inconsistencies and discrepancies:

  • Use two spaces instead of tabs (soft-tab uses spaces to represent tabs).
  • When saving the file, trailing whitespace is removed.
  • Set the file encoding to UTF-8.
  • Add a blank line at the end of the file.

Refer to the documentation and add these configuration information to the project's .editorconfigfile. Example: .editorconfig instance in Bootstrap . For more information, please refer to about EditorConfig .

Guess you like

Origin blog.csdn.net/m0_62617719/article/details/131810850