Printable View
getElementsByClassName has been around for quite awhile, but never a part of the specification. People have written their own, and the best and most versatile do everything this new native method can, some perhaps even more.
Still it will be nice when all browsers have a standard method for this. In the meantime, you can make your own that will work like the new standard and implement it when there is none, or is one that doesn't follow the standard.
Yes, but it's such a pain to create your own function to do that (or maybe it's just me). And I would imagine that, since it's now part of the language, it'll also run faster then a function you build yourself. Unfortunately, right now the only way you can use it is in a try/catch statement, since it's not supported by anything but FF as far as I know-- and, even when it is supported cross browser, it'll be years before browsers without the method stop being used. Still, we're getting there, which makes me happy.
Try/catch is almost never required, and is overused, or used in more general ways than required for efficient code branching. As regards this new native function, a simple test will suffice (in most cases):
It is a little more complicated than that sometimes because getElementsByClassName functions exist, their syntax and capabilities can still be tested against the standard though to tell whether or not they're up to the situation at hand. If they are, might as well use them, if not - go for your own custom function.Code:if (document.getElementsByClassName){
do stuff here that uses it
}
else {
do something else that takes care of it
}
That way your code will benefit from the efficiency of the native and/or existing function, while still being able to execute in the absence of either.
I know, you're right - in actual practice it can be a pain. But that is what must be done any time a new native function (that already had popular approximations in a variety of scripts) is introduced. Over time (in most cases) though, it becomes a standard. At that point backward compatibility can usually be safely abandoned.
In actual practice though, the simple test I provided will work 99% of the time because few scripts will use Element.prototype (supported only by some browsers) to spoof getElementsByClassName, which would be required to satisfy the test in the absence of a native getElementsByClassName.
On second thought, yes, you're right. I was thinking that trying to call the classname method would throw an error in browsers that don't have it, but it won't throw one in an if/else statement. Thank you very much for the correction.Quote:
Originally Posted by jscheuer1
Do you suppose it's worth it to check, though? If you have to make the function anyway, you might as well just use it. But then, perhaps the native function would work better.Quote:
It is a little more complicated than that sometimes because getElementsByClassName functions exist, their syntax and capabilities can still be tested against the standard though to tell whether or not they're up to the situation at hand. If they are, might as well use them, if not - go for your own custom function.
That way your code will benefit from the efficiency of the native and/or existing function, while still being able to execute in the absence of either.
Sorry for my ignorance, but I'm not sure what you mean by that.Quote:
Over time (in most cases) though, it becomes a standard. At that point backward compatibility can usually be safely abandoned.
No need to apologise, that's actually a good question. What I mean is that there was a time (not too many years back) when just about all javascript had to branch on document.layers, document.all, and document.getElementById. Otherwise it would not be functional in at least one major segment of the browsing public's user agents (browsers).Quote:
Originally Posted by Jas
In fact, it is still prudent to do so for certain scripts, especially if the goal is to have something universally applicable. However, for the most part document.getElementById can more or less just be assumed nowadays, or at the very least safely branched upon, and then ignoring all else.
So, in the case of document.getElementById, this has more or less already happened. We no longer must branch off to documnet.layers (NN 4) or document.all (IE 4), because almost no one uses these any longer, and if they do, simply rendering most pages will be an issue, let alone handling any javascript on those pages. But it is still prudent to check for document.getElementById and simply stop execution (degrade gracefully) if it isn't available.
One day document.getElementsByClassName will be the same, though it certainly isn't at the moment.
Here you can view a speed comparison between Firefox 3's native getElementsByClassName and some other popular prior custom implementation here.
I've used Firefox 3.01 for a while but most of the Firefox add-ons I've been using are incompatible with it especially Firebug. Though Firebug beta releases can be used with it but Firebug used to show some incorrect information especially during the AJAX call tracking. So I've changed back to Firefox 2.0.0.16.
I haven't done much JS troubleshooting with Web Developer add-on
Thanks, John. I think that I understand, now.
Codeexploiter: I don't use firebug much, but I know a lot of people haven't switch yet because of that. The Web Dev add on seems to work in Firefox 3, though. I use that add on all the time.
I recently upped to FF 3, and having recently read some very promising things about Firebug, decided to grab it. The version of Firebug I got is for FF 3, seems to work fine, but I can't be sure yet as I'm still on the learning curve with it. I had been using Developer Extension, and it automatically upgraded when I got FF 3, except that I had to manually add Dom Inspector as it no longer is a 'come with' in FF 3. For those unfamiliar with Developer Extension, in the past it has always just grabbed FF's native Dom Inspector and made it look like part of the Developer Extension package. Developer Extension is working fine, but I notice the 'view generated source' causes a script error at least some of the time it is run, but that doesn't seem to hurt anything. Also, as I had previously configured my editor as one possible option for code view, I see that is no longer working, though I cannot seem to fix that, even by reconfiguring it. I haven't spent a great deal of time trying to tweak these two minor issues (the script error on 'view generated' looks like an edit of one of FF's own script files would do the job) though because I still have FF 2 installed (just in case). I'm thinking very seriously of removing it, and then worrying about these other two things. I may be best off uninstalling both versions then going with a fresh install of 3.
I just downloaded FF3. I liked some of the added features. for example, when you type a letter on the address bar( not sure what its exact name for it). It will show up the websites you last went to that has the letter . Quite interesting I feel. Another thing, It may sound dumb. But its seems my FF3 loaded kind of faster than FF2. Is that related to my connection speed or partly because of the program?
I think I've heard that it's supposed to have better graphics support and a better interface with the Windows kernel. The second would only matter on a Windows based machine. I haven't noticed anything that would indicate either of these in any dramatic way. It still gets jerky with javascript animation - more so than IE, so the kernel interface could use more improvement IMHO.