Time for some champagne on a monday morning! W000t!!!1!

“The sad truth about CSS3 selectors is that they really shouldn’t be used at all if you care about page performance. Decorating your markup with classes and ids and matching purely on those while avoiding all uses of sibling, descendant and child selectors will actually make a page perform significantly better in all browsers.”

(http://www.shauninman.com/archive/2008/05…)

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.

Try it ;-)

(Courtesy of Sean Treadway – thanks for making my day!)

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…

Rock ‘n Roll! You are 4.31 % mainstream!

What are you?

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!