When producing a theme, we try not to limit the website owner’s options within the WordPress Dashboard. The owner may wish to enable an option down the track and be disappointed if they can’t.

The downside for the designer and developer is they may put in work for elements that are never used. The upside is happy clients and return business.

Like most things web, the site’s purpose will dictate that some things just aren’t feasible. Consider this as a series of guidelines that you can adapt for your purposes.

This is a giant list of everything we could think of. It makes the task of designing for WordPress look a lot more daunting than it actually is. The theme test unit contains posts with every type of content listed below.

For the purposes of this post, we focused on our internal WordPress framework.

The website basics

The frame of the website includes the header, footer and any sidebars for website owners to add widgets. The frame may change on various pages throughout the site.

Some typical items that need to be designed for the site are:

• Menus, including hover states and any drop downs or mega menus, if applicable
• Headings and sub headings: HTML can have up to six levels of headings and sub headings. To keep code semantic in our framework, it allows
  • 5 levels of headings within a page (with the page title being the top level)
  • 4 levels of headings within a post (on archive pages, the post title is a second level heading)
• Form input fields, including
  • label placement
  • error message placement
  • focus states (when the user’s cursor is in the input)
  • submit buttons
    • hover states
    • focus states
    • active states (when the button is clicked)
  • an example of a typical layout can be found on our CSS framework’s form demo page (hit the submit button to view error messages).
• link colours
  • default
  • visited (if different from default)
  • hover state
  • focus state (for users navigating the page via keyboard)
    As mentioned in a recent post, we tend to reverse the foreground and background colours for the focus state.
  • active state (when the link is being clicked, frequently the same as hover state)
• Footer, typically containing
  • links to website policies
  • declaration of copyright,
  • links to main pages or a site map.

Widgets

Widgets are the various elements that appear in the sidebar, such as recent posts.

Each widget has a title and the contents described below

• List Widgets
  Most widgets are a list of links. Commonly these are styled in the same fashion but, if the design demands it, they can be made to look quite different.
  • Archives of months/categories
    • Option: Display as drop down
    • Option: Show or hide post count
    • Option for categories: show hierarchy.
  • Links/blog roll
    • Option: show link image (if no image, title is displayed)
    • Option: show link title
    • Option: show link description
    • Option: show link rating
  • Pages/custom menu, shown as hierarchy. Options do not affect design.
  • Recent post titles
    • Option: number of posts to display
  • Meta, links to site’s admin, RSS feed and similar
  • RSS Feed, can also be used to show recent posts. Shows title and an extract from the post.
    • Option: number to display
    • Option: display post author
    • Option: display post date
  • Recent Comments.
    Actually two links per list item; one to the comment and one to the commenter’s webpage.
    • Option: Number of comments to display
• Other widgets
  • Search form, includes input and a submit button
  • Text widget, can include any HTML
  • Calendar: one month with links to dates on which there were posts
  • Tag cloud

Plugins can be used to add other widgets to your page, for example a mailing list subscription form.

Archives and Search Results

WordPress includes the following archives of posts.

• Main archive – archive of posts from all categories by all authors
• Date based archives (by year, month and day)
• Category archives
• Tag archives
• Author archives
• Search results by search term

It is possible for the designer to include a description or author bio on the page. If you add this, you need to allow for the element to be removed if no description/bio is defined.

The archives are a list of posts, while the designer may remove them, they typically include

• title,
• category,
• tags (if added by website owner),
• author,
• number of comments,
• date of post,
• a short excerpt, the beginning or full text of the post
• a ‘read more’ link

Additionally, links to older and newer posts are displayed.

Search results display both pages and posts containing the search term in their title, excerpt or content.

Single Posts

Single posts typically display

• a feature image or thumbnail (if enabled by the designer)
• title
• category
• tags (if defined by website owner)
• author
• comments (if enabled)
• comment form (if open)
• date of post
• full text of the post
• links to the next & previous posts
• links to the next and previous page of comments (if applicable)

it is also possible to display a variety of information about the author if it has been defined.

Some plugins add extra content to the contents of this page. Designing for the gazillions of plugins available is impossible so discussing plugins with your client upfront will be helpful.

WordPress supports post formats which can be used to alter the display for the post depending on it’s content. The theme designer can choose to enable none, some or all of these. Possible post formats are:

• standard
• aside
• gallery
• link
• image
• quote
• status
• video
• audio
• chat

Single pages

WordPress allows multiple page templates to be included within a theme, common templates include:

• A standard page layout (required)
• A home page
• Special purpose landing pages

Pages typically display

• a feature image or thumbnail (if enabled by the designer)
• title
• comments (if enabled)
• comments form (if open)
• full text of the page
• links to the next & previous pages of comments (if applicable)

Attachment pages

An attachment page is linked to from an image or other media file.

• The full sized image, or a link to the media file
• A caption
• the next/previous attachment – if applicable.
• title
• date uploaded
• comments (if enabled)
• links to next / previous page of comments (if applicable)

Post and page content

The WordPress visual editor allows website owners to add numerous items to their post content, including

• bulleted and numbers lists,
• block quotes
• left, right, centre or justified alignment of text,
• links
• headings & subheadings – up to five levels in our framework
• images (left, right or centre aligned)
• images with captions  (left, right or centre aligned)
• video – either uploaded or embedding a youtube video.
• audio – either uploaded or embedding from elsewhere
• links to next/previous pages (if the page/post is split across pages)

If the website owner knows HTML, they can add other items using the HTML editor.

The layout test post on the theme test data page contains everything the website owner can add.

If the theme author enables it, each post and page may include a featured image/thumbnail. This may be displayed wherever post content appears.

Pull out quotes and other decretive elements can be added at the theme designers desecration.

Comments

Comments are generally displayed in the same manner on both pages and posts. WordPress allows for comments to be

• Paginated
• Nested
  By default WordPress allows comments to be nested up to ten levels deep. As the theme designer you can disable this or limit it to a lower number.
  We tend to limit it three or four levels deep.
• display avatars or not.
  As these are enabled and disabled in the dashboard, it is important for the comment design to allow for both scenarios.

The design of individual comments are dictated by the designer. Comments typically include

• name of the commenter
• the contents of the comment
• date and time of the comment
• avatar (if enabled)
• reply to this comment link (if enabled)
• When commenters submit a comment, if the comment needs to be moderated by the admin the text “You comment is awaiting moderation” is displayed.

The comment form

Users that aren’t logged in will see a comment form requesting:

• their name (required),
• their email address (required),
• their website (optional, the theme designer can remove this)
• the comment (required)
• a submit button

If the user fails to fill in the form correctly, our framework displays error messages next to each field.

If the website owner has required users register before leaving a comment, in place of the comment form logged out users will see the text “You must be logged in to post a comment.” In our framework, we display a login form below this text.

Users that are logged in will see the text “Logged in as username. Log out?” and a form requesting the comment followed by a submit button.

Not found pages

If a search term returns no results or a visitor enters a URL incorrectly, a no results/file not found page will be displayed.

Anything can be displayed on this page, by default our framework includes:

• a one line explanation of what’s happened,
• a search form,
• a site map.

Additional items

The theme designer may wish to add additional items & content to their WordPress site. For the most part your imagination is the limit.

Updates

• 28 Sep, 2011 – added a:active as suggested by Edward Caissie below
• 28 Sep, 2011 – change heading level details for posts, brain freeze.

Along with the standard features you would expect in a WordPress framework, it includes

• templates for the Theme My Login plugin,
• custom default code for Formidable / Formidable Pro plugins,
• custom html output for the Grunion Contact Form plugin, and,
• a child theme starter.

Never use the framework proper to set up a theme, set up a child theme instead.

• Copy the files from the starter directory into the base folder of your child theme
• Create the sub-directory assets in your child theme
• Copy the framework’s assets/child/ directory into the assets directory of your child theme

See the WordPress codex page on child themes for more information.

More documentation to come!

The Soupgiant base WordPress themes are now available on GitHub. There’s no documentation at this stage, I’ll write up a blog post with details in the coming weeks.

There are two parts to the theme

• Soupgiant Parent Theme
  We use this as the parent theme across multiple projects. Any bug fixes or new features applied to this theme will be available to all child themes.
• Soupgiant Child Theme
  Starting point for each project. Once duplicated for the project, CSS styling and per project PHP customisations are applied/overridden in the child theme. Most projects require a custom header.php & footer.php.

As I say, documentation to come.

Update: We’re currently updating our themes to use WordPress 3.1 features, make wider use of the API and to make child themes easier. Subscribe to our RSS feed and you’ll be notified when these are published.

