• Choose a category
• All
• Classic-Fiction

When users clicks on a celebrity, their selection should appear above the list in the format “category > celebrity” as in Figure 8.4. So what’s the best way to capture this information?

Figure 8.4. Delegating events

If we added a click event handler to every single list item—$('#picker li').click(…)—we could end up with hundreds of handlers. This would severely impact performance, as the browser would need to keep track of them all and check them all whenever a click occurred on the page. With event delegation, we add our lone event handler to the parent of the list, and then access the target of the event to determine the element that was actually clicked on. The target property of an event is the actual DOM element—so it needs to be wrapped in the jQuery selector to obtain a jQuery object:

$('#picker').click(function(e) {

$('#current').text($(e.target).text());

});

Our list acts as if each item has its own handler! Nice, but what was the gotcha mentioned earlier? Event delegation works because of event bubbling (which we looked at in the section called “Event Propagation” in Chapter 5)—the events will bubble up until our parent handler catches them. The problem occurs if a handler catches the event before the parent and stops the event from propagating (with e.stopPropagation, or "return false"). If the event is stopped on its way up, event delegation will fail! That’s why it’s important that you know how events are being handled under the hood—it’ll save you a lot of headaches when dealing with otherwise incomprehensible bugs.

We’ve handled any clicks with a single handler, but we now need to find out a bit more about where the element is located. Specifically, how can we find out which category the element is in? How about this:

(excerpt)

$('#picker').click(function(e) {

var celebrity = $(e.target).text();

var category = $(e.target)

.closest('.category')

.find('.title')

.text();

$('#current').text(category + " > " + celebrity);

});

We’ve asked the closest method to find the closest element with the category class. If the element itself doesn’t have that class, closest will check its parent … and so on until it finds a matching element. This saves us having long strings of parent().parent().parent(), and also lets us be more flexible in how we structure our HTML.

Tables

If HTML lists are the unsung heroes of the new Web, tables are that bad kid who ends up turning out good. The tables themselves were never to blame—we misused and abused them for years as a hack to lay out our web designs in a reasonable cross-browser manner. But that’s what CSS is for, not poor old tables. And now that CSS has come of age, we can finally return to using tables solely for their original purpose: displaying tabular data.

StarTrackr! has stacks of data to display. So much so that it’s growing out of hand: the tables are becoming overly large and unreadable, the information has no paging or sorting mechanisms, and there’s no way to edit the information easily. We saw how easy it was to add zebra striping and row highlighting to tables in Chapter 2; this will give us a few quick wins, but to address the more serious table issues, we’re going to need some extra help from jQuery.

Fixed Table Headers

The header row of a table is of paramount importance: without it, you’d be stuck with rows of meaningless data. But if you’re dealing with a large number of rows, you’ll find that the headers become less and less helpful, as they scroll out of sight and out of mind. Paging the data generally takes care of the problem—but if you need to have all the data on one page at the same time, you’ll have to think of another option.

Keeping the header row fixed at the top of the table is an effective way to keep track of what our columns are about, and it also looks really cool! As the user scrolls the table to reveal new data, the header follows along. You can see this