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.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



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 3rd 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 to



prevent the application/site from defaulting to compatibility mode:

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



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. ) 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 (, , , , 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



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

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 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 :

8.9. The of the HTML document should contain a with the id set to page which is used for alignment

8.10. General Markup Guidelines 8.10.1. Use actual elements for paragraph delimiters as opposed to multiple tags. 8.10.2. Make use of (definition lists) and when appropriate 8.10.3. Items in list form should always be housed in a , , or , never a set of

s or s. 8.10.4. Use 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 , , and when appropriate.

8.11. See also: 8.11.1. http://validator.w3.org/



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



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



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)



-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.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.

Documents

Front End Standards