As with most WordPress sites we use plugins to enhance WordPress, including Donncha O Caoimh‘s excellent WordPress MU Domain Mapping plugin. As the name implies, the domain mapping plugin allows us to use top level domains for each site rather than being stuck with sub-domains. In the case of this blog, without the plugin it would reside at bigredtin.pressgiant.net.

Taking care with plugins

Many plugins are tested for the single site version of WordPress only. I don’t have a problem with this as most plugins are released under the GPL and free in terms of both speech and beer. If I’m not paying for software, it’s up to me to test it in the fringe environment of WordPress MS.

Now that WordPress is WordPress MS is WordPress, more developers may test in both environments but they certainly can’t be expected to test with all manner of combinations of plugins.

The standout problem

One of the standout problems when using plugins with WordPress MS is when they define a constant for the plugin’s url as the script starts executing, the PHP code may look similar to:

<?php

  define('PLUGIN_DIR', get_bloginfo('url') . "/wp-content/plugins/peters-plugin");

  function plugin_js_css(){
    wp_enqueue_script('plugin-js', PLUGIN_DIR . '/script.js');
    wp_enqueue_style('plugin-css', PLUGIN_DIR . '/style.css');
  }

  add_action('init', 'plugin_js_css');

?>

The above stands equally for themes mapping the stylesheet directory at the start of execution:

<?php

  define('THEME_DIR', get_bloginfo('stylesheet_directory') );

  function theme_js_css(){
    wp_enqueue_script('theme-js', THEME_DIR . '/script.js');
    wp_enqueue_style('theme-css', THEME_DIR . '/style.css');
  }

  add_action('init', 'theme_js_css');

?>

The get_bloginfo and bloginfo functions return information about your blog and your theme settings including the site’s home page, the theme’s directory (as in the second code sample above) or the stylesheet url. bloginfo outputs the requested information to your HTML, get_bloginfo returns it for use in your PHP.

Outside of code samples, bloginfo and get_bloginfo are interchangeable throughout this article.

The problems occur when a subsequently loaded plugin needs to change something retrieved from bloginfo. In this site’s case, Domain Mapping changes all URLs obtained through bloginfo, but it could be a plugin that simply changes the stylesheet url to a subdomain to speed up page load.

In a recent case, a plugin – let’s call it Disqus – was defining a constant in this manner. As result an XSS error was occurring when attempting to use Facebook Connect. Replacing the constant with a bloginfo call fixed the problem.

The improved code for the first sample above is:

<?php

  function plugin_js_css(){
    wp_enqueue_script('plugin-js', get_bloginfo('url') . '/wp-content/plugins/peters-plugin/script.js');
    wp_enqueue_style('plugin-css', Pget_bloginfo('url') . '/wp-content/plugins/peters-plugin/style.css');
  }

  add_action('init', 'plugin_js_css');

?>

bloginfo doesn’t hit the database everytime

I presume the developers set their own constants because they’d like to avoid hitting the database repeatedly to receive the same information.

Having run some tests on my local install of WordPress, I can assure you this is not the case. Running bloginfo('stylesheet_directory') triggers a db call on the first occurrence, the information is then cached for subsequent calls.

I realise I sound incredibly fussy and that I’m suggesting we protect against edge cases on our edge cases. You’re right, and it’s not the first time, but as developers it’s the edge cases that we’re employed to avoid.

In this section we’ll deal with a more complicated example and use Google’s AJAX libraries API to lower your bandwidth costs. We’ll also take what we’ve learnt about including JavaScript and apply it to our CSS.

A more complicated example

The sample code yesterday included a simple example of using the same JavaScript file throughout your site. Let’s spice things up slightly by introducing the following circumstance. Consider that you have three JavaScript files:

• base.js is the base JavaScript file to be used throughout the site. It uses the jQuery library and must load in the HTML <head>;
• posts.js loads on pages and posts and only calls functions from the base JavaScript file but doesn’t use the jQuery library directly. It can load in the HTML footer.
• archives.js loads on all other pages throughout your site (except admin). It calls functions from your base JavaScript file and makes direct use of the jQuery library. It can load in the HTML footer.

In this situation, you could change your base.js to use another library – say, Prototype – and it would have no effect on the posts.js. So, posts.js can be said not to depend on jQuery directly.

Changing libraries would require edits to the third file, in which case archives.js does depend on jQuery directly.

Registering the Files

The code to register those JavaScript files and conditions with WordPress is:

wp_register_script (
  'mytheme-base', /* handle */
  get_bloginfo('template_url') . '/base.js', /* source */
  array('jquery'), /* requires jQuery */
  1.0 /* version 1.0 */
);

wp_register_script (
  'mytheme-posts', /* handle */
  get_bloginfo('template_url') . '/posts.js', /* source */
  array('mytheme-base'), /* requires base.js */
  1.0, /* version 1.0 */
  true /* load in footer */
);

wp_register_script (
  'mytheme-archives', /* handle */
  get_bloginfo('template_url') . '/archives.js', /* source */
  array('jquery', 'mytheme-base'), /* requires jQuery & base.js */
  1.0, /* version 1.0 */
  true /* load in footer */
);

This code says to WordPress:

• If loading posts.js, also load base.js;
• If loading archives.js, also load jQuery and base.js;
• If loading base.js, also load jQuery;

Each of these are separate checks (if) rather than a series of options (if, else if).

Enqueueing the files

All the hard work has been done registering the files, WordPress knows what each file requires to work and where in the HTML (<head> or footer) the <script> tags should be inserted.

Now it’s a simple process of checking if the visitor is loading a post or page and requesting the appropriate file.

We need to delay the check slightly, otherwise WordPress won’t know if the user is on a page, post or elsewhere. The first step is to enclose the check in a function.

function que_scripts(){
  if (!is_admin()) { //visitors only
    if (is_singular()) { // pages & posts
      wp_enqueue_script('mytheme-posts');
    }
    else {
      wp_enqueue_script('mytheme-archives');
    }
  }
}

Then tell WordPress when to execute the function. For this we use the action wp_print_scripts. This runs the code above before WordPress attempts to output the <script> tags to your HTML.

add_action('wp_print_scripts', 'que_scripts')

There is no need to enqueue jQuery or base.js directly. WordPress knows to add those to the HTML based on the dependancies listed when registering the files.

Using the Google AJAX Libraries API

Loading all these libraries from your own server may seem like a waste of your bandwidth considering you could be loading the libraries directly from Google’s servers.

With a bit of luck, your visitor will have Google’s version of the libraries in their browser’s cache already and your site will load a little quicker.

It’s a bit messy to do this yourself, especially since jQuery needs to be kept in noConflict mode. Fortunately Jason Penny has developed a plugin, called “Use Google Libraries”, to do the hard work for you.

“Use Google Libraries” is the first plugin I add when setting up sites for me and my clients.

Making our super-broken example super-fabulous

If, when developing their theme and plugin, George and Richard from our example in Part 1, had used the wp_register_script and wp_enqueue_script WordPress functions to load their JavaScript, WordPress would know that only one version of jQuery needs to be loaded for both the theme and the plugin to work.

As WordPress releases come in fits and bursts, sometimes the version of the JS libraries included with WordPress fall behind the current version of the library available otherwise.

This is a small price to pay for the knowledge that our sites will remain super-fabulous rather than super-broken, at least when it comes to the JavaScript.

A bonus for CSS

By now the reasons for using wp_register_script and wp_enqueue_script should be clear. If you want to go that one step further, you can use the equivalent functions for your CSS.

As CSS should always be loaded in the HTML <head>, there is no option to load the CSS files in the footer of the HTML. Otherwise the CSS functions take the same arguments as their JavaScript equivalents. The CSS functions are:

• wp_register_style
• wp_enqueue_style

The four parameters they take are:

$handle

(required for both functions) Name of the style sheet

$source

(required for wp_register_style) – URL of the script. Also required by wp_enqueue_style if the style is unregistered.

$dependancies

(optional) – an array of handles the style sheet depends on

$version

(optional) – version number

WordPress doesn’t include any style sheets bases, such as YUI CSS, in the default distribution, so the main purpose of the CSS functions is to allow you to keep track of your version numbers and to call in style sheets only as they’re needed.

Conditional comments

Unfortunately the WordPress functions for JavaScript do not allow for conditional comments, so scripts targeting older versions of IE (okay, I’m referring to PNG fixers for IE6) need to be coded directly into your theme’s header.php or footer.php.

On the other hand, the CSS functions do allow for conditional comments, in a round-about fashion. Let’s register a CSS file we’ll be targeting at IE6.

