Home / Unlabelled / Comprehensive Overview of Coding Standards

Comprehensive Overview of Coding Standards

Front-end Code Standards & Best Practices

Overview

This document contains guidelines for web applications built by the Creative Technology (front end engineering) practice of Roundarch Isobar. It is to be readily available to anyone who wishes to check the iterative progress of our best practices.
This document's primary motivation is two- fold: 1) code consistency and 2) best practices. By maintaining consistency in coding styles and conventions, we can ease the burden of legacy code maintenance, and mitigate risk of breakage in the future. By adhering to best practices, we ensure optimized page loading, performance and maintainable code.
{}

General Guidelines◊Back to Top

Pillars of Front-end Development◊

  1. Separation of presentation, content, and behavior.
  2. Markup should be well-formed, semantically correct and generally valid.
  3. Javascript should progressively enhance the experience.

General Practices◊

Indentation◊

For all code languages, we require indentation to be done via soft tabs (using the space character). Hitting Tab in your text editor shall be equivalent to four spaces.

Readability vs Compression◊

We prefer readability over file-size savings when it comes to maintaining existing files. Plenty of whitespace is encouraged, along with ASCII art, where appropriate. There is no need for any developer to purposefully compress HTML or CSS, nor obfuscate JavaScript.
We will use server-side or build processes to automatically minify and gzip all static client-side files, such as CSS and JavaScript.
{}

Markup◊Back to Top

The first component of any web page is the tag-based markup language of HTML. The Hyper Text Markup Language (HTML) has a sordid history but has come into its own in the last few years. After a lengthy experimentation with the XML-based XHTML variant the industry has accepted that HTML is the future of the web.
Markup defines the structure and outline of a document and offers a structured content. Markup is not intended to define the look and feel of the content on the page beyond rudimentary concepts such as headers, paragraphs, and lists. The presentation attributes of HTML have all been deprecated and style should be contained in style sheets.

HTML5◊

HTML5 is a new version of HTML and XHTML. The HTML5 draft specification defines a single language that can be written in HTML and XML. It attempts to solve issues found in previous iterations of HTML and addresses the needs of web applications, an area previously not adequately covered by HTML. (source).
We will use the HTML5 Doctype and HTML5 features when appropriate.
We will test our markup against the W3C validator, to ensure that the markup is well formed. 100% valid code is not a goal, but validation certainly helps to write more maintainable sites as well as debugging code. Roundarch Isobar does not guarantee code is 100% valid, but instead assures the cross-browser experience is fairly consistent.

Template◊

For HTML5 Documents we use a fork of H5BP modified for our own project needs. Fork the Github repository.

Doctype◊

A proper Doctype which triggers standards mode in your browser should always be used. Quirks mode should always be avoided.
A nice aspect of HTML5 is that it streamlines the amount of code that is required. Meaningless attributes have been dropped, and the DOCTYPE declaration has been simplified significantly. Additionally, there is no need to use CDATA to escape inline JavaScript, formerly a requirement to meet XML strictness in XHTML.
HTML5 Doctype
1.

Character Encoding◊

All markup should be delivered as UTF-8, as its the most friendly for internationalization. It should be designated in both the HTTP header and the head of the document.
Setting the character set using tags.
1.<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
In HTML5, just do:
1.<meta charset="utf-8">

General Markup Guidelines◊

The following are general guidelines for structuring your HTML markup. Authors are reminded to always use markup which represents the semantics of the content in the document being created.
  • Use actual P elements for paragraph delimiters as opposed to multiple BR tags.
  • Make use of DL (definition lists) and BLOCKQUOTE, when appropriate.
  • Items in list form should always be housed in a UL, OL, or DL, never a set of DIVs or Ps.
  • 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. note 1 note 2
  • 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.
  • Place an html comment on some closing div tags to indicate what element you're closing. It will help when there is lots of nesting and indentation.
  • Tables shouldn't be used for page layout.
  • Use microformats and/or Microdata where appropriate, specifically hCard and adr.
  • Make use of THEAD, TBODY, and TH tags (and Scope attribute) when appropriate.
    Table markup with proper syntax (THEAD,TBODY,TH [scope])
    01.<table summary="This is a chart of year-end returns for 2005.">
    02.<thead>
    03.<tr>
    04.<th scope="col">Table header 1</th>
    05.<th scope="col">Table header 2</th>
    06.</tr>
    07.</thead>
    08.<tbody>
    09.<tr>
    10.<td>Table data 1</td>
    11.<td>Table data 2</td>
    12.</tr>
    13.</tbody>
    14.</table>
  • Always use title-case for headers and titles. Do not use all caps or all lowercase titles in markup, instead apply the CSS property text-transform:uppercase/lowercase.

