Here are HTML & CSS coding standards and mandatory to know before developing SharePoint 2013 apps.
Many of the coding standards in this document are based off those used by Google. These can be found at:
1.2 Indentation / Whitespace
Indentation should be 4 spaces at a time; tabs should not be used.
Trailing whitespace should be removed as it can complicate diffs.
An editor which uses UTF-8 as character encoding without a byte order mark (BOM) should be used.
The encoding in HTML templates and documents should be specified via <meta charset="utf-8">. The encoding of style sheets should not be specified as these assume UTF-8.
1.4 Separation of concerns
Structure, presentation, and behaviour should be kept strictly apart, and the interaction between the three kept to an absolute minimum. HTML documents should contain only structural markup, anything presentational should be in stylesheets, and everything behavioural in scripts.
2. HTML & CSS
All code should be lowercase: This applies to HTML element names, attributes, attribute values (unless text/CDATA), CSS selectors, properties, and property values (with the exception of strings).
Comment should be placed where necessary to explain complex code or a decision, this will depend on the situation / project.
HTML closing tags should not be commented “for clarity”; most editors will highlight selected tags or allow expanding/collapsing sections for this purpose.
2.3 Graceful Degradation
If support is required for IE prior to version 9 (or otherwise non-HTML5-supporting older browsers), an HTML5 shiv/shim script should always be included. If the project is built using a framework (eg. Bootstrap) or something lightweight is required then html5shiv is probably sufficient, otherwise Modernizer is recommended.
Newer technologies like CSS3 gradients should be used for extra polish, and ensure the styles still appear clear in older browsers. Don’t leave the background displaying black on browsers which don’t support a gradient if the text is also black!
Providing alternative contents is important for accessibility reasons: A blind user has few cues to tell what an image is about without alt, and other users may have no way of understanding what video or audio contents are about if these are disabled or unsupported by their browser.2.4 HTML
HTML5 should be used for all HTML documents:
<!DOCTYPE html>. XHTML syntax should be used, that is all void elements should be closed (such as <br />).
Documents should always be served as
text/html(not application/xhtml+xml or otherwise).
Validity should always be tested, using tools such as the W3C HTML validator.
Elements should always be used for their intended purpose, and the most appropriate element should always be used for the content; the HTML5 specification can be quite specific, or for an easier read there are sites such as html5doctor.
typeattributes in these contexts is not necessary as HTML5 implies
Although in HTML5 there are now some tags which do not have to have a closing tag, for example: html, head, body, p, dt, dd, li, option, thead, th, tbody, tr, td, tfoot, colgroup; for readability the closing tags for these should be used.2.5 Omit the protocol from embedded resources.
The protocol portion (http:, https:) should be omitted from URLs pointing to images and other media files, style sheets, and scripts unless the respective files are not available over both protocols. Omitting the protocol—which makes the URL relative—prevents mixed content issues and results in minor file size savings.
2.6 Entity References
Although UTF-8 encoding should be used for all documents, for consistency and editor compatibility use of entity references like —, ”, or ☺
;is advised (and required for HTML characters such as < and &).
Unless dealing with CSS validator bugs or requiring proprietary syntax, valid CSS code should be used. Tools such as the W3C CSS validator should be used to test. Use of LESS is recommended, particularly if the project is also using a framework which uses it (like Bootstrap).
All CSS hosted in an environment beyond local development (ie. ‘test’ / production environments) should be minified for performance.
A CSS reset script should always come at the beginning of the first CSS script or be the first script included on the page - a recommended reset script is Eric Meyer’s Reset CSS 2.0. If the project is using Bootstrap no additional reset is required as it is built to be cross-browser compatible.
Shorthand properties should be used where possible, for code efficiency and clarity.
Words and abbreviations in selectors should not be concatenated by any characters (including none at all / camelCase) other than hyphens, in order to improve clarity.
2.11 Code Formatting
Every declaration should be ended with a semicolon for consistency and extensibility reasons. CSS minifiers will remove these later as necessary.
All block content should be indented to reflect hierarchy and improve clarity.
Property and value should be separated by a single space (but no space between property and colon) for consistency.
A single space should be used between the last selector and the opening brace that begins the declaration block. The opening brace should be on the same line as the last selector in a given rule.
Instead of presentational or cryptic names, ID and class names that reflect the purpose of the element in question, or that are otherwise generic, should be used. Names that are specific and reflect the purpose of the element should be preferred as these are most understandable and the least likely to change; generic names are simply a fallback for elements that have no particular or no meaning different from their siblings. They are typically needed as “helpers.”
Unless necessary (for example with helper classes), element names in conjunction with IDs or classes should not be used. Avoiding unnecessary ancestor selectors is useful for performance reasons.
2.12 Conditional CSS
Conditional CSS should be used sparingly, but there are certainly cases which warrant it (IE filters in older versions are an example); browser-specific CSS hacks are to be avoided wherever possible. A separate stylesheet should be included for older versions of IE, through conditional comments, as necessary (IE 10 and above no longer support conditional comments).