Front-end Code Standards & Best Practices
This document contains guidelines for web applications built by the Creative Technology (front end engineering) practice of 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.
Pillars of Front-end Development
- Separation of presentation, content, and behavior.
- Markup should be well-formed, semantically correct and generally valid.
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
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. Isobar does not guarantee code is 100% valid, but instead assures the cross-browser experience is fairly consistent.
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
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 <meta> tags.
In HTML5, just do:
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.
labelfields to label each form field, the
forattribute 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.
- Always use title-case for headers and titles. Do not use all caps or all lowercase titles in markup, instead apply the CSS property
The HTML5 specification defines quotes around attributes as optional. For consistency with attributes that accept whitespace, all attributes should be quoted.
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.
- 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.
We typically don't use the W3C validator.
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.
For multiple author environments, single line CSS should be avoided because it can cause issues with version control.
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.
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.
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.
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.
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.
!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
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
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:
- 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)
- 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
- Define default styling for
h1-h6headings 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
- 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-bottomand some padding with
text-decoration: none;. This just looks better.
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.
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
For full cross-browser compatibility use Fontsprings' new bulletproof @font-face syntax (latest version as of 2/21/11).
Here's a working demo using this version of implementation.
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
<head> to prevent your site from defaulting to compatibility mode:
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
- Easy to implement
- Large variety of APIs
- Easy to add to elements
- Nothing required besides CSS
- Is currently part of the working draft of CSS Fonts Module 3
- 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.
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.
Then define a style for the selector you want to apply the font to:
Including the webfont.js file this way is faster if not already using the Ajax APIs. Otherwise you should use this:
- Very easy to implement
- Wide browser support
- Can be combined with Typekit
- Customizable when using the font loader
- API does the same thing as
- Very small font library if using the font API
- 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
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
- Easy to implement
- 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
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
- 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.
We'll let you do the math here.Pros
- Text can be selected
- Support on most browsers
- Renders okay on supported browsers
- It uses Flash
- It's Flash!
- Text doesn't appear until the scripts load
- ...and it's Flash...
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
- CSS 2 Fonts – May 1998 (Obsolete)
- CSS 3 Fonts – Working Draft 2009
- CSS Fonts Module – W3C Working Draft March 2011
- WOFF Font Format – Working Draft 2010
- SVG Font Format
- Embedded Open Type (EOT) File Format
- Microsoft Open Type Specification
- OpenType Feature File Specification
- Apple True Type Reference
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.
General Coding Principles
- 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".
- Name variables and functions logically: For example:
- Don't manually minify. With the exception of the traditional
i, etc. for
forloops, 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.
- Don't waste your time with
- 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.
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.
— Interfaces developed by Isobar should meet Section 508 standards.
— Interfaces developed by Isobar should meet Priority 1 guidelines.
- Follow the Yahoo Performance Guidelines
- Smush images using smush.it. Also using YSlow can autosmush all your images for you.
- Avoid inline
<script>blocks within the HTML. They block rendering and are quite devastating to page load time.
- Set caching headers appropriately.
- Consider a cookie-less subdomain for static assets
- CSS should be located in the
- Both should be served using gzip on the wire
- CSS should be concatenated together. Obviously this can only be done for files that share the same media type (e.g. screen or print). The general goal here is to reduce the number of HTTP connections to dependencies during the loading of the page.
- Concatenation and minification typically occur during an automated build process, when packaging the code for deployment on stage or production. Many use tools like Ant or Maven for this.
During a page load, there is typically a lot of script waiting to execute, but you can prioritize it. This order prioritizes based on user response:
- Script that changes the visible nature of the page needs to fire absolutely first. This includes any font adjustment, box layout, or IE6 pngfixes.
- Page content initialization
- Page header, topnav and footer initialization
- Attaching event handlers
- Omniture, Doubleclick, and other 3rd party scripts
Leverage CSS Sprites
CSS Sprites basically take a number of image assets and merge them together into a singular image file. Each part of it is revealed using CSS background-position. Some typical CSS would look like:
It's quite common to leverage sprites for :hover states. In that case you'll see something like:
Using sprites reduces total page weight and reduces HTTP connections which speeds up page load. More on the general technique and overview at css-tricks.com. It is just an overall best practice to make use of CSS sprite images whenever you can.
Many developers use a vertically-oriented sprite in addition to the primary sprite. This vertical sprite will be less than or equal to 100px wide (and tall) and contain icons that are typically placed next to text, such as list item bullets or call to action links and buttons. Yahoo uses a few such as this one.
The one consideration is to not make sprites too large, something over 1000px in either direction will end up using a sizeable amount of memory. Read more on when to use sprites and memory usage here, and for more general tips and techniques on creating sprites check out the Mozilla Dev Blog.
There are four main image formats that should be used, detailed here:
JPEG. - This will cover all photography-based images, such as homepage and category page promo images, or anything with a very high color count.
PNG24. This format, easily accessible in Photoshop, outputs high-color count imagery and fully supports graded opacity by pixel. Relatively, it's quite a heavy format as far as kilobyte weight. It is the only format that IE6 needs to execute a pngfix on. In that case, Isobar recommends the DD_belatedPNG script (A pngfix fixes the issue where PNG24's appear to have a gray or light-blue background in IE6. They are not always compatible with background-position).
In many cases, you can use a GIF fallback for IE6, in place of a PNG24. This is especially true if any sprites need to be done in PNG24. All pngfixes are very slow and expensive, so it's best to avoid using them.
PNG8. - A surprising diversity of color can be captured inside 256 colors, so it's worth trying PNG before heading JPG. PNG also is a lot more compressible than GIF (using tools like pngcrush and pngquant). This format allows graded opacity in nearly all browsers, but in IE6, those semi-opaque pixels are just shown 100% transparent. In many cases this is sufficient. It also does not require a pngfix script to be run, so it's optimized for speed.
Photoshop cannot output these semi-opaque files correctly but Fireworks can. More detail here: http://www.sitepoint.com/png8-the-clear-winner/
Transparent GIF 89a. - GIF 89a offers the flexibility of transparency and wide browser support, but the constraints of no graded opacity nor a color depth above 256. In our experience, color depths of 64 still provide very good quality thumbnails, and keep the file size comparably very small.
All low-color count imagery such as icons or thematic graphics should be done in PNG8, as it's the most size-efficient of these four. PNG8 is our primary recommendation for most site graphics.
Detailed information on the PNG format, browser support, and the pros and cons of each can be found in this excellent article.
For further optimization all of these formats, taking them through Yahoo's Smush.It will reveal how they can be smaller.
For static content, the browser should cache the file locally as long as is reasonable. Content that should have far future caching includes:
- product images
- thematic graphics
- flash .swf's
- promo images (lighter caching likely)
For the best caching, leverage the Expires http header. This is a far future Expires header, telling the browser that this response won't be stale until April 15, 2015.
Expires: Thu, 15 Apr 2015 20:00:00 GMT
If your server is Apache, use the ExpiresDefault directive to set an expiration date relative to the current date. This example of the ExpiresDefault directive sets the Expires date 1 year out from the time of the request.
ExpiresDefault "access plus 1 year"
Expires http header should be set to a value between one month from present to a year (far future) from present. Caching only applies to that exact URL, so a change in the filename of any asset will start a fresh copy. Many developers use a build process to add a version number or timestamp to their assets. Each subsequent build will start a brand new cached version, allowing you to use far future cache dates without worry. Google has a lot more detail on browser caching.
Shard resources across domains
Static content should certainly be served from a domain different than the one that serves HTML. This is optimal so that there are no extra cookies headers on all static content requests. It's also much easier to write caching rules for the entire domain. (Also any subdomains of the current domain will inherit domain cookies, so it's worth using a completely new domain).
However with enough assets (especially images) the number of requests grows enough to slow down the load of the page. Many browsers have a low constraint of how many assets they will download simultaneously per domain. (In IE6 and 7, it's only two). In this case, we can serve the assets from multiple subdomains such as:
Iframes are the most costly element to add to a given page. They block the page from firing the onload event until they are complete. Sometimes they are useful to let another agency handle tracking scripts. For example the Doubleclick floodlight tag is an iframe, and the admin can add tracking pixels into it from their dashboard. In any case where an iframe is added, it should be appended to the DOM dynamically after window onload has fired. More detail at Yahoo's Performance site.
3rd Party Integration
Backup HTML content should be in place of the flash in all cases to maximize SEO value. For XML-driven flash, the backup HTML content should be leveraging the exact same XML file, to ensure data consistency.
All replacements should be done using SWFObject but without inline script tags. SWFObject initialization should fire after the DOM Ready event. Minimum player version should be set to minimum v9, to ensure AS3 compatibility.
Cross-Browser Performance Strategy
There are two major truths when it comes to in-browser experience:
- Everyone wants the most responsive experience possible.
- Everything added to the page slows it down.
So with these two facts of life, what steps do we need to take so everyone is happy?
Create success metrics with the client
These should be customized to your client and project and done before the wireframing phase. These goals should be reasonable from a technical POV, as well as testable.Some goals that would be appropriate:
- The slowest browser supported must go from an empty cache to fully loaded and initialized within 5 seconds.
- Hover states (and other 'instant' changes) should respond within 100ms.
- Animations should appear smooth, with jumpiness occurring < 15% of the time (across all browsers).
For load-time based goals, it's important to define the benchmark system. Something like PageTest is a good option. Additionally, goals may be defined for multiple pages, for example: the two most popular landing pages (e.g. homepage and support).
If the client has more aggressive goals than are reasonable with the intended design, expectations need to be set across the board, priming the team that performance goals are going to be paramount.
Communicating the performance impact during design phaseInternally
During IA, IxD, and visual design, it is the front end engineer's role to communicate the performance impact of interactive features or certain visual techniques on the target browsers. Give the designers constraints: "If we're using Cufon, we cannot have more than 10 elements of custom font per page."Externally
Expectations need to be set that all browsers will not have the same experience. They won't perform as well as each other, nor may it make sense to have feature parity. It may be sensible to drop a few features from the IE7 experience. Features that could be considered to be dropped are: shadows, transitions, rounded corners, opacity, gradients.When communicating the impact of something:
- Clarify the impact with as much detail as possible: "it will hurt page load" vs "it will add 2 seconds to page load in IE"
- Provide a quick POC (proof of concept) if it's reasonable: "This similar-looking page without siFR loads in 2 seconds, with siFR it loads in 8 and has a delay to show during scrolling"
Develop according to best practices
Choose libraries and plugins that are performance optimized. Make wise architecture decisions based on performance goals. Also minimize DOM manipulation when possible, and write styles to avoid visual changes to the page as it loads and initializes.
Measure performance during QA
QA teams should also prioritize performance related tickets alongside visual, functional, and usability issues. Developers and QA should determine how that priority will be assigned. During QA, the success metrics should be tested regularly.Tools to test with
- Redevelop the code - profile, discover bottlenecks, refactor code, optimize to target faster execution in the browser
- Drop the feature - turn it off for slower browsers only
- Redesign approach of the UI - perhaps the design could use a tweak which would bypass the issue entirely
With this approach, we think all parties have a better chance of having aligned expectations heading in as well as a more sensible workflow in dealing with performance challenges.
What we support
Isobar supports any browser with an A-Grade in Yahoo's Graded Browser Support, with the exception of Opera. There may be exceptions to this, given regional markets and their particular metrics.
We will strive to support any other mission critical browsers mandated by the client (IE 5.5, Opera, Konqueror, Safari 3 on PC, etc), though we cannot guarantee all functionality is possible.
How we test
Comprehensive browser testing is a must on every Isobar web project. Considerable effort must be made to test across browsers and platforms to ensure a quality and consistent user experience. Setting up a testing environment can be a challenge but can be well worth it.
On Microsoft Windows
Since it's impossible to have more than a single copy of Microsoft Internet Explorer installed on a PC, testing for IE is a challenge. Fortunately, Microsoft has finally made available development versions of older Internet Explorer's available for downloading. These Virtual Hard Drives (VHD's) run stripped down versions of Microsoft Windows that expire (time out) over time. Setting them up again after a few months is typically required. Development copies of Microsoft Windows from your MSDN license (if available) may also be an option depending on what you have access to.
- Virtual PC - Virtual PC must be installed on your computer, and if you are on Windows 7, you must use "XP Mode".
- Microsoft Windows VPC Images - Several varieties are available of the virtual hard drive images. You may need to install several to have a comprehensive test suite, depending on your project.
- Firefox 3.6+ should be installed natively as well - with version 3.0 available through a portable apps version.
- If you're up to it, Install Firefox 3, 3.5, and/or 3.6 side-by-side with FF4. The Firefox Profile Manager allows you to install to different directories and maintain different profiles for each.
Safari for the PC
- Use the newest release of Safari for the PC. It is 98% consistent with Safari on OS X, but not completely, so test there if its a required platform.
- You can download old versions from their archive. Install in different folders to run multiple versions
Google Chrome and Chrome Versions
Google Chrome updates itself and as luck would have it, most all users have the most recent version more often than not. If only every browser were this easy. No worries about old browsers based on Google Chrome.
On Mac OS X
For the core Mac OS X browsers, Mozilla Firefox, Google Chrome and Apple Safari offer virtually identical browser experiences to their Windows counterparts. That said, some OS level differences can be present and web sites should be tested on both platforms. Typical differences are around font rendering and thus spacing issues sometimes arise.
Testing for Windows on a Mac
There are a number of options for testing Windows-based browsers on the Mac OS. First, Mac computers offer a "boot camp" partition which allow you to boot the Mac into a Microsoft Windows partition. This is a complex yet thorough testing environment. Once you've booted to Windows, the normal Windows options exist.
Other options include virtualization of Windows inside Mac OS X, which allows you to literally run Windows inside of the Mac OS.
The Microsoft VHD's can be opened or converted on most of these options, therefore enabling the same degree of testing prowess that Windows users have available to them. Though since you can also test on the Mac simultaneously, some might argue you have more flexibility...
- Parallels - Parallels is available and may already be installed by the Isobar IT department on your Mac.
- VMWare Fusion - VMWare Fusion offers the same level of Windows virtualization through their Fusion product.
Just like on Windows, you can install and run multiple copies of Mozilla Firefox on a Mac, though it is a bit trickier to set up multiple profiles via the Profile Manager. That said, there are some tricks you can use with Automator to make separate profiles and run them nicely.
Bugs in standalone IE versions
Note: The IE6 standalone has a buggy implementation of opacity in some cases. This will result in any opacity applied with a CSS filter, like alpha opacity or a 24-bit PNG, to fail. In the case that opacity must be tested, you will need a native IE6 installation.
It has been noticed that IE 7 using the Vista platform does have differences from IE 7 on Windows XP, therefore, you might want to make sure that someone on your team has this configuration as well. IETester is known to fix a number of these issues, as do the Xenocode browsers.
Along with catering to browsers, developers must stay conscious of the screen resolutions of their audience. As monitor screens get larger, the breadth of resolutions grows as well. Below are some guidelines to help you in working with resolutions.
- Fold estimated at 570px.
- Optimal width: 960px - Has comfortable padding on both sides, is divisible by many numbers, and also plays well with IAB ad standard widths
- Larger width: 970px - Still has some padding on both sides in most browsers. The math plays well with the Golden Ratio
- Maximum width: 996px - Without incurring any horizontal scrollbars in the major browsers. Based on the research here the maximum is 1003 px wide if you don't want a horizontal scrollbar.
Current stats on window sizes
- Authentic Boredom - Optimal width for 1024px resolution?
- Market share for browsers, operating systems and search engines
- Global Web Stats
System resolution is not, however, the same as browser size
Be aware of SEO best practices
- Print CSS best practices.
- Site/app will fit according to Browser Resolution guidelines.
- Site/app will be compatible with browser requirements described in Browser Testing and Support.
- Be aware of Accessibility best practices, such as the 508 and WCAG standards:
This lets the page get indexed correctly by search engines as well as allows users to open in new tabs and windows.
The title tag should feature target keywords for the unique page. The titles should be unique to each page. Headings (h1,h2,etc) should form an outline of the document and represent the most important keywords for that page. URLs should be human-readable with primary target keywords present in them:
Flash and Image Replacement
Always use backup HTML content for flash. All promo images should use CSS-based image replacement instead of alt tags.
Google's SEO Report Card
Google's SEO Report Card is an effort to provide Google's product teams with ideas. on how they can improve their products' pages using simple and accepted optimizations. These optimizations are intended to not only help search engines understand the content of their pages better, but also to improve their our users' experience.
when visiting their sites. Simple steps such as fixing 404s and broken links, simplifying URL choice, and providing easier-to-understand titles and snippets for their pages can benefit both users and search engines.
Code reviews are a strategic investment of time to mitigate risk on a project.
Often times, interface developers are asked to author markup from wire frames or visual compositions. However, its possible that screens that are designed cannot be translated to markup easily, or without compromising quality. Code reviews provide an opportunity for this risk to be addressed and resolved before full production of pages begins.Code reviews increase the overall level of knowledge across projects
Since code reviews involve members from within and outside a project team, techniques and best practices are easily shared throughout the entire Creative Technology team.Code reviews eliminate bugs before they are reproduced from a few templates into multiple pages
Ideally, code reviews are conducted early in the development process, before full production of pages begins. When templates are reviewed by the team and run through multiple validation tools and browsers, bugs can and will appear. This is the ideal time for bugs to be fixed.Code reviews give a set of fresh eyes an opportunity to spot issues with code
Reviewers from outside a project team can spot issues with code more easily than authors of markup, who have been working with code for a longer amount of time.Who should participate in a code review?
Ultimately, the front end engineering Lead on a project is required to ensure that proper code review procedures are followed.
Ideally, a practice lead should act as facilitator for a code review session, unless the practice lead is also the interface developer whose code is under review. In this situation, a project manager can be brought in as a facilitator.
The review team should include at least two senior members of the Interface Technology team versed in development and best practices.What is required for a code review?
Before a code review is conducted, templates to be reviewed must be fully developed, validated, and tested against the browsers and platforms required by the project.
A practice lead and/or interface developer must distribute the following 48 hours prior to the date of the code review:
- Screenshots of each template
- URLs of the templates, if applicable
- A list of browsers and platforms supported by the project
- A list of known issues/areas of concern
It is typical for code to be changed constantly until the code review is to take place. Unfortunately, this does not leave enough time for validation and testing. If this is the case, it is recommended that the code review be rescheduled to a date that ensures a proper code review.
In addition, a practice lead and/or interface developer should book a conference room and call-in number for all attendees, since it is possible that members of either the project or code review team are off-site. An hour should provide enough time for review of two or three templates; however, time will vary depending on the volume and complexity of the templates.
During the code review, a practice lead and/or interface developer should facilitate the meeting, while the practice lead or project manager takes notes and assigns action items. Reviewers should have reviewed the code and come prepared to ask questions or provide feedback.
Notes and action items (including owners) should be distributed to all attendees after the code review. If substantial changes come out of a code review, or all code is not reviewed, it may be necessary to schedule a second code review. However, this should be discussed amongst the project team to determine feasibility.
Appendix A: Validators
- W3C CSS Validation Service
- HTML Validation firefox extension
- CSS validator
- Accessibility - Bobby Validation Service
- Tests individual pages for accessibility against either the W3C or Section 508 standards.
- Accessibility - Cynthia Says Portal
- Similar to Bobby, tests individual pages for accessibility against either the W3C or Section 508 standards.
Appendix B: Tools
- Browsershots makes screenshots of your web design in different operating systems and browsers
- Browserling is an interactive cross-browser testing site. Fully interactive sessions, not static screenshots.
- Accessibility - Evaluation, Repair, and Transformation Tools for Web Content Accessibility - lists validation tools for validating, testing and fixing web content to make it more accessible.
A great code editor can spark productivity in exceptional ways. Many developers prefer rudimentary text editors, others prefer powerful integraded development environments (IDEs). What follows is a general listing of some of the more well-known tools, it would be impossible to list them all.
- Geany is a text editor using the GTK2 toolkit with basic features of an integrated development environment. It was developed to provide a small and fast IDE, which has only a few dependencies from other packages. It supports many filetypes and has some nice features. Geany. [Linux, Mac, Windows]
- Notepad ++
- Notepad++ is a free (free as in "free speech", but also as in "free beer") source code editor and Notepad replacement, which supports several programming languages, running under the MS Windows environment. Notepad ++. [Windows]
- e TextEditor
- E is a new text editor for Windows, with powerful editing features and quite a few unique abilities. It makes manipulating text fast and easy, and lets you focus on your writing by automating all the manual work. You can extend it in any language, and by supporting TextMate bundles, it allows you to tap into a huge and active community. e TextEditor. [Windows]
- Edit Plus
- EditPlus is a text editor, HTML editor and programmers editor for Windows. While it can serve as a good Notepad replacement, it also offers many powerful features for Web page authors and programmers. EditPlus. [Windows]
- HomeSite 5.5 provides a lean, code-only editor for web development. Advanced coding features enable you to instantly create and modify HTML, CFML, JSP, and XHTML tags, while enhanced productivity tools allow you to validate, reuse, navigate, and format code more easily. Configure Adobe (formerly Macromedia) HomeSite to fit your needs by extending its functionality and customizing the interface. Homesite. [Windows]
- TextMate claims to be the "Missing Editor" for Mac OS X. A general purpose editor with a sparse interface, the real power is in it's extensibility. Features column selections, recordable macros, snippets, auto-pairing of brackets and other characters, clipboard history, code folding, tab-triggers, tabbed placeholders and mirror typing. And that's just for starters. Anything that can be done via scripts through the Mac command line can be done through custom commands, allowing an extremely high degree of customization and expansion of the feature set. TextMate's "bundle" format has been adapted by many other code editors including the aforementioned e TextEditor. TextMate. [Mac]
- Espresso was created by the same fellow that created the innovative CSSEdit CSS editor. Espresso features syntax highlighting, code folding, code completion, document outliner/navigators, projects, powerful find features, and built-in file transfer publishing capabilities. Finally, it has a powerful "Sugar" feature set which allows the creation of custom commands and plugins. Espresso. [Mac]
- BBEdit is the grand-daddy of Mac code editors for web development. Features syntax highlighting, exceptionally powerful text manipulation tools, multi-file searches, a scriptable API, text clippings, and extensive Mac Automator features. BBEdit. [Mac]
- The free "little brother" of BBEdit, it is a powerful raw text editor with a massive text manipulation feature set. Searches, regular expressions, text transformations, syntax highlighting and code navigation tools for a variety of different language environments. TextWrangler. [Mac]
- Coda from Panic software is a powerful IDE with code editing, terminal, remote file management, and help documentation all built into one UI. Aiming to be a one stop shop for your web development workflow, it also features SVN integration and a new plug-in builder with powerful scripting support and TextMate bundle importing. Finally, code clips and live multi-user editing are also supported. Coda. [Mac]
- Another editor that's been around for ages, this is an immensely robust and powerful text editor, able to open files limited only by the amount of memory on your computer. The feature list is virtually too much to list, with a massive list of text manipulation features, project support, powerful search and replace, hex editing, function lists, a massive list of languages supported (600+) remote file ftp, telnet, ssh, file comparison, scriptable macros, tools and compiler support, and much, much more. UltraEdit. [Linux, Mac, Windows]
- Sublime Text
- A relatively new editor, Sublime Text is a new approach in editors. "Open Anything" searches through file names and file contents, with remarkable efficiency. Incredibly powerful selection controls allow editing text in multiple locations at once and the "Minimap" gives you a bird's eye view of the open file so you can find your place easily. Actively being developed, new features are being added and the community around the editor is rapidly expanding. Macros, auto-complete, snippets, build tools, the list of features goes on and on. Supports Linux and Mac starting with version 2. Sublime Text. [Linux, Mac, Windows]
- If you have to ask, it's probably not for you. Vim [Linux, Mac, Windows]
Google Chrome Extensions
- Developer Tools
- code cola
- A pop-up panel with CSS editing tools for examining and modifying the styles on a given page. code cola.
- Firebug Lite for Google Chrome
- You really don't need to install an extension to use Firebug Lite with Chrome, though the extension is nice because it enables one-click application of the Firebug Lite script to any page you are working with. Not the full Firebug feature set, but close. Firebug Lite.
- HTML5 Outliner
- The HTML5 Outliner adds a pop-up with a generated HTML5 outline of the current page's header hierarchy. Helps for checking your pages' organization against the new HTML5 header outlining algorithms. HTML5 Outliner.
- Nice set of tools for showing data about and interacting with the current web page. Very similar to the original web developer toolbar for Firefox. Pendule.
- Web Developer for Chrome
- Chris Pederick, the original developer of the original Web Developer toolbar for Firefox has ported the majority of it over to Chrome. There you have it. Web Developer.
- FireFTP is a free, secure, cross-platform FTP client for Mozilla Firefox which provides easy and intuitive access to FTP servers. FireFTP.
- FireQuery is a collection of Firebug enhancements for jQuery integrated into Firebug. Firequery.
- Firecookie adds cookie viewing, editing, and deletion to Firebug. Firecookie.
- CSS Usage
- CSS Coverage is an extension for Firebug which allows you to scan multiple pages of your site to see which CSS rules are actually used in your site. CSS Usage.
- Web Developer Toolbar
- Adds a menu and a toolbar with various web developer tools. Web Developer Toolbar.
- Live HTTP headers
- When running, captures all HTTP traffic from the browser, which enables you to see what files are being requested as well as information about the requests and server responses. Live HTTP Headers.
- Quick Locale Switcher
- A tremendous help when doing internationalization, Quick Locale Switcher allows you to change the locale sent along in the browser's user-agent HTTP header, telling servers to display content for you in other locales. Quick Locale Switcher.
- Screengrab sits in the Firefox status bar, allowing you to capture and copy or save screen shots of everything from selections of a web page to the entire page, even parts displayed "below the fold." Screengrab.
- Total Validator
- Enables one-click access to sending your page through a markup validator. No better way to quickly check for missing or mismatched tags! Also available as a standalone application. Total Validator.
Dragonfly is Opera's developer tool similar to Firebug.
CompanionJS, DebugBar, IE8 Dev tools.
Charles watches all requests and can tell you a lot of information about them. Also supremely useful is Map Local which lets you use a local file in place of a given URL (good for replacing a minified js with a full one).
From the site: "Fiddler is a Web Debugging Proxy which logs all HTTP(S) traffic between your computer and the Internet. Fiddler allows you to inspect traffic, set breakpoints, and "fiddle" with incoming or outgoing data. Fiddler includes a powerful event-based scripting subsystem, and can be extended using any .NET language."
Speedlimit is a Leopard (works in snow leopard) preference pane for limiting your network bandwidth to one of a couple different speeds—768k DSL, Edge, 3G, and Dialup. Good for testing your lowest supported speeds or when you want to know how your app will function in real world speeds.
Tutorials & Tools:
- Famfamfam silk icons
- Paul's bookmarks for more icons
- Fugue Icons - 3,100 icons in PNG format.
Appendix C: Resources
- ECMA 262 5th Edition December 2009
- Opera's The Web Standards Curriculum - basic articles about building with web standards.
- 10 Principles of the CSS Masters - all of this is smart advice.
- Google - when in doubt, google it.
- Too lazy? - let me google that for you then...
- Yahoo's Exceptional Performance team has maintained one of the best summaries of performance advice.
- Google now has a Speed site with excellent detail. (Click All best practices).
- Mozilla's coding standards.