Quoting Attributes◊

The HTML5 specification defines quotes around attributes as optional. For consistency with attributes that accept whitespace, all attributes should be quoted.
1.<p class="line note" data-attribute="106">This is my paragraph of special text.</p>
{}

CSS◊Back to Top

The second component of a web page is the presentation information contained in the Cascading Style Sheet (CSS.) Web browsers successful implementation of CSS has given a whole generation of web authors site-wide control over the look and feel of their web sites.
Just as the information on a web page is semantically described in the HTML Markup, CSS describes all presentation aspects of the page via a description of its visual properties. CSS is powerful in that these properties are mixed and matched via identifiers to control the page's layout and visual characteristics through the layering of style rules (the "cascade").

General Coding Principles◊

  • Add CSS through external files, minimizing the # of files, if possible. It should always be in the HEAD of the document.
  • Use the LINK tag to include, never the @import.
    Including a stylesheet
    1.<link rel="stylesheet" type="text/css" href="myStylesheet.css" />
    Don't use inline styling
    1.<p style="font-size: 12px; color: #FFFFFF">This is poor form, I say</p>
  • Don't include styles inline in the document, either in a style tag or on the elements. It's harder to track down style rules.
  • Use normalize.css to make rendering more consistent across browsers.
  • Use a font-normalization file like YUI fonts.css
  • Elements that occur only once inside a document should use IDs, otherwise, use classes.
  • Understand cascading and selector specificity so you can write very terse and effective code.
  • Write selectors that are optimized for speed. Where possible, avoid expensive CSS selectors. For example, avoid the * wildcard selector and don't qualify ID selectors (e.g. div#myid) or class selectors (e.g. table.results.) This is especially important with web applications where speed is paramount and there can be thousands or even tens of thousands of DOM elements. More on writing efficient CSS on the MDC.

CSS Box Model◊

Intimate knowledge and understanding of the CSS and browser-based box model is necessary for conquering the fundamentals of CSS layouts.
CSS Box Model
3D CSS Box Model diagram by Jon Hicks.

CSS Validation◊

We typically don't use the W3C validator.

CSS Formatting◊

At minimum, format CSS with selectors on one line and each property on its own line. The declarations are indented.
As an enhancement to that style, related or child styles and additional 2 or 4 spaces. That allows for hierarchical scanning and organization and makes (for some people) an easier-to-read style sheet.
Also, if you specify multiple selectors, it's a good idea to start each on new line. This prevents lines from growing long and improves readability as well as version control workflow.
01..post-list li a{
02.color:#A8A8A8;
03.}
04..post-list li a:hover{
05.color:#000;
06.text-decoration:none;
07.}
08..post-list li .author a,
09..post-list li .author a:hover{
10.color:#F30;
11.text-transform:uppercase;
12.}
For multiple author environments, single line CSS should be avoided because it can cause issues with version control.

Alphabetize◊

If you're performance obsessed alphabetizing CSS properties increases the odds of larger repeatable patterns being present to aid in GZIP compression.

Classes vs. IDs◊

You should only give elements an ID attribute if they are unique. They should be applied to that element only and nothing else. Classes can be applied to multiple elements that share the same style properties. Things that should look and work in the same way can have the same class name.
1.<ul id="categories">
2.<li class="item">Category 1</li>
3.<li class="item">Category 2</li>
4.<li class="item">Category 3</li>
5.</ul>

Naming Conventions for Selectors◊

It is always preferable to name something, be it an ID or a class, by the nature of what it is rather than by what it looks like. For instance, a class name of bigBlueText for a special note on a page is quite meaningless if it has been changed to have a small red text color. Using a more intelligent convention such as noteText is better because when the visual style changes it still makes sense.

Selectors◊

The CSS Selectors Level 3 specification introduces a whole new set of CSS Selectors that are extremely useful for better selection of elements.

Pseudo-classes◊

Pseudo-classes enable you to dynamically style content. Some pseudo-classes have existed since CSS1 (:visited, :hover, etc.) and CSS2 (:first-child, :lang). As of CSS3, 16 new pseudo-classes have been added to the list and are especially useful for styling dynamic content. Learn how to use pseudo-classes in-depth.

Combinators & Attribute Selectors◊

Combinators provide shortcuts for selecting elements that are a descendant element, a child element, or an element's sibling.
Attribute Selectors are great for finding elements that have a specific attribute and/or specific value. Knowledge of regular expressions helps with attribute selectors.

Specificity◊

Browsers calculate a selector's specificity to determine which CSS rule should apply. If two selectors apply to the same element, the one with the higher specificity wins.
IDs have a higher specificity than attribute selectors do, and class selectors have higher specificity than any number of element selectors. Always try to use IDs to increase the specificity. There are times when we may try to apply a CSS rule to an element and it does not work no matter what we try. This is likely because the specificity of the selector used is lower than another one and the properties of the higher one are taking precedence over those you want to apply. This is more common in working with larger more complex stylesheets. It isn't a big issue with smaller projects usually.
Calculating specificity◊
When working with a large and complex stylesheet it helps to know how to calculate the value of a selector's specificity, to save you time and to make your selectors more efficient.
Specificity is calculated by counting various components of your CSS and expressing them in a form (a,b,c,d).
  • Element, Pseudo Element: d = 1 – (0,0,0,1)
  • Class, Pseudo class, Attribute: c = 1 – (0,0,1,0)
  • Id: b = 1 – (0,1,0,0)
  • Inline Style: a = 1 – (1,0,0,0)
However, it may be better to use a specificity calculator.
  • Specificity Calculator
  • Some things you should know about specificity
  • IE Specificity bugs
Using !important overrides all specificity no matter how high it is. We like to avoid using it for this reason. Most of the time it is not necessary. Even if you need to override a selector in a stylesheet you don't have access to, there are usually ways to override it without using !important. Avoid using it if possible.

Pixels vs. Ems◊

We use the px unit of measurement to define font size, because it offers absolute control over text. We realize that using the em unit for font sizing used to be popular, to accommodate for Internet Explorer 6 not resizing pixel based text. However, all major browsers (including IE7 and IE8) now support text resizing of pixel units and/or full-page zooming. Since IE6 is largely considered deprecated, pixels sizing is preferred. Additionally, unit-less line-height is preferred because it does not inherit a percentage value of its parent element, but instead is based on a multiplier of the font-size.
Correct
1.#selector {
2.font-size: 13px;
3.line-height: 1.5;  /*  13 * 1.5 = 19.5 ~ Rounds to 20px. */
4.}
Incorrect
1./*  Equivalent to 13px font-size and 20px line-height, but only if the browser default text size is 16px. */
2.#selector {
3.font-size: 0.813em;
4.line-height: 1.25em;
5.}

Internet Explorer Bugs◊

Inevitably, when all other browsers appear to be working correctly, any and all versions of Internet Explorer will introduce a few nonsensical bugs, delaying time to deployment. While we encourage troubleshooting and building code that will work in all browsers without special modifications, sometimes it is necessary to use conditional if IE comments for CSS hooks we can use in our stylesheets. Read more on paulirish.com
Fixing IE
1.
2.
3.
4.
5. <body>
1..box { float: left; margin-left: 20px; }
2..ie6 .box { margin-left: 10px; }
If you're using HTML5 (and the HTML5 Boilerplate) we encourage the use of the Modernizer JavaScript library and this pattern:
1.
2.
3.
4.
5.<html class="no-js" lang="en">

Shorthand◊

In general, CSS shorthand is preferred because of its terseness, and the ability to later go back and add in values that are already present, such as the case with margin and padding. Developers should be aware of the TRBL acronym, denoting the order in which the sides of an element are defined, in a clock-wise manner: Top, Right, Bottom, Left. If bottom is undefined, it inherits its value from top. Likewise, if left is undefined, it inherits its value from right. If only the top value is defined, all sides inherit from that one declaration.
For more on reducing stylesheet code redundancy, and using CSS shorthand in general:
  • http://qrayg.com/journal/news/css-background-shorthand
  • http://sonspring.com/journal/css-redundancy
  • http://dustindiaz.com/css-shorthand

Images◊

  • For repeating images, use something larger than 1x1 pixels
  • You should never be using spacer images.
  • Use CSS sprites generously. They make hover states easy, improve page load time, and reduce carbon dioxide emissions.
  • Typically, all images should be sliced with a transparent background (PNG8). All should be cropped tightly to the image boundaries.
    • However, the logo should always have a background matte and have padding before the crop. (so other people can hotlink to the file)

Color Management◊

  • Verify that all members on your team have consistent color management settings.
    • Any given two monitors most likely display the colors differently, but sRGB color profile must be your default.
    • When you open files in Photoshop, pay attention to Color Profile warnings and notify team members when Photoshop is suggesting to convert an image to a different profile.
  • Never embed a color profile in your images.
    • When you Save for Web and Devices from Photoshop, be sure to uncheck "Embed Color Profile."

General Text and Font Styling◊

Headings◊

  • Define default styling for h1-h6 headings including headings as links. It's helpful to declare these at the top of your CSS document, and modify them with as necessary for consistency across the site.
  • Headings should show a hierarchy indicating different levels of importance from the top down starting with h1 having the largest font size.
  • SEO: To get a rough idea of how your page hierarchy is organized and read, use your Developer Toolbar to disable CSS. You'll end up with a text-based view of all your h1-h6 tags, strong, em, etc.

Links◊

  • Default styles for links should be declared and different from the main text styling, and with differing styles for hover state.
  • When styling links with underlines use border-bottom and some padding with text-decoration: none;. This just looks better.

Web Typography◊

The use of custom fonts and typefaces on the web has been growing more popular the past few years. with native browser support on the rise and several supporting services and APIs now available there is real momentum in this space. Each of these approaches have their own pros and cons. Before a project kicks off it's best to do research into technology and licensing limitations to choose the proper approach for the specific project.
All of these approaches have drawbacks in code overhead, development time and performance (clock and perceived). Familiarizing yourself with these issues and communicating them to the other members of the team and to the client will save significant problems later on in the project.
Listed here are some popular methods of embed custom fonts, list in the order of our preference for implementation.

@font-face◊

The @font-face at-rule allows you to define custom fonts. It was first defined in the CSS2 specification, but was removed from CSS2.1. Currently, it's a draft recommendation for CSS3.
Our first and most preferred choice for customizing fonts on the web is @font-face, simply because it is part of the CSS Fonts Module working draft which means it will continue to grow in popularity as browser support grows, and ease of use for it improves as it becomes more stable.
For now, when using @font-face it's recommended to declare the source for each font format. This is important if you want it to work in the most number of browsers, though it is not a requirement for use.
The font formats included in the specification are:
  • woff: WOFF (Web Open Font Format)
  • ttf: TrueType
  • ttf, otf: OpenType
  • eot: Embedded OpenType
  • svg, svgz: SVG Font

Bulletproof @font-face◊

For full cross-browser compatibility use Fontsprings' new bulletproof @font-face syntax (latest version as of 2/21/11).
01.@font-face {
02.font-family: 'MyFontFamily';
03.src: url('myfont-webfont.eot');                     /* IE9 Compat Modes */
04.src: url('myfont-webfont.eot?iefix') format('eot'), /* IE6-IE8 */
05.url('myfont-webfont.woff') format('woff'),     /* Modern Browsers */
06.url('myfont-webfont.ttf') format('truetype'),      /* Safari, Android, iOS */
07.url('myfont-webfont.svg#svgFontName') format('svg'); /* Legacy iOS */
08.font-weight: ;
09.font-style: ;
10.// etc.
11.}
Here's a working demo using this version of implementation.

Cross-Browser Compatibility◊

Safari, IE 6-9, IE 9 Compatibility Modes, Firefox, Chrome, iOS, Android, Opera

Prevent Compatibility Mode◊

Sometimes IE can have a mind of its own and will switch to compatibility mode without you knowing. Include the following in the site to prevent your site from defaulting to compatibility mode:
1.<meta http-equiv="X-UA-Compatible" content="IE=edge">

Tips for @font-face◊

  • IE 6–8 will only accept a TrueType font packaged as an EOT.
  • font-weight and font-style have different meanings within @font-face. Declarations where font-weight:bold; means this is the bold version of this typeface, rather than apply bold to this text
  • @font-face gotchas
Pros
  • Easy to implement
  • Large variety of APIs
  • Customizable
  • Easy to add to elements
  • Nothing required besides CSS
  • Is currently part of the working draft of CSS Fonts Module 3
Cons
  • Limited browser support if used improperly
  • Some older versions of modern browsers (Chrome, Opera) don't always render well. Text can have rough edges. **I have not been able to confirm whether this is still an issue now or not.

Google WebFonts API & Font Loader◊

There are two options available with Google Webfonts. Both options have their downsides of course but they can be just as good to use as @font-face, it all depends on a projects needs.

Webfonts API◊

Google's Webfonts API essentially does the same thing as @font-face, it just does all the hard work for you, providing wider browser support.The major drawback to this method is the very small font library it uses. To make it work all you need to do is include the stylesheet + the font name.
1.<link rel="stylesheet" type="text/css" href="http://fonts.googleapis.com/css?family=Font+Name">
Then define a style for the selector you want to apply the font to:
1.CSS selector {
2.font-family: 'Font Name', serif;
3.}

Webfont Loader◊

Another option Google offers is the Webfont Loader which is a JavaScript library that allows for more control than the font API does. You can also use multiple webfont providers like Typekit. To use it include the script in your page:
01.
Including the webfont.js file this way is faster if not already using the Ajax APIs. Otherwise you should use this:
1.
2.
By using the Webfont Loader you have more ability to customize things including the use of more fonts, not just those in the Google Webfont library which is not large. However, it then requires you to load JavaScript, sacrificing one thing for another.
Pros
  • Very easy to implement
  • Wide browser support
  • Can be combined with Typekit
  • Customizable when using the font loader
  • API does the same thing as @font-face
Cons
  • Very small font library if using the font API
  • Using the Webfont Loader requires the use of JavaScript to work
  • Most browsers will load the rest of the page first, leaving a blank space where the text would be, or otherwise show the fallback option if one exists, until the page fully loads.
  • Some fonts in the webfont library render poorly on Windows

Cufon◊

If you choose to use Cufon, it is highly recommended you use the Cufon compressed version. You will need to convert your font using the generator.
1.
2.
3.
We recommend using Cufon sparingly since it can cause a lot of overhead if applied to a large amount of text. For more info visit the Cufon Wiki.
Pros
  • Wide browser support
  • Renders well in supported browsers
  • Customizable
  • Easy to implement
Cons
  • Requires use of JS to work
  • Text can't be selected that uses it
  • Not all characters can be used
  • Customization can be a pain
  • Not always easy to apply to multiple elements, especially when adding effects like hovers

Typekit◊

Using Typekit has its advantages and shouldn't be completely disregarded when choosing which method to use for adding custom fonts to a web site. It has strong platform integration and is a scalable and popular service. It can be used with Google Webfonts and is easily added to WordPress, Posterous, Typepad, and other similar CMS powered sites.
However, full use of Typekit doesn't come without a cost. If you need to use it on more than 2 sites or on a site that gets a high amount of pageviews you will need to pay an annual cost of $49.99, and for sites with a million+ pageviews it costs twice as much. Though, you probably have the money to cover the cost if you're getting over a million pageviews. If not then you may want to rethink your business model.
Pros
  • Large font library, including Adobe fonts
  • Easy implementation
  • Google Webfont API and blogging platform integration
  • Free plan has limits but doesn't expire
