Interactive Development Best Practices

April 29, 2012

Documenting best practices for interactive development is an exhaustive task, and is one that, if done effectively, would fill the pages of several books. The purpose of this guide is not to provide an all-encompassing list of best practices, but to highlight many of the most important components of a stable, high performance web page.

CSS

Never Use Inline Styles

It may be tempting to declare styles for an element within a style attribute. For example:
Inline styling
```
<p style="color:red; font-size:1.4em;">Wrong way to style</p>		
```
Declaring styles for an element this way usually leads to maintenance issues, as you would now have to keep track of styles declared both in the HTML itself as well as in an external stylesheet.

The style declared in the HTML tag attribute also loses out on context. When looking at styles within a (well organized) CSS document, you can see all other styles that may be applied to the element, including those that may be applied to its parent or other ancestors (this "cascade" is the C in CSS).

Finally, inline styles will override externally defined styles, even those intentionally given a high cascade weight. This can make debugging difficult when a developer is expecting external styles to be applied.

For reasons similar to these, it is usually best to avoid using <style> elements as well, though there may occasionally be an exception to the rule in this case.
Place All CSS Within the <head>

Technically speaking, links to external stylesheets and <style> elements may be placed almost anywhere within an HTML page. However, it is considered to be a best practice to put all styles within the <head> of a page to improve the perceived load time of the page.

When styles are included within the <body> element, they may be applied after elements have already rendered on the page. This can cause “jumpy” effects as styles are retroactively applied to the rendered elements.

The actual loading time of the page (as opposed to the perceived loading time) can be affected as well, as application of certain styles causes the browser to repeat certain page loading actions (such as determining element layout and “painting” the rendered page).
Combine CSS Files

Browsers can only request a limited number of files from the server concurrently. This leads to a staggered download profile, and the loading time of a page will increase dramatically along with the number of assets that need to be requested from the server.

One way to avoid excess server round-trip time is to combine assets into fewer files. For this reason, if a given set of styles is going to be used across a site, it almost always makes the most sense to combine all of these styles into a single stylesheet.

For further details, read Google's documentation on minimizing round trips.
Use <link> to Include CSS, Not @import

There are two ways to include a stylesheet in your web page. You can use the <link> tag:
The <link> method
```
<link rel='stylesheet' href='css/main.css'>		
```
Or you can use the @import rule:
The @import method
```
<style>
    @import url('a.css');
</style>		
```
Steve Souders, author of High Performance Web Sites, recommends the use of the <link> element over the @import rule for performance reasons, among other things. You can find his blog article on the subject here.
Use a CSS Reset

Unfortunately for interactive developers, the baseline styles applied to HTML elements differ widely from browser to browser. It is a long standing practice to include a CSS reset within the global stylesheet for a website. This is the best way to ensure a consistent result from browser to browser. There are many such resets, but one good one that has been adapted for the use of HTML5 elements can be found here

Normalize.css

One criticism of CSS resets is that the browser default styles are useful, and having to redefine them after resetting everything is wasteful. Normalize.css seeks to address these concerns by preserving default styles, changing only those styles necessary to ensure consistency across browsers.

The resetters will be quick to point out that the browser landscape is ever-changing, and it may be dangerous to assume that these normalizations will hold up indefinately without maintenance.

As with anything else, the decision of whether to user a reset or Normalize.css depends on the needs of your project and your team's level of comfort with each approach.
Specifying Font Sizes

Font sizes can be specified in several ways: pixels, percentages, ems, and points. The choice as to which should be used largely depends on what browsers you are obligated to support for your project. Modern browsers provide either text resizing of pixel units and/or full-page zooming, but Internet Explorer 6 relies on relative font sizing (like ems or percentages) for this functionality. A good rule of thumb is to use pixels (which offer the most absolute control of font sizes) if you are not obligated to support IE6.

If IE6 must be supported, it helpful to recognize that, by default, body text size is set to 16 pixels across all major browsers (one thing they managed to do the same, thankfully). Since calculating em values based on the number 16 is tiresome, a good practice is to set the font size of the body element to 0.625em. This converts the baseline font size to 10 pixels, and other font sizes can be given as a multiplier of 10 (which is easy to handle mentally).

For instance, if a design calls for paragraph text to be 12 pixels in size and <h1> text to be 18 pixels, you would specify the following styles:
Example of using ems to support text resizing in IE6
```
body{
    font-size:0.625em;          /* equivalent to 10px */
}
p{ 
    font-size:1.2em;            /* equivalent to 12px */
    line-height:1.25em;         /* relative to the p font size, so 15px */
}
h1{ 
    font-size:1.8em;            /* equivalent to 18px */
}
```
Writing Good Selectors

Writing good CSS selectors is important for maintainability and performance. To understand why, you have to first realize two things: browsers parse CSS selectors from right to left, and different selector types have different relative weights (this latter part is called CSS specificity).

Let's use the following set of selectors as a reference to illustrate these concepts:
CSS selector examples
```
.highlight{					
    color:blue;
}
span.highlight{
    color:red;
}
#note-section .highlight{
    color:yellow;
}
div.footer .highlight{
    color:green;
}
```
If we were to assume that browsers parsed as we read, from left to right, then we would think that each of these selectors is more efficient than the last. The opposite is true. It is faster for a browser to find all elements with the highlight class than it is to first find those elements, then verify that each of those elements meets the additional selector requirements (such as being a <span>, or having a <div> as an ancestor).

Of course we can't always use the simplest selectors. We may want our highlights to be blue in general, but yellow within the note section of our page and green within the footer. This is where being more specific helps, but there's a problem with our example set above: ID selectors are infinitely more powerful than class selectors, so the footer highlight will end up being yellow, not green.

The only way to trump the ID selector would be to add an another ancestor element with an ID selector into the selection chain, or to use the !important designator. You can probably see how this can escalate into a selector arms race, with each overriding selector getting longer and longer (not to mention slower and slower!).

To avoid these issues, here are some specific guidelines to follow:
- Use the simplest selector necessary to reach your target elements and override any pre-existing styles (note that an equivalent selector located lower in the source code is sufficient for this)
- Avoid ID selectors unless you're certain that the style will never be overridden
- Never use the !important designator
- Avoid the wildcard selector (*)
- Don't qualify ID selectors (e.g. div#myid) or class selectors (e.g. table.results) unless its necessary for readability or for efficiency
For further reading, check out these articles on selector efficiency, CSS specificity, and browser support for CSS selectors
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:
Useful Links

The web is rife with CSS tools and references. Some useful links are provided below: