Front End Standards

1 | P a g e
Copyright 2013 by Cambridge Associates LLC. All rights reserved. Confidential.

Front-End Web Development Standards

1. Introduction ............................................................................................................................................ 1
2. Frameworks, Libraries, Plugins & Technologies ...................................................................... 1
3. Obsolete Practices to Avoid .............................................................................................................. 2
4. Guiding Principles for Design & Development .......................................................................... 2
5. Constraints & Browser Support ...................................................................................................... 3
6. Accessibility Considerations ............................................................................................................. 4
7. Performance Considerations ............................................................................................................ 4
8. HTML ......................................................................................................................................................... 5
9. CSS .............................................................................................................................................................. 7
10. Images .................................................................................................................................................... 10
11. JavaScript .............................................................................................................................................. 10

1. Introduction
1.1. Scope of Document
1.1.1. These standards are intended to specify certain details regarding how web sites
should be constructed in order to increase asset reusability, browser compatibility,
adoption of industry best practices, site scalability, ease of maintenance, ability to
integrate with CMS technologies, and good teamwork.
1.2. Goals
1.2.1. Identify obsolete or irrelevant practices that should no longer be used as the basis for
work (This is similar to the Agile philosophy of designing for
change/revision/extension)
1.2.2. State general guidelines and design methodologies to bear in mind
1.2.3. Select standard frameworks, libraries, and languages that will be available for use
1.2.4. State language-specific conventions to be followed
1.2.5. Refer to style guide, pattern library, look & feel documentation if solution differs from
default bootstrap framework and global styles
2. Frameworks, Libraries, Plugins & Technologies
2.1. Frameworks
2.1.1. Bootstrap should be implemented as soon as development begins. Refer to Bootstraps
website for documentation on semantic HTML grid markup, implementing Base CSS,
components, and JavaScript. - http://twitter.github.io/bootstrap/
2.1.2. Normalize.css should also be implemented as soon as development begins-
http://necolas.github.io/normalize.css/
2.2. Libraries
2.2.1. jQuery (required for Bootstrap as well as most of our plugins)- http://jquery.com/
2.2.2. jQueryUI jQuery UI is used only for interface components that are not included in
Bootstrap - http://jqueryui.com/
2.3. Plugins
2.3.1. Icons FontAwesome - http://fortawesome.github.io/Font-Awesome/
2.3.2. DataTables - http://www.datatables.net/blog/Twitter_Bootstrap_2
2.3.3. jQuery MultiSelect for dropdowns with multiple checkboxes -
http://www.erichynds.com/blog/jquery-ui-multiselect-widget

2 | P a g e

2.3.4. jQuery Expander for showing/hiding text -
http://plugins.learningjquery.com/expander/
2.3.5. jQuery Autocomplete for search - http://jqueryui.com/autocomplete/
3. Obsolete Practices to Avoid
3.1. Embedding text into images
This creates problems for translation, copy/paste, scaling, bandwidth, mobile experience,
and more. Hopefully it is obvious that this practice should be avoided.
3.2. Using Adobe Flash or other 3rd party browser plugins to interact with the user
There are more standard, more secure, less intrusive ways to accomplish this now, and
many platforms(especially those produced by Apple) do not support Flash. Flash can be
used to improve the functionality of older/sub-standard browsers but should not be
depended upon for anything else (e.g. use standard solutions first and then allow fallback
to polyfills as needed).
3.3. Using Java Applets to interact with the user
Applets create accessibility issues, tend to cause confusion for the user, are slow to load,
usually do not add much value to the users experience, force mixing of logic and
presentation, and can increase security risk. Since modern browsers provide
natural/flexible ways to do most of what applets were designed for
(animation/interaction), applets are most often unneeded.
3.4. Using extra windows to show additional content
This tends to disrupt normal browsing flow (e.g. breaks the back button), is often blocked
automatically by modern browsers, and usually the same goals can be achieved using
modern web techniques.
3.5. Exceptions are made only for legacy applications or vended solutions that are not
integrated into other applications
3.6. See also:
3.6.1. http://www.richardsramblings.com/2005/09/java-applets-are-good-examples-of-
bad-webdesign/
3.6.2. http://www.useit.com/alertbox/9605.html
3.6.3. http://www.dailyblogtips.com/43-web-design-mistakes-you-should-avoid/
3.6.4. http://www.webpagesthatsuck.com/biggest-mistakes-in-web-design-1995-2015.html
4. Guiding Principles for Design & Development
4.1. Quality is crucial it is almost always more costly to make changes later.
Though you may not be in a position to fix something, make every effort to avoid making it
worse. Leadership is one our key values, and this should apply to all of your work
4.2. Do not under-design anticipate potential changes to avoid painting yourself into a
corner
4.3. Do not over-design work should be organized so that future changes are as painless as
possible, but do not attempt to predict or implement the future now
4.4. Do not reinvent the wheel use available functionality before considering a custom or 3rd
party solution
4.5. Protect good URL structure/organization
A site's URL structure should be as simple as possible. Consider organizing your content so
that URLs are constructed logically and in a manner that is most intelligible to humans (when
possible, readable words rather than long ID numbers) Google

