Enforce these, or your own, agreed upon guidelines at all times. Small or large, call out what's incorrect. For additions or contributions to this Code Guide, please open an issue on GitHub.
Every line of code should appear to be written by a single person, no matter the number of contributors.
Enforce standards mode and more consistent rendering in every browser possible with this simple doctype at the beginning of every HTML page.
From the HTML5 spec:
Authors are encouraged to specify a lang attribute on the root html element, giving the document's language. This aids speech synthesis tools to determine what pronunciations to use, translation tools to determine what rules to use, and so forth.
Read more about the
lang attribute in the spec.
Head to Sitepoint for a list of language codes.
Internet Explorer supports the use of a document compatibility
<meta> tag to specify what version of IE the page should be rendered as. Unless circumstances require otherwise, it's most useful to instruct IE to use the latest supported mode with edge mode.
For more information, read this awesome Stack Overflow article.
Quickly and easily ensure proper rendering of your content by declaring an explicit character encoding. When doing so, you may avoid using character entities in your HTML, provided their encoding matches that of the document (generally UTF-8).
Per HTML5 spec, typically there is no need to specify a
Strive to maintain HTML standards and semantics, but not at the expense of practicality. Use the least amount of markup with the fewest intricacies whenever possible.
HTML attributes should come in this particular order for easier reading of code.
Classes make for great reusable components, so they come first. Ids are more specific and should be used sparingly (e.g., for in-page bookmarks), so they come second.
A boolean attribute is one that needs no declared value. XHTML required you to declare a value, but HTML5 has no such requirement.
For further reading, consult the WhatWG section on boolean attributes:
The presence of a boolean attribute on an element represents the true value, and the absence of the attribute represents the false value.
If you must include the attribute's value, and you don't need to, follow this WhatWG guideline:
If the attribute is present, its value must either be the empty string or [...] the attribute's canonical name, with no leading or trailing whitespace.
In short, don't add a value.
Whenever possible, avoid superfluous parent elements when writing HTML. Many times this requires iteration and refactoring, but produces less HTML. Take the following example:
:for each declaration.
rect()values. This helps differentiate multiple color values (comma, no space) from multiple property values (comma with space).
#fff. Lowercase letters are much easier to discern when scanning a document as they tend to have more unique shapes.
input[type="text"]. They’re only optional in some cases, and it’s a good practice for consistency.
margin: 0;instead of
Questions on the terms used here? See the syntax section of the Cascading Style Sheets article on Wikipedia.
Declarations should be ordered alphabetically by property.
@import is slower, adds extra page requests, and can cause other unforeseen problems. Avoid them and instead opt for an alternate approach:
For more information, read this article by Steve Souders.
Place media queries as close to their relevant rule sets whenever possible. Don't bundle them all in a separate stylesheet or at the end of the document. Doing so only makes it easier for folks to miss them in the future. Here's a typical setup.
Do not add vender prefixes to your code, Autoprefixer will do it for you on build.
In instances where a rule set includes only one declaration, consider removing line breaks for readability and faster editing. Any rule set with multiple declarations should be split to separate lines.
The key factor here is error detection—e.g., a CSS validator stating you have a syntax error on Line 183. With a single declaration, there's no missing it. With multiple declarations, separate lines is a must for your sanity.
Strive to limit use of shorthand declarations to instances where you must explicitly set all the available values. Common overused shorthand properties include:
Often times we don't need to set all the values a shorthand property represents. For example, HTML headings only set top and bottom margin, so when necessary, only override those two values. Excessive use of shorthand properties often leads to sloppier code with unnecessary overrides and unintended side effects.
The Mozilla Developer Network has a great article on shorthand properties for those unfamiliar with notation and behavior.
Avoid unnecessary nesting. Just because you can nest, doesn't mean you always should. Consider nesting only if you must scope styles to a parent and if there are multiple elements to be nested.
For improved readability, wrap all math operations in parentheses with a single space between values, variables, and operators.
Code is written and maintained by people. Ensure your code is descriptive, well commented, and approachable by others. Great code comments convey context or purpose. Do not simply reiterate a component or class name.
Be sure to write in complete sentences for larger comments and succinct phrases for general notes.
.btnis useful for button, but
.sdoesn't mean anything.
.js-*classes to denote behavior (as opposed to style), but keep these classes out of your CSS.
It's also useful to apply many of these same rules when creating Sass and Less variable names.
[class^="..."]) on commonly occuring components. Browser performance is known to be impacted by these.
Set your editor to the following settings to avoid common code inconsistencies and dirty diffs: