I know there’s a slew and a half of tutorials on this out there, but I’m adding my own to the mix.  I’ve been working on a generic template for plugin development and have cobbled together what I feel is a solid one.

First thing first, however, building a plugin is about being a good citizen

1. You’ve got a naming convention to deal with.  jquery[your plugin name].js
2. Be considerate of the $.XXX namespace.  Only claim 1, and try to make it both developer friendly and unique.  In our case it will be $.plugin
3. Always return this.
4. Always end with a “;”
5. Wrap the entire thing in an anonymous function call, this will protect the plugin from instances where jquery has been renamed. 

So, with all that said and done, the skeleton of a plugin looks like this:

   1: (function($) {

   2:  

   3:   $.fn.myPlugin = function(settings) {

   4:     var config = {'foo': 'bar'};

   5:     if (settings) $.extend(config, settings);

   6:     this.each(function() {

   7:       // element-specific code here

   8:     });

   9:     return this;

  10:   };

  11:   

  12:    var newMethods = {

  13:        a   : function() {

  14:                 var config = {'foo': 'bar'};

  15:                 if (settings) $.extend(config, settings);

  16:  

  17:                this.each(function() {

  18:                   // element-specific code here

  19:                 });

  20:  

  21:                 return this;

  22:                   },

  23:        b   : function() { return this },

  24:        c     : function() { return this }

  25:       };

  26:       

  27:  jQuery.each(newMethods, function(i) {

  28:    jQuery.fn.myPlugin[i] = this;

  29:  });

  30:  

  31:  

  32: })(jQuery);

Note, what this code is doing.

First, we define the core behavior of the plugin, then extend the plugin once.  This way we keep our declarations concise, clear and well encapsulated.

We have an established closure structure for shared private functions.

We keep everything encapsulated to protect the jquery namespace as much as possible, and iterate over the child functions to extend the plugin.

PS– most of this is adapted from the jquery extension guide here: http://docs.jquery.com/Plugins/Authoring

On top of yesterdays release of the silksprite plugin.  There are already 3 plugins included in the default blueprint download that are quite useful.  This will be a closer look at using these plugins and will hopefully inspire you to create & deploy plugins in your future projects.

Buttons 

buttons styles <button /> & <a/> elements of type button.  Into a more polished, cross browser web 2.0 look.  It also handles hover states.

Of note, the button plugin provides 2 “modifier” classes of type positive & negative which provide the green & red appearance.   Although the icons shown in the sample are included with the button plugin, they aren’t handled by CSS.

Fancy-Type

Fancy Type provides significant, baseline compatible classes to improve the polish of your blueprint layouts. The provided classes include

• p + p indentation instead of line shifts for sibling paragraphs
• .alt a fancy, italic script to call attention to ampersands, prepositions etc.
• .dquo Fancy quotation marks for the start of titles & lines
• .incr Reduced font & line size for sidebars & similar that complies with baseline
• .caps Special, small-caps class.

CSS-Classes

A collection of utility classes to help with formatting.

• .hide
• .left (float left)
• .right (float right)
• .reset-margin
• .reset-padding
• .reset (reset both padding & margin)
• .align-left
• .align-right
• .align-center
• .align-justify

All of these plugins can be included in your project simply by adding the line

@import ‘plugins/(plugin file)/(plugin css file)’;

to screen.css

Today, I’m proud to announce the release of SilkSprite a CSS Sprite plugin for Blueprint based on the widely used Silk Icons.

Benefits

• 1000 icons compressed into 1 file
• Entire Plugin is only 3 files
• Easy to use

Usage

• Place this directory inside blueprint/plugins
• Add this line to “blueprint/screen.css”,
  • @import ‘plugins/silksprite/sprite.css’;
• Use the sprites by attaching classes ss_sprite & ss_(name of sprite) to an a, span or div element. You can use test.htm as a key to the names of sprites.
• example:

  <span class="ss_sprite
  ss_add"> </span><br />

Credit

• Silk Sprite is Based on the Silk Icon Set by Mark James [famfamfam.com]
• Compiled & Adapted for Blueprint by Don Albrecht [ajaxbestiary.com]

Check it out online here:

http://www.ajaxbestiary.com/Labs/SilkSprite/

When I first started using CSS frameworks & standardized resets to streamline my web development, I adopted a process that I’m sure is familiar to many of you.  I would first link to the frameworks CSS files and then link to a project specific stylesheet.  The project specific stylesheet would build on the frameworks foundation to provide color & background data, special classes and all the other bits and bobs unique to the design.

For me, this system worked quite well.  I gained the benefit of the frameworks without excessive overhead and while I was no longer coding my CSS from the ground up, the process was surprisingly smooth.  When I first heard about plugins, I really didn’t see the point of adopting them.  They seemed an arbitrary way to include functionality that really belonged in the project stylesheet.  A recent project, however, completely changed my mind.  I was working with a client on a site that required support for several different templates (holiday sale, investor relations, technical support, etc).  While many of these sections employed radically different looks, they needed to be consistent in terms of typography, form elements, tooltips, etc.  They also needed support for seasonal theming as much of their marketing was holiday & special event oriented.

Suddenly, the plugins systems made sense.  I built a single plugin for all site wide styling and a second plugin to allow for seasonal color schemes (simply upload a different folder to the same location and you can change the colorscheme site wide).  Once I realized the power of plugins for complex projects, the realm of uses has exploded for me.

Where I use CSS plugins:

• Site specific typography & branding
• Common form elements (error, required field, etc)
• turn on and off debugging styles (great for troubleshooting)
• My personal CSS widget toolkit ( pullquotes, notes, etc.)
• Custom Grid (Instead of replacing grid.css in blueprint, I may deploy a new grid as a plugin during development)
• CSS Sprites

Plugins are currently supported by Tripoli & Blueprint.

I’m curious who here has started working with plugins or some other formal, modular system for CSS.

Coda Slider is a slick, sliding panel widget plugin for jQuery.  It smoothly scrolls between a series of dynamically created tabs and provides a slick, circular navigation.

• Some Features:
• Clean and Valid XHTML Strict
• Circular Navigation
• Dynamically Created Tab Set
• Multiple Sliders Can Exist On One Page
• Cross Browser
• Navigation is queued to prevent sudden jumps.

Some Drawbacks,

• Text not selectable in Firefox 2 PC
• Not Possible to Hyperlink to Selected Tabs / Anchor Support

Get It Online Here:

http://www.ndoherty.com/demos/coda-slider/

Read the Blog Post:

http://www.ndoherty.com/blog/2007/09/15/introducing-coda-slider/

Here’s a handy plugin to attach elements to view port so they don’t scroll with the page.  Scripts for both pinning and unpinning are available. 

To pin:

$(‘fxtarget’).pin();

To unpin:

$(‘fxtarget).unpin();

You can get it online from clientside here:

http://clientside.cnet.com/code-snippets/visual-effects/new-elementpin/