3 | P a g e

4.5.1. Avoid use of different domains and subdomains that complicates security,
functionality, and promotion/migration/testing when possible, use relative links
4.5.2. Path should match breadcrumb/navigation
4.5.3. Maximize readability; minimize length
4.5.4. Avoid numbers and capital letters
4.5.5. Use (hyphen) characters in place of spaces; do not use _ (underscore) characters or
concatenate words without separators
4.5.6. Try to keep path element names to one word, especially at lower levels
4.5.7. Avoid specifying protocol (if you must link to an absolute host, begin the href with //
instead of http://" or https:// to allow the browser to consistently use the same
protocol for all requests on the page). Note: external links are an exception to this rule.
4.5.8. Example of a bad URL:
http://arbitrary.sub.domain.com/314159/RouterThing5.aspx?something%20bad=X#
page2
4.5.9. Example of a good URL:
http://www.domain.com/services/locations-near-you
4.6. Validate assumptions (communicate with your customer / project leader)
4.7. Invite/consider feedback from coworkers
4.8. Use UTF-8-encoding it is ubiquitous character set of the web
4.9. See also:
4.9.1. http://blogs.edgehill.ac.uk/webservices/2008/01/30/bad-urls-part-1-when-urls-
gobad/
4.9.2. http://support.google.com/webmasters/bin/answer.py?hl=en&answer=76329
4.9.3. http://en.wikipedia.org/wiki/UTF-8
4.9.4. http://www.killersites.com/articles/articles_dosAndDontsWebDesign.htm
5. Constraints & Browser Support
5.1. Compliance with regulatory requirements
All 3
rd
party code (e.g. scripts/plugins) must be internally approved for use by the
appropriate compliance team UX standards group.
5.2. Security Considerations
5.2.1. Take security seriously even if you suspect that the parts you are working on are not
important or not connected to any sensitive information. It is your responsibility to do
the best work you can and value our customers and companys privacy and security.
5.2.2. You should be familiar with basic security/vulnerability concepts such as the same-
origin-policy, CORS (cross-origin resource sharing), XSS (cross-site scripting), SQL
injection, MitM (man-in-the-middle) attacks, session hijacking, click-jacking, etc.
5.2.3. All production code must be reviewed by the companys designated information
security teams
5.2.4. Follow all relevant best practices documented as part of OWASP (Open Web
Application Security Project)
5.3. List of supported and tested browsers
5.3.1. Chrome (version 12.0 and above)
5.3.2. Safari (version 4.0 and above)
5.3.3. Firefox (version 4.0 and above)
5.3.4. Internet Explorer 7, 8, 9 and 10
5.3.4.1. IE can easily switch into compatibility mode due to Intranet and network
settings. The following META tag must be included FIRST inside of the <head> to

4 | P a g e

