There is one major drawback though. In IE submit and reset events do not bubble, thus you cannot use delegation here. Same is true for submit events in Safari 2.

In the upcoming Plazes delegation for submit/reset events turned out to be a requirement, so I wrote an event delegation plugin based on Dan Webb’s stuff, in particular on what Yehuda Katz proposed in one of the comments, and added workarounds for IE and Safari, so that you can now use delegation for these events just as you would expect. There were also some issues with using confirm().

I needed to do that quickly, thus the code could use some optimization (later).

Get it here:
http://stilbuero.de/jquery/delegate/

I just noticed that Jörn Zaefferer wrote something similar for the focus and blur events and I’m going to merge the two.

Until today I have fixed a bunch of bugs that popped up and I hope Tabs 3 is stable now. I’ve added a couple of frequently requested features but please be aware that the new Tabs require jQuery 1.2.1 and also that I have left away history support for now. The history plugin itself needs a major overhaul and when that is done I will build it into Tabs again. I have closed down comments on all of the Tabs 2 posts to indicate that this version will not be maintained any longer.

If you’d like to report a bug, I’d like to ask to you to file a ticket. This way it’s much easier to keep track of bugs and if you post a bug in the comments I will create a ticket anyway.

To be consistent with other UI modules, i.e. to conform to some conventions we set up, the Tabs API has changed quite a bit. The documentation, which has been moved from the source file to the jQuery documentation Wiki is your friend (and because it’s a Wiki everybody can help to improve it – remember I’m not a native english speaker and documenting code is not always easy for me). I’ll also write a follow-up post about the most important changes and additions.

A demo is here.

Thank you for using Tabs!

Important to know is that this required an additional span element nested in the anchor element of a tab.

Increased flexibility

For a much increased flexibility regarding the HTML structure required for a tab interface you can now add particular classes to the unordered list and the tab containers. If no classes are present, the elements are queried relying on the default structure. The tabStruct option still works but is deprecated and will go away with the next release (Tabs 3).

Say you need a div wrapped around each the unordered list and the containers. Provide the following HTML:

<div id="container">
     <div>
         <ul class="tabs-nav">
             …
         </ul>
     </div>
     <div>
         <div id="fragment-1" class="tabs-container">
             …
         </div>
         <div id="fragment-2" class="tabs-container">
             …
         </div>
         <div id="fragment-3" class="tabs-container">
             …
         </div>
     </div>
</div>

That also means that you can easily switch the order of containers and the list:

<div id="container">
     <div id="fragment-1">
         …
     </div>
     <div id="fragment-2">
         …
     </div>
     <div id="fragment-3">
         …
     </div>
     <ul class="tabs-nav">
          …
     </ul>
</div>

As long as you attach these classes to the proper elements, you can go crazy with your HTML. The class names are even configurable via option. If the default structure is used, adding the class names does no harm but it is not required. They are of course required for the look of the tabs, but they are attached by the plugin if not present. The underlying (default) HTML becomes even more unobtrusive that way and it also becomes much easier to add fallback styles for the case of JavaScript being disabled.

Specify active tab by class

Instead of specifying the active tab when initializing tabs you can now also simply add the class to the list element representing the desired tab, like:

<li class="tabs-selected">

Please note that a given fragment identifier/hash in the URL will take precedence and the class will be removed if the active tab doesn’t match. Here’s how the active tab gets computed: fragment identifier overrules class overrules active tab given as parameter in the initialization.

onClick enhanced

Switching tabs is now canceled if the onClick callback returns false. This is useful for instance if proceeding to the next tab requires form validation before.

Some more changes

• Triggering/Enabling/Disabling tabs can also be done via id instead of an index:

  $('#tabs').triggerTab(1);

  is the same as

  $('#tabs').triggerTab('#tab-1');

• Fixed a bug (duplicate ids) occuring when multiple Ajax tabs containers are included in the same page. Remote tabs are now numbered consecutively.
• There’s a new option hashPrefix to define a string that is used as base for constructing the id of a remote tab, such as “#remote-tab-1″.
• Finally tabs are looking better…
• I’ve fixed a few little quirks in IE introduced with the Ajax support. Along with that goes an update for the History plugin where I’ve fixed a minor bug that occured both in IE and Safari.

