About Me

Having 12 years experience in Microsoft technologies.Since more than 7 years working in SharePoint technologies. Expert in providing consultation for SharePoint projects. Hands on with development and administration.

Tuesday, 25 November 2014

SharePoint 2013 - Fronnt end & HTML/CSS coding standards

Here are HTML & CSS coding standards and mandatory to know before developing SharePoint 2013 apps. 
1.1               General
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.
1.3               Encoding
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
2.1               Capitalisation
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).
<!-- Not recommended -->
<A HREF="/">Home</A>
<!-- Recommended -->
<img src="logo.png" alt="Client Logo">
/* Not recommended */
color: #E5E5E5;
/* Recommended */
color: #e5e5e5;
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!
All dynamic content and multimedia should degrade gracefully.  Images should be provided for browsers which do not support <canvas>, alt content should always be provided for all images, and transcripts / captions for <video> and <audio> where available.  For pages where javascript is absolutely required for important tasks such as navigation, or the main content (not recommended), a <noscript> alternative should be provided.
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.
<!-- Not recommended -->
<div onclick="goToRecommendations();">All recommendations</div>
<!-- Recommended -->
<a href="recommendations/">All recommendations</a>
The type attributes should not be specified for style sheets (unless not using CSS) and scripts (unless not using JavaScript).  Specifying type attributes in these contexts is not necessary as HTML5 implies text/css and text/javascript as defaults. This can be safely done even for older browsers.
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.
<!-- Not recommended -->
<script src="http://www.site.com/js/gweb/analytics/autotrack.js"></script>
<!-- Recommended -->
<script src="//www.site.com/js/gweb/analytics/autotrack.js"></script>
/* Not recommended */
.example {
  background: url(http://www.site.com/images/example);
/* Recommended */
.example {
  background: url(//www.site.com/images/example);
2.6               Entity References
Although UTF-8 encoding should be used for all documents, for consistency and editor compatibility use of entity references like &mdash;, &rdquo;, or &#x263a; is advised (and required for HTML characters such as < and &).
2.7               CSS
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.
2.8               Reset
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.
2.9               Shorthand
Shorthand properties should be used where possible, for code efficiency and clarity.
/* Not recommended */
border-top-style: none;
font-family: palatino, georgia, serif;
font-size: 100%;
line-height: 1.6;
padding-bottom: 2em;
padding-left: 1em;
padding-right: 1em;
padding-top: 0;
/* Recommended */
border-top: 0;
font: 100%/1.6 palatino, georgia, serif;
padding: 0 1em 2em;
2.10            Naming
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.
/* Not recommended: does not separate the words “demo” and “image” */
.demoImage {}
/* Not recommended: uses underscore instead of hyphen */
.error_status {}
/* Recommended */
#video-id {}
.ads-sample {}
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.
@media screen, projection {
  html {
    background: #fff;
    color: #444;
Property and value should be separated by a single space (but no space between property and colon) for consistency.
/* Not recommended */
h3 {
/* Recommended */
h3 {
  font-weight: bold;
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.
/* Not recommended: missing space */
  margin-top: 1em;
/* Not recommended: unnecessary line break */
  margin-top: 1em;
/* Recommended */
#video {
  margin-top: 1em;
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.”
/* Not recommended: meaningless */
#yee-1901 {}
/* Not recommended: presentational */
.button-green {}
.clear {}
/* Recommended: specific */
#gallery {}
#login {}
.video {}
/* Recommended: generic */
.aux {}
.alt {}
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.
/* Not recommended */
ul#example {}
div.error {}
/* Recommended */
#example {}
.error {}
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).

 Happy programming....

No comments:

Post a Comment