prevent the application/site from defaulting to compatibility mode:
<meta http-equiv="X-UA-Compatible" content="IE=edge">
5.4. List of supported and tested mobile devices
5.4.1. iPhone (iOS 4 and above)
5.4.2. iPad (iOS 4 and above)
5.4.3. Android phone (2.2 and above) TBD
5.4.4. Andriod tablet (4.0 and above) TBD
5.5. See also:
5.5.1. http://en.wikipedia.org/wiki/JavaScript#Security
5.5.2. https://www.owasp.org/index.php/OWASP_AJAX_Security_Guidelines
6. Accessibility Considerations
6.1. While C|A does not need to uphold strict standards regarding accessibility, consider the
standards as they are best practice regardless of accessibility needs
6.2. Consider WAI-ARIA guidelines and 508 standards
6.3. Apply landmark roles to content
6.3.1. The main container of the site should have the role attribute set to main
6.3.2. Navigation should have the role attribute set to navigation
6.3.3. Refer to the W3C WAI-ARIA specification for others (in the See also section)
6.4. There should be a skip to main content link, which is positioned off-screen
6.5. Embedded media/content needs to have an alt attribute defined (may be blank)
6.6. See also:
6.6.1. http://www.w3.org/TR/2006/WD-aria-role-20060926/#Structure
6.6.2. http://www.w3.org/WAI/
6.6.3. http://www.section508.gov/
6.6.4. http://webaim.org/standards/508/checklist
6.6.5. http://www.paciellogroup.com/blog/2010/10/using-wai-aria-landmark-roles/
7. Performance Considerations
7.1. HTTP requests & DNS lookups
7.1.1. Minimize the number of HTTP and DNS requests, but not at the expense of code
quality
7.1.2. Use standard libraries, plugins, and global scripts first to avoid needing to make
additional requests
7.1.3. Take advantage of Googles hosting for available libraries and plugins (jQuery, jQuery
UI, ChromeFrame, etc.): https://developers.google.com/speed/libraries/devguide
7.1.4. If a large set of plugins or scripts is needed on a particular page or collection of pages
then it might be wise to consider bundling them, but this should be done after careful
planning and discussion. It is better not to bundle at all than to bundle carelessly.
7.2. Images, bandwidth & caching
7.2.1. TBD: Use a CDN (content delivery network) for static & shared resources
7.2.2. Use sprites instead of many small images (better performance, less overhead)
7.2.3. Do not use images when standard HTML5 solutions can fulfill the same requirements
7.2.4. Use FontAwesome plugin for standard web icons -
http://fortawesome.github.io/Font-Awesome/
7.2.5. Make sure the hosting servers support compression (e.g. gzip/deflate) MVC 4.5 does
this automatically
7.3. Client-side considerations

5 | P a g e

7.3.1. Avoid binding handlers to extremely frequent events such as mousemove except
when absolutely necessary. In those cases be sure to unbind the handlers when no
longer needed.
7.3.2. When there are many similar event handlers, consider combining them into a single
event handler on a parent element (e.g. delegating)
7.3.3. Concatenating long strings used to be an important performance consideration but is
less important now. Focus on making your code well organized, commented, and
readable.
7.4. See also:
7.4.1. http://www.scriptiny.com/2008/04/introduction-to-web-caching/
7.4.2. https://addons.mozilla.org/en-US/firefox/addon/yslow/
7.4.3. http://developer.yahoo.com/performance/rules.html
7.4.4. http://www.sitepen.com/blog/2008/05/09/string-performance-an-analysis/
7.4.5. http://api.jquery.com/on/
8. HTML
8.1. Adhere to HTML5 standards
All HTML source code must validate against the HTML5 standard validator without any
errors (warnings are acceptable, but should be noted and reviewed)
8.2. Do not use self-closing tags (e.g. <br />) since our HTML is served with the text/html MIME
type not application /html+xml. If self-closing tags are used, the browser just ends up
interpreting the / as a Boolean attribute present on the tag and adding clutter to the
mark-up.
8.3. Focus on structure & content
8.3.1. Keep all styling out of HTML inline and embedded (it MUST be in an external
stylesheet)
8.3.1.1. Avoid styling inside JavaScript as well, unless it is absolutely necessary
8.3.2. Keep JavaScript out of HTML (it belongs in external script files)
8.3.3. Use semantic tags when appropriate (<header>, <navigation>, <article>, <footer>, etc.)
8.3.4. When styling is disabled, the content must render in a readable way
8.4. Only add id values to elements that are used as anchor points in styling or for JavaScript
8.5. When naming id and class values, use meaningful, consistent, representative suffixes.
The following table is provided as an example:

Element(s) / Roles Suffix
Elements whose sole purpose is containing or wrapping other
elements
div, header, footer, article, section, nav
container
Elements containing list items
ul, ol
list
Elements serving as list items
li
item
Elements that direct the user to another page
a
link
Elements that collect information from the user
form
form