I consider this the last maintenance release for the Tabs plugin. After I’ve tackled Thickbox Reloaded I’m going to rewrite Tabs for Tabs 3, which will allow mixed static/Ajax tabs, easy creating and removing tabs, mouseover tabs…

The HTML you need is slightly different from the one that is used for static tabs: A list of links pointing to existing ressources (from where the content gets loaded) and no additional containers at all (unobtrusive!). They’re going to be created on the fly:

<div id="container">
     <ul>
         <li><a href="ahah_1.html">Content 1</a></li>
         <li><a href="ahah_2.html">Content 2</a></li>
         <li><a href="ahah_3.html">Content 3</a></li>
     </ul>
</div>

Initialize the tabs interface with the remote option set to true:

$('#container').tabs({remote: true});

Obviously this will degrade gracefully – the links, e.g. the content, will still be accessible with JavaScript disabled.

All other options and history support should be totally unaffected by that.

There’s another option: While the tab content is being loaded a little spinner left to the tab title text is shown (which you will hardly see on the demo, because it’s loading too fast). Just like in Firefox for example. This is controlled by a CSS class, which you can change:

$('#container').tabs({remote: true, loadingClass: 'progress'});

If you don’t want to show a spinner at all just remove the rule

.anchors .tabs-selected .tabs-loading {
     ...
}

from the style sheet.

This is pretty exciting and I’m looking forward to bring in my capabilities to an already strong team!

What bothered me was that when scrolling or resizing the browser window the Thickbox modal window gets moved to stay in the center, but that happens not smooth at all and with a little delay (after the resize/scroll events get fired that is).

So I changed the Thickbox CSS to use fixed positioning, starting with the modal window:

1. Change CSS to this:

   html, body {
       height: 100%;
   }
   
   #TB_window {
       position: fixed;
       top: 50%;
       left: 50%;
       ...
   }

2. Remove the scroll and resize event handler:

   $(window).scroll(TB_position);
   $(window).resize(TB_position);

3. Change the function TB_position to this:

   function TB_position() {
        $("#TB_window").css({marginLeft: '-' + parseInt(TB_WIDTH / 2) + 'px', width: TB_WIDTH + 'px'});
        if ( !(jQuery.browser.msie && typeof XMLHttpRequest == 'function') ) { // take away IE6
            $("#TB_window").css({marginTop: '-' + parseInt(TB_HEIGHT / 2) + 'px'});
        }
        TB_overlaySize();
   }

   It now pushes the modal window half of its width/height to the left/top from the middle so that it is exactly centered.

4. Fix our special friend IE 6 to emulate a fixed positioning:

   * html #TB_window {
        position: absolute;
        margin-top: expression(0 - parseInt(this.offsetHeight / 2) + (TBWindowMargin = document.documentElement && document.documentElement.scrollTop || document.body.scrollTop) + 'px');
   }

   (Based on http://www.howtocreate.co.uk/fixedPosition.html)

   I use the Star Selector hack to hide these styles from IE 7, which supports fixed
   positioning. Because this being invalid CSS, I recommend inclusion in an extra style sheet via Conditional Comments.

5. Smoooooth.

6. The same consideration applies to the overlay and the spinner. There is still some overhead to compute their dimensions and position depending on the state of the viewport.

   Use fixed positioning here as well and make the overlay 100% wide and high:

   #TB_overlay {
        position: fixed;
        top: 0;
        left: 0;
        width: 100%;
        height: 100%;
        ...
   }
   
   #TB_load {
       position: fixed;
       top: 50%;
       left: 50%;
       margin: -50px 0 0 -50px; /* -height/2 0 0 -width/2 */
       ...
   }

7. Change TB_load_position(); to $('#TB_load').show(); and throw away

   function TB_overlaySize(){
       ...
   }

   and all references to it. Also remove

   function TB_load_position() {
       ...
   }
   
   function TB_getPageScrollTop(){
       ...
   }

   Nearly done!

