How can you wonder what is returned?
if (condition)
{
return false;
}
// this would tell you if false was returned. assuming it doesn't return false
// later on, we now know false wasn't returned.
alert('false not returned, so whatever is returned below...');
And what do you mean by recognize? Looking at the code
/* Decide wether DOM is implemented or not by checking for
document.getElementById */
isDOM = document.getElementById ? true : false;
/* isDOM is true in all new (major) browsers: IE 8, FF 3.6, Chrome, and also in their
older versions (IE6 and IE7, FF 3, possibly FF2, Chrome didn't exist) and also in all
browsers of lower market share that I know of (Safari, Opera etc)
This means that !isDOM is expected to be false in any currently used browser.
if (!isDOM && otherConditionsWillNotBeEvaluated)
{
return false;
}
So either something else is screwing up a modern FF (and no surprise there since you can't expect KLayers to support it), or by "recognize FF", do you mean that it should go to the "return false part" part?
If the latter is the case, you could check FF's js documentation and try for anything included in say Gecko 1.6 or later, for example
// Gecko 1.6
if (Array.indexOf)
{
}
There is of course no guarantee that IE9 won't implement this or that it exists in webkit (more about how and why to perform tests further down). And perhaps there are FF versions that you consider "too new" that still only had 1.5 (and I don't know where to find documentation for Gecko less than v 1.5, so I wouldn't know how to find changes unless by trial and error.
So, I'd really really recommend switching away from KLayers as soon as humanly possible, since a google search for klayers found me this page tells me that
KLayers page wrote:
KLayers is a JavaScript program, so it is included by standart tags
<script language="JavaScript" type="text/javascript" src="klayers.js"></script>
There is no language attribute for the script element. And for elements that do have a language attribute, JavaScript is not one of the accepted languages, since it's intended for natural languages.
It might be seen as a minor issue, but I'm sceptical if they tell me to break document validation simply by using their product. And yes, you could simply remove the language attribute, but this is an issue of trust for me.
KLayers page wrote:
Supported browsers?
This version of KLayers supports all main DHTML-browsers:
* MSIE 4, 5, 6;
* Netscape 4, 6, 7, Mozilla;
* Opera 5, 6 (partially), 7 (full support)
Other browsers officially not supported.
In case of new DHTML-browsers releasing I will add it's support to new versions of KLayers and you should only download updated version of KLayers.
I know you wrote "OLD", but this is ancient! IE4 was released in 97 and IE5 was released in 99. So part of the code is targetting a browser which hasn't been used for roughly 10 years! IE6 which is their latest supported IE version holds no more than roughly 5% of the browser market share and while it is supported by microsoft for Windows XP SP3, it was superceded by IE7 5 years ago!
So, it seems safe to say that KLayers has not been in development for about 5 years, meaning that it may not work with IE8 (30% market share), Firefox 3.6 (25%) and Chrome (15%). Statistics according to Statcounter. Be aware that you may find completely different stats depending on where you collect your user data (w3 for example has <30% total for IE).
Anyway, since the purpose of this library is cross browser interoperability, I'd choose something that actually target's browsers in use today.
Another issue is with the initKLayers function itself. It seems to want to decide by a few simple rules what kind of browser you are using. The problem is that a newer version of a browser suddenly may fall into another browser's category with this kind of testing.
For example, up until 2006 (IE7) you might have decided that a browser couldn't be IE by checking for XMLHttpRequest, and after this check you go on and happily use window.getComputedStyle. Then IE7 introduces XMLHttpRequest and if your order of tests is done in such a way that IE7 is ruled out of being an IE browser (instead of first finding out that it is), while it still hasn't implemented window.getComputedStyle.
The recommended way of doing things is testing for functionality, not for browser families etc. The UA string can be set and changed by the user and cannot be trusted. Also, it might fail for new browsers and versions.
If, at every point you want to do something (with differing or missing implementations) check if it can be done, you also have a higher likelihood of a newer browser supporting one of the old ways of doing it.
var el = someElement;
var w = window;
// Most browsers. (iirc including Opera. Does it also include IE8? or will IE9 fit here?)
if (w.getComputedStyle)
{
// Use w.getComputedStyle and whatever you need from this style object
}
/* This is IE (iirc including Opera. IE8 is here. IE9 will definitely have this support
even if they add support for getComputedStyle.
Now, iirc getComputedStyle has advantages over currentStyle (I believe Opera
has this element attribute, but spotty support, while implementing a decent
version of getComputedStyle), I prefer using that if possible, which means I put
that test first for a reason. But apart from this, it doesn't matter which category
a browser falls into when I only test for support when using that very thing
*/
if (el.currentStyle)
{
// Make use of el.currentStyle
}