6 | P a g e

8.6. The following IE conditional statements must be applied to the body tag:



 <body> 

8.6.1. C|As intranet flags the site as compatibility mode, so for any application that is
accessed via the intranet use the corresponding conditional IE code applied the body
tag.
8.6.2. This directs the browser to render the content in HTML strict mode (please do not
specify any DTD here) and applies classes that can be used for styling even when
JavaScript is not enabled.
8.6.3. Here, no-js, will be automatically removed by modernizr if JavaScript runs.
8.6.4. Here, site-name, should be (manually) replaced with the name selected for this web
site.
8.6.5. The conditional comments are interpreted by Internet Explorer 9 and older.
Though these could be added using JavaScript, it is generally faster and more reliable
to set them this way due to IEs slower JavaScript Virtual Machine.
8.7. The <head> of the HTML document should be arranged in the following order:
8.7.1. Metadata (excluding title)
8.7.2. Global stylesheets
8.7.3. Local/custom stylesheets
8.7.4. Libraries and global scripts/plugins
8.7.5. Local/custom scripts
8.7.6. Title
8.8. Always include the following <meta tags>:
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<meta charset=utf-8>
<meta name=viewport content=width-device-width, initial-scale=1>
8.9. The <body> of the HTML document should contain a <div> with the id set to page which
is used for alignment
8.10. General Markup Guidelines
8.10.1. Use actual <p> elements for paragraph delimiters as opposed to multiple <br/> tags.
8.10.2. Make use of <dl> (definition lists) and <blockquote> when appropriate
8.10.3. Items in list form should always be housed in a <ul>, <ol>, or <dl>, never a set of
<div>s or <p>s.
8.10.4. Use <label> fields to label each form field, the for attribute should associate itself
with the input field, so users can click the labels. cursor:pointer on the label is wise
as well.
8.10.5. Do not use the size attribute on your input fields. The size attribute is relative to
the font-size of the text inside the input. Instead use css width.
8.10.6. Place an HTML comment on some closing div tags to indicate what element youre
closing. It will help when there is lots of nesting and indentation. This is critical since
we use bootstraps grid layout.
8.10.7. Tables cannot be used for page layout.
8.10.8. Make use of <thead>, <tbody>, and <th> when appropriate.
8.11. See also:
8.11.1. http://validator.w3.org/

7 | P a g e

8.11.2. http://www.w3.org/TR/html401/struct/global.html#h-7.4.1
8.11.3. http://modernizr.com/docs/
8.11.4. http://developers.whatwg.org/
9. CSS
9.1. Following patterns and principles from OOCSS is encouraged
9.1.1. Separate structure and skin always
9.1.2. Separate container and content
9.2. Use CSS3 for modern browsers. Use the IE classes placed on the body tag (see 8.6 above) to
target specific IE browsers for graceful degradation.
9.3. NEVER include styles inline in the document, either in a style tag or inline on the HTML.
Always place CSS in external stylesheets.
9.4. Use the LINK tag to include, never the @import.
9.5. Use normalize.css (see 2.1.2) to make rendering consistent across browsers.
9.6. Elements that occur only once inside a document should use IDs, otherwise, use classes.
9.7. Understand cascading and selector specificity so you can write very terse and effective
code.
9.8. All id and class names must only be composed of lowercase letters and (hyphen)
characters
9.9. The flow of the stylesheet ought to follow the flow of the page (e.g. style for top of page
should be at the top & related sections should be near each other)
9.10. Avoid duplication use cascading (e.g. broader definitions should be placed before
more specific ones)
9.11. Favor use of compact/shorthand version of properties but follow proper syntax
Example: (Syntax is background: color position size repeat origin clip attachment image;)

background: #fff 0 0 contain repeat-x padded-box content-box fixed "//a.com/image.jpg";
or
background-color: #fff;
but not
background: #fff; /* Please dont do this! */

9.12. When grouping selectors, each one should be on a separate line
9.13. Closing brace should be indented to align with property settings
9.14. Example:

#some-id.some-class,
#other-id > a.other-class {
display: block;
}

9.15. Properties should be ordered/sorted consistently
The preferred ordering of CSS properties is as follows:

/* Display & Flow */
display
visibility
float

8 | P a g e

clear

/* Positioning */
position
top
right
bottom
left
z-index

/* Dimensions */
width
min-width
max-width
height
min-height
max-height
overflow

/* Margins, Padding, Borders, Outline */
margin
margin-top
margin-right
margin-bottom
margin-left

padding
padding-top
padding-right
padding-bottom
padding-left

border
border-top
border-right
border-bottom
border-left

border-width
border-top-width
border-right-width
border-bottom-width
border-left-width
border-style
border-top-style
border-right-style
border-bottom-style
border-left-style

9 | P a g e


outline

list-style
table-layout
caption-side
border-collapse
border-spacing
empty-cells

/* Typographic Styles */
font
font-family
font-size
line-height
font-weight
text-align
text-indent
text-transform
text-decoration
letter-spacing
word-spacing
white-space
vertical-align
color

/* Backgrounds */
background
background-color
background-image
background-repeat
background-position

/* Opacity, Cursors, Generated Content */
opacity
cursor
user-select
user-drag
content
quotes

9.16. When using vendor prefixes, they should be ordered from least-common to most
common:
(more obscure prefixes can be placed here)
-khtml (for Konqueror)
-o (for Opera)
-ms (for Microsoft)
-moz (for Mozilla/Firefox)

10 | P a g e

-webkit (for Webkit/Safari)
(actual standard property value goes at the end)
9.17. See also
9.17.1. http://fordinteractive.com/2009/02/order-of-the-day-css-properties/
9.17.2. http://www.webdesignerdepot.com/2009/05/10-best-css-practices-to-improve-
yourcode/
9.17.3. https://github.com/stubbornella/oocss/wiki
10. Images
10.1. When possible, do not force bandwidth-sensitive clients (e.g. mobile users) to
download high-resolution images.
10.2. Do not use GIF images, except in the rare case an animation is required
10.3. For repeating images, use something larger than 1x1 pixel
10.4. You should never be using spacer images.
10.5. Use CSS sprites generously. They make hover states easy and improve performance.
10.6. Typically, all images should be sliced with a transparent background (PNG8). All
should be cropped tightly to the image boundaries.
10.7. Image Formats
10.7.1. Use PNG8 as much as possible, with the exception of photographs.
10.7.2. JPEG should always be used for photographs, but make sure you Save for the web
and optimize for file-size.
10.7.3. Avoid GIFs.
11. JavaScript
11.1. We primarily develop applications in jQuery, although we have expertise in plain
JavaScript.
11.2. 99% of code should be housed in external JavaScript files.
11.2.1. Plugins.js should hold all plugin code (see 7.1.4)
11.3. Do not use document.write().
11.4. Name variables and functions logically
11.4.1. Names should be descriptive another developer should be able to easily determine
the purpose of a variable or function. Ex: popUpWindowForAd rather than
myWindow
11.4.2. Avoid abbreviating words, especially short ones. Ex: use text not txt
11.4.3. Use camelCase (first letter lowercase, first letters of subsequent words capitalized)
11.5. Comment your code! It helps reduce time spent troubleshooting JavaScript
functions.
11.6. Encapsulate/scope appropriately in general, the more localized: the better.
To avoid conflicts, it is generally recommended to wrap a script entirely in an anonymous
function within a jQuery ready callback, such as is done in the following example:

jQuery(document).ready(function($) {
// Code goes here
});

11.7. Organize code into logical functions

11 | P a g e

11.8. Any type of debug code should be marked and must not be released to production.
Whenever possible, debug code should be in a separate file that is never promoted from
one environment to another.
11.9. When to use Ajax calls refer to Application development standards
11.10. See also:
11.10.1. http://amix.dk/blog/post/19496
11.10.2. https://www.owasp.org/index.php/Leftover_Debug_Code
11.10.3. https://developer.mozilla.org/en/Introduction_to_Object-
Oriented_JavaScript
11.10.4. http://www.webcredible.co.uk/user-friendly-resources/css/planning-
stylesheet.shtml
11.10.5.

Front End Standards

Uploaded by

Copyright:

Available Formats

You might also like

Front End Standards

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Front End Standards

Uploaded by

Copyright:

Available Formats

1 | P a g e

Copyright 2013 by Cambridge Associates LLC. All rights reserved. Confidential.

You might also like