8. The only thing we still need to do is to accommodate IE 6 with a Dynamic Property again:

   * html #TB_overlay {
        position: absolute;
        height: expression(document.body.scrollHeight > document.body.offsetHeight ? document.body.scrollHeight : document.body.offsetHeight + 'px');
   }

   And don’t forget to add * html #TB_load:

   * html #TB_window, * html #TB_load {
       ...
   }

Here’s a demo with all these modifications to the original. Try scrolling and resizing the window and you will see the difference. I’d really like to see that in a future version of Thickbox. Have fun!

Licensing

First of all I changed the licensing for the plugin. The plugin is available under the the same double licensing scheme as jQuery itself is (MIT/GPL). Thus that should be no problem at all, still I think it’s worth mentioning.

Keep track

The (guaranteed) latest version of the plugin is also available from jQuery’s plugin repository. Check it out from svn://jquery.com/plugins with your Subversion client of choice.

Packer

Tabs is packable with Dean Edward’s JavaScript Compressor. I fixed errors that occured in the packed script (e.g. a missing semicolon) and replaced Conditional Compilation with checks for jQuery.browser.msie. In fact, the script in the downloadable ZIP file is already packed. The download contains an uncompressed file as well for those of you who like to have a look into the source code.

Documentation

I added a complete inline documentation, which can be found in the uncompressed source file.

Bookmarkability and the back button

Tabs are truly bookmarkable. Clicking on a tab changes the hash in the URL. If you use Tabs together with my newly created History/Remote plugin the back (and forward) button is fixed as well. If you use Tabs together with my newly created History/Remote plugin, tabs are truly bookmarkable, e.g. clicking on a tab changes the hash in the URL of the browser, as well as support for the back (and forward) button is enabled. Tabs will auto-detect its presence. Supported browsers are Firefox, Opera, Safari and Internet Explorer. History/Remote is contained in the download.

API change

To pass in the tab to be initially activated you no longer specify it with an “on” option. Instead you pass the number as first argument to the tabs() function. That’s the way it was in the very beginning and I found passing in the initial tab as {on: 2} a little too verbose:

$('#container').tabs(2); // start with second tab
$('#container').tabs(2, { /* options */ });

If a hash in the URL of the page refers to one fragment (tab container) of a tab interface, this parameter will be ignored and instead the tab belonging to that fragment will be activated. If it is omitted it defaults to 1. But because of the bookmarkability of a tab such usage is limited and more or less deprecated anyway. You can always control the active tab on page load by having the appropriate hash in the URL.

Optional settings

All of the following options are key/value pairs in an object literal that is passed to tabs() as an argument . For example:

$('#container').tabs({ fxFade: true, fxAutoHeight: true});

It doesn’t matter if you omit the initial tab parameter or not:

$('#container').tabs(2, { fxFade: true, fxAutoHeight: true});

Effects

fxFade: true

Boolean flag indicating whether fade in/out animations are used for tab switching. Can be combined with fxSlide. Will overrule fxShow/fxHide. Default value: false.

fxSlide: true

Boolean flag indicating whether slide down/up animations are used for tab switching. Can be combined with fxFade. Will overrule fxShow/fxHide. Default value: false.

fxSpeed: 'fast'

A string representing one of the three predefined speeds ("slow", "normal", or "fast") or the number of milliseconds (e.g. 1000) to run an animation. Default value: "normal".

fxShow: {height: 'show', opacity: 'show'}

An object literal of the form jQuery’s animate function expects for making your own, custom animation to reveal a tab upon tab switch. Unlike fxFade or fxSlide this animation is independent from an optional hide animation. Default value: null. See animate.

fxHide: {height: 'hide', opacity: 'hide'}

An object literal of the form jQuery’s animate function expects for making your own, custom animation to hide a tab upon tab switch. Unlike fxFade or fxSlide this animation is independent from an optional show animation. Default value: null. See animate.

fxShowSpeed: 'fast'

A string representing one of the three predefined speeds ("slow", "normal", or "fast") or the number of milliseconds (e.g. 1000) to run the animation specified in fxShow. Default value: fxSpeed.

fxHideSpeed: 'fast'

A string representing one of the three predefined speeds ("slow", "normal", or "fast") or the number of milliseconds (e.g. 1000) to run the animation specified in fxHide. Default value: fxSpeed.