wp_register_style (
  'mytheme-ie6', /* handle */
  get_bloginfo('template_url') . '/ie6.css', /* source */
  array('mytheme-css'), /* requires mytheme-css (not shown) */
  1.0 /* version 1.0 */
);

Behind the scenes WordPress is adding the stylesheet to the object $wp_styles. To add the conditional comments you need to access the object more directly. To target the above to IE6, the command is:

$wp_styles->registered['mytheme-ie6']->extra['conditional'] = 'IE 6';

If, as in the complicated example above, you need to check where a user is before enqueueing your stylesheet, again you need to enclose the enqueueing command in a function and run it on an action, in this case the action wp_print_styles.

For example, to output the IE6 stylesheet above on pages and posts only, the full code would be:

function que_styles(){
  if (!is_admin()) { //visitors only
    if (is_singluar() {
      wp_enqueue_style('mytheme-ie6');
    }
  }
}

add_action('wp_print_styles', 'que_styles')

Conclusion

The methods described in this tutorial may appear to complicate matters for little pay off, especially if you’re developing a theme or plugin for your own site.

Replacing your <script> tags with the code above, it is true, will have almost no effect on the HTML or JavaScript output by WordPress. What’s worse, if you use the $ alias for jQuery in your JavaScript, you’ll need to edit both the theme’s php and JavaScript files.

These functions, wp_register_script and wp_enqueue_script, aren’t about now, however, they’re about “then”.

• Then… I activated this plugin and my JavaScript stopped working.
• Then… I changed the theme and my favourite plugin stopped working
• Then… I looked at the source code, and two copies of jQuery were being sent to every visitor

The WordPress developers have seen the problems JavaScript conflicts can cause, and developed these functions to make your theme or plugin more robust. It’s the added robustness, for such little effort, that make these functions worth using.

It’s also possible your theme or plugin will work perfectly well without these functions on its own. Problems will arise when your theme or plugin both use the same JavaScript library or if Prototype and jQuery are both used on the same site.

These functions are used to add JavaScript to the html, either in the head or the footer.

Introducing wp_register_script and wp_enqueue_script

For the rest of this article I’ll refer to development of your theme. The tutorial applies equally to development of your plugin, but there’s only so many times the phrase “your theme or plugin” can appear in a page.

In this first part, we’ll look at:

• Defining the problem;
• The libraries included with WordPress;
• Defining the functions we’ll be using and;
• The functions for registering and enqueueing your scripts.

The problem defined

Imagine you’ve used a theme on your WordPress site for months or years without a problem. It uses jQuery to add AJAX functionality to your site and it’s called George’s Super Theme.

You decide to add a plugin to your WordPress site and add more AJAXy goodness to your site. This plugin also uses jQuery for the JavaScript and it’s called Richard’s Fabulous Plugin.

You activate the plugin and instead of the super-fabulous result you were looking for you end up with a super-broken site. None of the JavaScript is working and your visitors are stuck on the home page, with nowhere to go.

Looking at the HTML of your WordPress site, you see the following lines:

<script type='text/javascript'
  src='/wp-content/themes/george/jquery-1.4.2.js'></script>
<script type='text/javascript'
  src='/wp-content/plugins/richard/jquery-1.3.2.js'></script>

Both the theme and the plugin are attempting to load the jQuery library. each uses a different version, which further complicates matters.

In this particular case, the theme is expecting jQuery version 1.4.2 and the plugin is replacing it with version 1.3.2. Anytime the theme attempts to use a function added to jQuery in version 1.4 or later, an error occurs preventing the JavaScript from running.

Even if the site was running as expected, it’s a waste of your users’ bandwidth.

Fortunately the WordPress developers envisioned this problem and sort to solve it by including the most common JavaScript libraries with WordPress and developing the functions that are the subject of this tutorial.

Libraries included with WordPress

WordPress comes with a number of JavaScript libraries pre-registered, so you need not include these libraries in your theme. All you need to do is include them as dependencies of your custom JavaScript and WordPress will do the work.

Some of the libraries included with WordPress are:

• jQuery – with the handle ‘jquery’, runs in no conflict mode
  • WP 2.9.2 includes version 1.3.2 of jQuery
  • WP 3.0 will include version 1.4.2 of jQuery
• Scriptaculous – with the handle ‘scriptaculous’
• SWFObject – with the handle ‘swfobject’
• Prototype – with the handle ‘prototype’
• A full list of pre-registered script can be found in the codex.

The functions defined

The WordPress codex defines wp_enqueue_script as “a safe way of adding JavaScripts (sic) to a WordPress generated page”.

wp_register_script is similar and can be thought of as a safe way of introducing JavaScript to WordPress, without adding it to the generated page.

The difference between these functions are fully explained in the sections Registering your scripts and Enqueueing your scripts below.

Both functions take the same five parameters:

$handle

(required for both functions) Name of the script

$source

(required for wp_register_script) – URL of the script. Also required by wp_enqueue_script if the script is unregistered.

$dependancies

(optional) – an array of handles the script depends on

$version

(optional) – version number

$in_footer

(true/false, optional) – if true, place script above the HTML </body> tag, otherwise place the script in the HTML <head>

These functions only work as expected if both wp_head() and wp_footer() are included in header.php and footer.php respectively.

Registering your scripts – wp_register_script

wp_register_script gives WordPress knowledge of your script without adding it to your HTML. Used by itself, it has no effect on your HTML whatsoever.

You can use it if you wish to register your various JavaScript files in one block of php within your theme’s functions.php file, allowing you to update version numbers, dependancies and handles in one place.

If the use of the JavaScript depends on particular conditions being met, such as the user being on a particular post, you can then enqueue your scripts elsewhere without losing track of where you should update version numbers.

If your theme’s JavaScript can be loaded in the footer and relies on the jQuery library, you would register your script with the following code:

wp_register_script (
  'mytheme-custom', /* handle WP will know JS by */
  get_bloginfo('template_url') . '/custom.js', /* source */
  array('jquery'), /* requires jQuery */
  1.0, /* version 1.0 */
  true /* can load in footer */
);

At this stage, this has no effect on your HTML, you need to use wp_enqueue_script to do that.

Enqueueing your scripts – wp_enqueue_script

wp_enqueue_script outputs your JavaScript to the HTML of the page, either as a result of the wp_head() or the wp_footer() call in your PHP. If you have pre-registered your script (as above), the full code is:

if (!is_admin()) {
  wp_enqueue_script('mytheme-custom');
}

Combined with the code above, this line of code will load both jQuery and your theme’s JavaScript. The only reference to jQuery is needed in the dependancies. There is no need to register or enqueue it yourself.

The check that your visitor is outside of the admin area, !is_admin() – is important, as these functions can be used to add JavaScript to both the visitor and admin areas.

More often than not, you’ll want to leave the admin area alone.

A shortcut

It’s possible to enqueue your script without registering it first. This comes in handy if your theme uses a single JavaScript that is loaded on every page, outside the admin area, of your blog.

The code to do this is:

if (!is_admin()) {
  wp_enqueue_script (
    'mytheme-custom', /* handle WP will know JS by */
    get_bloginfo('template_url') . '/custom.js', /* source */
    array('jquery'), /* requires jQuery */
    1.0, /* version 1.0 */
    true /* can load in footer */
  );
}

Again, our custom code requires the jQuery Library.

Aside: noConflict for jQuery and Prototype

As mentioned earlier, jQuery runs in noConflict mode. The reason being that in jQuery’s standard mode it includes the $ variable as an alias. WordPress also includes Prototype, which includes the JavaScript variable $.

Imagine if your theme uses jQuery and you add a WordPress plugin that makes use of Prototype, whichever is loaded second would override the $ variable of the former. Either your theme’s or the WordPress plugin’s JavaScript would crash as a result.

If your theme uses jQuery and you’d still like to make use of the $ alias, it’s possible to do so without breaking the plugin’s JavaScript. In your JavaScript file, just wrap your code between these two lines:

(function($) {
  /* your code */
})(jQuery);

– source

Under no circumstances should you reintroduce the $ alias for jQuery, it could lead to problems down the track.

A shorter aside: throughout this post I’m using the example of JavaScript requiring jQuery. The reasons are two-fold: a) it’s the library we use at Soupgiant and Big Red Tin and, b) as Twitter’s Dustin Diaz said recently of jQuery: ‘they won‘.

Now Available: Part Two

In part 2 of this tutorial we’ll further illustrate dependancies, lower your bandwidth costs and show you how to use similar functions to load your stylesheets.