Cons
  • Requires JavaScript to use
  • Limited font library access without paying
  • Free and cheapest plans only allow use on 1-2 web sites and 2-5 fonts per site
  • You have to pay to use it on more than 1 site

Scalable Inman Flash Replacement (sIFR)◊

We do not recommend that you use this method but because of how widely used it is we felt it was necessary to include so you could make a properly informed decision when choosing which method to go with for customized webfonts.
Despite its wide popularity among web designers, and its decent support in most browsers, the drawbacks to its use outweigh its convenience. The biggest and most obvious reason to not use sIFR is the fact that it uses Flash. Plus, in order for the Flash to even work, it requires JavaScript and the scripts must be loaded before the text you use it on is visible on the page. Not to mention that it increases page load time, and can cause a slow site to be even slower.
We'll let you do the math here.
Pros
  • Text can be selected
  • Support on most browsers
  • Renders okay on supported browsers
Cons
  • It uses Flash
  • Requires JavaScript for the Flash to work
  • It's Flash!
  • Text doesn't appear until the scripts load
  • ...and it's Flash...

Font Licensing◊

Even though you can transform just about any font into a web font file, you should still make sure it is legally okay for you to do so. Many foundries have updated their conditions to specify how their fonts can be used on the web. View Font Licensing and Protection Details for more information.

Specifications & Font File Formats◊

Use CSS3◊

You can do a lot of new things with the added features in the CSS3 spec, many of which are not yet fully supported by all the major browsers. That doesn't mean they can't be used today. For the things that aren't supported there are fallback libraries or other 'polyfills' which you can use to fill in the holes where browsers may be lacking some support of a new feature.
There are also browser specific properties or prefixes that can be used to style things too. We recommend using Prefixr.com to make sure you include all the different prefixed browser properties for the sake of cross-browser support.
{}

JavaScript◊Back to Top

JavaScript is the third major component of a web page. JavaScript code, when properly applied to a web page, enhances the overall user and browser-based experience through attaching to events and controlling the overall behavior layer.
JavaScript has seen an explosion in popularity in recent years as powerful new browser implementations have finally empowered the creation of full on browser-based web applications. Additionally, careful use of JavaScript allows for full manipulation and control over the other two components of web page authoring, HTML Markup and CSS. Today the structure of pages and the visual styles of pages can be manipulated real time without full web page refreshes.

JavaScript Libraries◊

We primarily develop new applications in jQuery, though we have expertise in plain JavaScript as well as all major modern javascript libraries.

General Coding Principles◊

  • 99% of code should be housed in external javascript files. They should be included at the END of the BODY tag for maximum page performance.
  • Don't rely on the user-agent string. Do proper feature detection. (More at Dive Into HTML5: Detection & jQuery.support docs)
  • Don't use document.write().
  • All Boolean variables should start with "is".
    Test for positive conditions
    1.isValid = (test.value >= 4 && test.success);
  • Name variables and functions logically: For example: popUpWindowForAd rather than myWindow.
  • Don't manually minify. With the exception of the traditional i, etc. for for loops, variables should be long enough to be meaningful.
  • Documentation should follow NaturalDocs structure.
  • Constants or configuration variables (like animation durations, etc.) should be at the top of the file.
  • Strive to create functions which can be generalized, take parameters, and return values. This allows for substantial code reuse and, when combined with includes or external scripts, can reduce the overhead when scripts need to change. For example, instead of hard coding a pop-window with window size, options, and url, consider creating a function which takes size, url, and options as variables.
  • Comment your code! It helps reduce time spent troubleshooting JavaScript functions.
  • Don't waste your time with comments surrounding your inline javascript, unless you care about Netscape 4. :)
  • Organize your code as an Object Literal/Singleton, in the Module Pattern, or as an Object with constructors.
  • Minimize global variables - the less globals you create, the better. Generally one, for your application namespace, is a good number.
    When specifying any global variable, clearly identify it
    1.window.globalVar = { ... }

