Learning jQuery

In the beginning (well, beginning with jQuery 1.2.3 in early 2008) there was the jQuery.data() API. It offers a way to associate JavaScript data — strings, numbers, or any object — with a DOM element. As long as you manipulate the DOM element with jQuery, the library ensures that when the DOM element goes away, the associated data goes away as well. This is especially important for older versions of IE that tend to leak memory when JavaScript data is mixed with DOM data.

Most jQuery code sets data values using the higher-level .data() API; for example, $("div").data("imaDiv", true) sets a boolean value on every div in the document. This API, in turn, calls down to jQuery.data() with each element to set the value. For completeness, there are also jQuery.removeData() and .removeData() to remove data elements, and jQuery.hasData() to determine if any data is currently set for an element.

Read the rest of this entry »

I just got back from the jQuery conference in San Francisco. Wow, what an event. In addition to some incredible talks, I had the opportunity to speak with Rey Bango, Johnathon Sharp, and, of course, John Resig. Any conference where you get to talk to some of the most influential people in jQuery is a win in my book. The “High Performance JQuery” presentation especially caught my attention when the speaker, Robert Duffy, said that .hide() and .show() were slower than changing the css directly. Not having occasion to ask him why, I benchmarked the various ways to hide DOM elements and looked into the jQuery source to find out what is going on.

The HTML I tested against was a page of 100 div tags with a class and some content, I cached the selector $('div') to use with each method to exclude the time needed to find all the div elements on the page from the test. I used jQuery 1.4.2 for the testing, but keep in mind that the algorithms behind the method calls can change dramatically from version to version. What is true for 1.4.2 is not necessarily true for other versions of the library.

The methods I tested were .toggle(), .show() & .hide(), .css({'display':'none'}) & .css({'display':'block'}), and .addClass('hide') & .removeClass('hide'). I also tested modifying an attribute of a <style> element.

Read the rest of this entry »

Editor’s Note: When I started this blog nearly three years ago, one of the first things I did was write a series on showing and hiding elements on a page. The posts were very basic, as was my knowledge at the time. At best, they demonstrated an incomplete answer to the question of how to selectively reveal content based on user interaction. At worst, they encouraged a solution without any regard to accessibility. That’s why I was thrilled when I saw an article on the Filament Group blog describing their accessible collapsible content widget. They’ve graciously accepted my request to re-post that article here, so without any further ado, here it is…

Collapsible content areas are frequently presented in web sites and applications as a way to let users to control how content is shown or hidden on the page. Also called collapsibles, spin-downs, toggle panels, twisties, and content disclosures, they’re ideal for selectively displaying optional information — like instructional text or additional details, for example — so users can focus on the task at hand and view this content only as needed.

The collapsible content area widget is fairly simple — a couple of HTML elements controlled with minimal CSS and JavaScript — but when we were researching our book, Designing with Progressive Enhancement, we discovered that many common approaches to creating collapsible content fail to incorporate accessibility features. Happily, there is a way to build collapsible content with progressive enhancement so it delivers an optimal accessible experience for sighted and screen reader users alike.

The code example described in this article is one of the 12 fully-accessible, project-ready, progressive enhancement-driven widgets that accompanies our new book, Designing with Progressive Enhancement.

Read the rest of this entry »

There are many, many jQuery tooltip plugins out there, and some of them are very good. But when someone on the jQuery Google Group asked (a year ago) which plugin could handle displaying tooltips for 2,000 links on a page, I wasn’t able to find one. So, I decided to throw together a quick little plugin myself and was surprised by how easy it was.

Event Delegation, Again

The key to having JavaScript handle hundreds, or even thousands, of elements on a page is to use event delegation. As Louis-Rémi Babé described in Working with Events, Part 3: More Event Delegation with jQuery, jQuery’s .live() method makes event delegation dead easy. A simple tooltip script using .live() might look something like this:

Read the rest of this entry »

The .append() method is perhaps the most misused of all jQuery methods. While an extremely useful and easy method to work with, it dramatically affects the performance of your page. When misused, the .append() method can cripple your JavaScript code’s performance. When used well, it’ll keep your script humming along.

Read the rest of this entry »

A common feature I’ve seen on “web 2.0” sites and wikis is the “external link” icon: . While I’m not crazy about the idea of sticking these little images all over the HTML, they’re a great candidate for using progressive enhancement. In our case, we can use jQuery to add the images pretty easily.

Read the rest of this entry »