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;
2.2
Comments
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 —, ”, or ☺
; 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 {
font-weight:bold;
}
/* 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 */
#video{
margin-top: 1em;
}
/* Not recommended: unnecessary line break */
#video
{
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....
Cheers!
Vamsi
No comments:
Post a Comment