White-space◊

In general, the use of whitespace should follow longstanding English reading conventions. Such that, there will be one space after each comma and colon (and semi-colon where applicable), but no spaces immediately inside the right and left sides of parenthesis. In short, we advocate readability within reason. Additionally, braces should always appear on the same line as their preceding argument.
Consider the following examples of a JavaScript for-loop...
Correct
1.for (var i = 0, j = arr.length; i < j; i++) {
2.// Do something.
3.}
Incorrect
1.for ( var i = 0, j = arr.length; i < j; i++ )
2.{
3.// Do something.
4.}
Also incorrect
1.for(var i=0,j=arr.length;i
2.// Do something.
3.}

plugins.js and script.js◊

Starting with H5BP we're presented with two files, plugins.js and script.js. This section outlines basic usage of these two files.

plugins.js◊

Plugins.js is meant to hold all of a sites plugin code. Instead of linking to many different files, we can improve performance by including plugin code directly in this one file. There can and should be exceptions to this usage. An extremely large plugin only used on one rarely visited page, for example, might be better off in a separate download, only accessed on the target page. Most of the time, however, it's safe to just paste in minified versions of all your plugins here for easy access.
Here's what an example file might looks like, including a small table of contents. This can serve as a handy guide for what plugins are in use, including URLs for documentation, rationale for use and the like.
01./* PLUGIN DIRECTORY
02.What you can find in this file [listed in order they appear]
03. 
04.1.) Animate Background Position - http://plugins.jquery.com/project/backgroundPosition-Effect
05.2.) jQuery Easing Plugin - http://gsgd.co.uk/sandbox/jquery/easing/
06.3.) jQuery Ajax Form plugin - http://jquery.malsup.com/form/#download           
07.4.) jQuery validation plugin (form validation) - http://docs.jquery.com/Plugins/Validation
08.-password strength
09.5.) Styled Selects (lightweight) - http://code.google.com/p/lnet/wiki/jQueryStyledSelectOverview
10.*/
11. 
12./**
13.* 1.) Animate Background Position - http://plugins.jquery.com/project/backgroundPosition-Effect
14.* @author Alexander Farkas
15.* v. 1.21
16.*/
17.(function($) {
18.if(!document.defaultView || !document.defaultView.getComputedStyle){ // IE6-IE8
19.//SNIPPED
20.};
21.})(jQuery);
22. 
23. 
24./**
25.* 2.) jQuery Easing Plugin (we're not using jQuery UI as of yet) - http://gsgd.co.uk/sandbox/jquery/easing/
26.*/
27. 
28.// t: current time, b: begInnIng value, c: change In value, d: duration
29.jQuery.easing['jswing'] = jQuery.easing['swing'];
30. 
31.jQuery.extend( jQuery.easing,
32.{
33.//SNIPPED
34. 
35.});
36.;(function($) {
37.$.fn.ajaxSubmit = function(options) {
38.//SNIPPED
39.}
40.})(jQuery);
41. 
42./*
43.* jQuery Styled Select Boxes
44.* version: 1.1 (2009/03/24)
45.* @requires jQuery v1.2.6 or later
46.*
47.* Examples and documentation at: http://code.google.com/p/lnet/wiki/jQueryStyledSelectOverview
48.*
49.* Copyright (c) 2008 Lasar Liepins, liepins.org, liepins@gmail.com
50.*
51.* Permission is hereby granted, free of charge, to any person obtaining a copy
52.* of this software and associated documentation files (the "Software"), to deal
53.* in the Software without restriction, including without limitation the rights
54.* to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
55.* copies of the Software, and to permit persons to whom the Software is
56.* furnished to do so, subject to the following conditions:
57.*
58.* The above copyright notice and this permission notice shall be included in
59.* all copies or substantial portions of the Software.
60.*
61.* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
62.* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
63.* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
64.* AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
65.* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
66.* OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
67.* THE SOFTWARE.
68.*
69.*/
70. 
71.jQuery.fn.styledSelect = function(settings) {
72.//SNIPPED
73.return this;
74.};