fxAutoHeight: true

Boolean flag that if set to true causes all tab heights to be constant (being the height of the tallest tab). Default value: false.

There’s one more thing about these effects I would like to point out: Even if you use animations, all the tab contents remain fully printable. This is not granted due to how animations work and you will hardly find that taken into account out there.

Other options

callback: function(tabToShow, tabToHide) {
    // do something
}

A function to be executed upon tab switch. If animations are used this function is invoked after the animations are completed. The function gets passed two arguments: the first one is the DOM element containing the content of the clicked tab (e.g. the div), the second argument is the one of the tab that gets hidden. Alternatively the former element can also be refered to with the this keyword in the body of the callback function. Default value: null.

selectedClass: 'a-css-class'

The CSS class attached to the li element representing the currently selected tab. Default value: "tabs-selected".

hideClass: 'a-css-class'

The CSS class used for hiding inactive tabs. A class is used instead of display: none in the style attribute to maintain control over visibility in other media types than screen, most notably print. Default value: "tabs-hide".

tabStruct: 'div>div'

A CSS selector or basic XPath expression reflecting a nested HTML structure that is different from the default single div structure (one div with an id inside the overall container holds one tab’s content). If for instance an additional div is required to wrap up the several tab containers such a structure is expressed by "div>div":

<div id="container">
    <ul>
        <li><a href="#section-1">Section 1</a></li>
        <li><a href="#section-2">Section 2</a></li>
        <li><a href="#section-3">Section 3</a></li>
    </ul>
    <div>
        <div id="section-1">
            ...
        </div>
        <div id="section-2">
            ...
        </div>
        <div id="section-3">
            ...
        </div>
    </div>
</div>

Recap: The default HTML structure the plugin relies on looks like this:

<div id="container">
    <ul>
        <li><a href="#section-1">Section 1</a></li>
        <li><a href="#section-2">Section 2</a></li>
        <li><a href="#section-3">Section 3</a></li>
    </ul>
    <div id="section-1">
        ...
    </div>
    <div id="section-2">
        ...
    </div>
    <div id="section-3">
        ...
    </div>
</div>

Triggering a tab

I have also added a function to activate a tab programmatically (”from outside”), as if the tab itself were clicked:

$('#container').triggerTab(2);

That would activate the second tab for an interface that was created in #container. Such a function comes in handy if you need rotating tabs for instance.

Thats it – have fun! Download and Demo are still in place.

svn://jquery.com/plugins

Or get it here. A few simple examples of how to use it:

$.cookie('the_cookie'); // get cookie
$.cookie('the_cookie', 'the_value'); // set cookie
$.cookie('the_cookie', 'the_value', { expires: 7 }); // set cookie with an expiration date seven days in the future
$.cookie('the_cookie', '', { expires: -1 }); // delete cookie

You’ll find the complete documentation inline.

Update

Ralf Engelschall suggested on the jQuery mailing list, that it is more intuitive to delete a cookie by passing null as value:

$.cookie('the_cookie', null); // delete cookie

I agree and updated the plugin accordingly. The old syntax for deleting still works of course.

The URL for a page with tabs on it must simply contain a fragment identifier (#hash) which refers to a fragment representing the content of one tab. This makes the belonging tab active and the tab bookmarkable. Try this out on the demo page (look at the tabs on top: without the hash portion in the URL the first tab is active):

http://stilbuero.de/jquery/tabs/#section-3

The tab which link refers to the fragment with the id section-3 becomes active:

<!-- tab -->
<li><a href="#section-3">Section 3</a></li>

<!-- tab content -->
<div id="section-3">
    …
</div>

Some notes:

URL takes precedence over option to compute the active tab in the beginning. Any value that is passed as option to the plugin, like {on: 3}, will be ignored if the URL’s fragment identifier matches a tab content holder’s id. If not the active tab is computed as usual (with or without options).

The browser’s scrollbar stays in place. It will not be scrolled to the specified fragment (if that belongs to a tab that is). This would happen especially if a page has a lot of content and the fragment is nearer to the bottom of the viewport or even below.