Browser support and Script layout

[blm126]

So, lately I've been rewriting a script of mine, and I've been wondering. When you write a script, what browsers do you support? And, when you use a script written by someone else, what browsers do you like to be supported? I'm asking because this script currently supports IE 5.5, but I'm not really sure if it's worth it anymore. It's hard to test, and harder to code for. Then there are the browsers I don't even have access to, like IE5/Mac and Safari/Mac.

And, another related question. In this script I'm writing, the code length has ballooned. When I'm developing the script I have different portions of the script split into files. These other files add new features to the script, but aren't really needed for the script to run. As a person implementing the script, would you prefer separate files or one large file?

[Nile]

Make sure that it works in the main browsers. Like Internet Explorer, Safari, Opera, and FireFox. That way most users will be happy with the results.

I personally don't like when people use a lot of files. But one reason why they do it is for different browsers. There's also another way that some people don't know of. And thats to see in an if statement, like below:

<script type="text/javascript">
function checkBrowser(){
if(document.all){
alert("Internet Explorer, and a few others...");
} else {
alert("FireFox, Safari, and a few others...");
}
}
window.onLoad=checkBrowser();
</script>

I hope this helps,
Nile

[kdhamric]

You can use crossbrowsertesting.com to test both the appearance of your pages and the underlying javascript functionality. It allows you to select the configuration you want to test, then launches a vnc window giving you access to that remote desktop. We are not supporting IE5 on the Mac platform yet, but you can test to make sure your script works on the Safari / Mac combination.
Thanks,
Ken

So, lately I've been rewriting a script of mine, and I've been wondering. When you write a script, what browsers do you support? And, when you use a script written by someone else, what browsers do you like to be supported? I'm asking because this script currently supports IE 5.5, but I'm not really sure if it's worth it anymore. It's hard to test, and harder to code for. Then there are the browsers I don't even have access to, like IE5/Mac and Safari/Mac.

[Nile]

Can't you just shut down someones computer with www.crossbrowsertesting.com?

[jscheuer1]

<script type="text/javascript">
function checkBrowser(){
if(document.all){
alert("Internet Explorer, and a few others...");
} else {
alert("FireFox, Safari, and a few others...");
}
}
window.onLoad=checkBrowser();
</script>

That's horrible, don't ever do it. You don't need exclusive document.all for any but IE 4 anyway (and almost nothing worth doing will work it that browser), so not much point in testing for it, except in a code branch where you might use:

getElementsByTagName('*')

In some of the generation 5 IE browsers (all of which support getElementsByTagName for specific tag names), the global ('*') tag name is not supported, document.all or document.allTags must be used instead.

For cross browser support, it is best as you move through the code simply to test if a method is available and if it provides the type of data expected, if not, use another approach or degrade.

[Nile]

@jscheuer1
I didn't mean document.all I meant something other, but document.all was an example.

[jscheuer1]

@jscheuer1
I didn't mean document.all I meant something other, but document.all was an example.

Well say what you mean. It's fine to test for a feature (object), including document.all if that is what you intend to use. However, it is never a good idea to think you have determined anything other than the availability of said feature (object). Your code suggests that some conclusions about the browser's identity can be gleaned from such a test. Although such conclusions are often reasonable in the majority of cases, they certainly are not in all cases, sometimes not even in the majority of cases, and so should never be relied upon in well written code.