Script.js◊

Script.js is meant to hold your site or application code. Again, this isn't always the best solution as larger teams and or larger, more feature rich projects can really benefit from breaking out application code into module or feature specific files. For smaller sites, simpler applications, and initial prototyping, however, dropping your work into scripts.js makes sense.
A simplified example, using the Markup-based unobtrusive comprehensive DOM-ready execution pattern, might look something like the following:
01./* Name: Demo
02.Author: Demo King */
03./*demo namespace*/
04.demo = {
05.common : {
06.init     : function(){
07.//initialize
08.},
09.finalize : function(){
10.//finalize
11.},
12.config : {
13.prop : "my value",
14.constant : "42"
15.}
16.},
17.mapping : {
18.init     : function(){
19.//create a map
20.},
21.geolocate    : function(){
22.//geolocation is cool
23.},
24.geocode : function(){
25.//look up an address or landmark
26.},
27.drawPolylines : function(){
28.//draw some lines on a map
29.},
30.placeMarker : function(){
31.//place markers on the map
32.}
33.}
34.}

Variables, ID & Class◊

All JavaScript variables shall be written in either completely lowercase letter or camelCase. The one exception to this are Constructor functions, which are capitalized by tradition. All id and class declarations in CSS shall be written in only lowercase. Neither dashes nor underscores shall be used.

Event Delegation◊

When assigning unobtrusive event listeners, it is typically acceptable to assign the event listener directly to the element(s) which will trigger some resulting action. However, occasionally there may be multiple elements which match the criteria for which you are checking, and attaching event listeners to each one might negatively impact performance. In such cases you should use event delegation instead.
jQuery's delegate() is preferred over live() for performance reasons.

Debugging◊

Even with the best of validators, inevitably browser quirks will cause issues. There are several invaluable tools which will help to refine code integrity and loading speed. It is important that you have all of these tools available to you, despite the browser you primarily use for development. We recommend developing for Firefox and Safari first, then Google Chrome and Opera, with additional tweaks via conditional comments just for Internet Explorer. The following is a list of helpful debuggers and speed analyzers...
  • Firefox: Firebug, Page Speed, YSlow
  • Safari: Web Inspector
  • Google Chrome: Developer Tools
  • Opera: Dragonfly
  • Internet Explorer 6-7: Developer Toolbar
  • Internet Explorer 8-10: Developer Tools

Patterns for better JavaScript◊

  • Writing Maintainable Code
  • Single var Pattern
  • Hoisting: A Problem with Scattered vars
  • (Not) Augmenting Built-in Prototypes
  • Avoiding Implied Typecasting
  • Avoiding eval()
  • Number Conversions with parseInt()
  • Opening Brace Location
  • Capitalizing Constructors
  • Writing Comments
  • Avoid void
  • Avoid with Statement
  • Avoid continue Statement
  • Avoid Bitwise Operators if possible
Stoyan Stefanov covers these and more in detail here.
{}

Accessibility◊Back to Top

Section 508 Standards for intranet and internet information and applications.
— Interfaces developed by Roundarch Isobar should meet Section 508 standards.
W3C checklist of checkpoints for accessibility.
— Interfaces developed by Roundarch Isobar should meet Priority 1 guidelines.
— The WCAG 1.0 Guidelines.
{}

Performance◊Back to Top

As we continue to push the limits of what the web can do, it remains just as important a web page can be used with minimal effort or wait time. The following section explains how web pages can be optimized to keep all audiences happy.

Optimize Delivery of CSS and JavaScript◊

There are many optimizations that should be done for serving CSS and javascript in Production:
  • Follow the Yahoo Performance Guidelines
  • Smush images using smush.it. Also using YSlow can autosmush all your images for you.
  • Set caching headers appropriately.
  • Consider a cookie-less subdomain for static assets
  • Avoid inline
Comprehensive Overview of Coding Standards Comprehensive Overview of Coding Standards Reviewed by JohnBlogger on 4:33 PM Rating: 5

No comments:

Subscribe to: Post Comments (Atom)