> From: ldexterldesign
>
> regarding your second point about using classes instead of
> IDs in my XHTML, i agree, but i am under the impression that
> warranting the use of classes on elements should only occur
> if you plan to re-use the object, otherwise ID it - i stand
> by this ethos, but i'm not as adept with JQ as you right now,
> so things may change. i am aware of ID overuse though and try
> to use as few as possible. is there some sort of speed issue
> with how JQ handles IDs as opposed to classes then?
Not at all, in fact just the opposite: In typical documents, $('#myid') can be
*much* faster than $('.myclass').
I think Glen was advocating the flexibility of classes, such as the way they
allow you to select multiple elements in a convenient
way and call a jQuery method on all of them simultaneously. Selecting by class
can also help you write more reusable code.
But if you know you're dealing with a single element, by all means use an ID
for speed.
One interesting code design point related to this: How do you access the
underlying DOM element(s) for a jQuery object? Normally,
you use .each() and a callback function. But when you use an ID selector, it's
perfectly reasonable to use [0].
For example, this code *must* use .each() - or an equivalent for loop - because
it has no way of knowing how many elements match the
selector:
function test( selector ) {
$(selector).each( function() {
// do something with each DOM element
});
}
Similarly, a more hard-coded version must also use .each(), because there may
be more than one element matching '.myclass:
$('.myclass').each( function() {
// do something with each DOM element
});
But if I saw this code, a mental alarm would go off (what if there is more than
one match?):
$('.myclass')[0].someDomMethod();
However, this code is perfectly reasonable (unless you need to handle the case
where the #myid element does not exist on the page):
$('#myid')[0].someDomMethod();
-Mike
