It can be tough to be practical and ethical at the same time. Ethically, I
believe in the W3C recommendations. I believe in advancing and supporting
accessibility and the document object model. The Internet should exclude the
fewest possible people. But practically speaking, I write code. And the code
that I write usually requires a modern, document object supportive browser
to really do its stuff.
My pages begin life as ordinary html and CSS. When I add scripts to these clean,valid pages, I wind up with something everyone can use, to some extent. If I am very, very careful.
It is not too difficult to write pages that work in either and both of these cases:
It is fairly easy to write scripts that work in the newest browsers. Trouble starts when the real world gets online, with browsers that support some but not all of the script. Give a half smart browser enough code and it'll hang itself...
I run a small shop, with a small budget. I don't have a test machine for every platform. I want to deliver my scripts only to the visitors that can use them.
If you set up your pages to run basic html, and limit the built in events to hyperlink navigation and server based forms, any page can display in any browser. Any other events can be built in scripts, and you can restrict the visitors who load the scripts to the folks who can use them. To each according to his ability...
In html, before the W3 put the kibosh on the 'language' attribute, you could screen the browsers by setting a version number of the language in the script tag:
<script language="JavaScript1.5" src="srcfile.js"></script>
This would prevent a browser that didn't support version1.5 loading the file.
You could get fancier, and load different scripts for various levels of support:
<script
language="JavaScript"src="srcfile1.js"></script>
<script language="JavaScript1.2" src="srcfile2.js"></script>
<script language="JavaScript1.5" src="srcfile3.js"></script>
Scripts here are cumulative. The first script loads in any browser that supports the 'src' attribute for external scripts. If number 3 loads, you can count on having the first two as well. Each can have an onload handler- the last handler assigned will be used when everything finally loads.
I wrote a lot of code like this, back when...
But no more. The language attribute is dead- or, as the W3 says, deprecated. None of the pages that use it will validate, whether or not the attribute does anything for the user. It really wasn't without flaws, to tell the truth. Navigator has some famous problems when you set the language to '1.2'- lots of little things don't work the way they ought to. And some browsers will always load the source file, whatever you set the language to.
The 'legal' way to assign a script to an html page is to use the "type" attribute:
<script type="text/javascript" src="srcfile.js"></script>
Lately most of the code I write is dom code. IE4 and Netscape, for example, display the plain page,or maybe use some html 0 code in a cross browser script. But the biggest part of my code is aimed at dom enabled browsers, and should have no affect on the others.
The hangnail to this is that even if the browser doesn't set any event handlers or run any procedures, it still has to parse the script file. Even if they are never called, all of the variables and functions are stored in memory. You have to be careful to check with the client before every function call or event handler. As a quick and dirty solution, it works, most of the time.
But...
There are some additions to javascript that break older versions. Even if you don't call a function , even if you burrow the new code in ifs and sniffer switches, just parsing a suspect line of code can throw an error. A good example is try...catch error handling. Navigator throws an error when it reads a line that uses 'try' as a method. It is (to N4) a protected keyword. And try is such a nice little method...
This turns a practice that was admittedly inelegant but relatively harmless into an error throwing monster.We are back to where we used to be. We want to only load a script to a browser that can run it.
If you want to separate the haves from the have nots, and give the plain page only to users who can not use the script, you can tell the browser to test for a method you want to use, and load a different page if the method is supported.
To add scripting only for browsers that understand the document object model:
Put a script in the head of the document:
<script type="text/javascript">
if (document.createTextNode) location.replace('thisforDOMbrowsers.html');
</script>
It works- if a page doesn't support the method nothing happens, you stay where you are. If it is supported, the new page will be a copy of the original, with a script included.
You end up with a lot more pages on your website. And as long as people can type urls, it ain't perfect, they can always get to a page that will cause problems. Not to mention links and src files that will be twice as hard to maintain.
Your users are also apt to complain about being pinballed around your site. And accessibility standards don't like it either. Gotta be a better way.
This method solves my problem. It separates browsers that support the dom from the rest. No support means the script is not loaded. Support means the script is loaded. But it is the same html, the same url, the same page for everyone.
Instead of this being in the head of the document:
<script type="text/javascript" src="mrhoo.js"></script>
I use this:
<script type= "text/javascript" >
<!--
if(document.createTextNode){
var str='<script type="text\/javascript" src="mrhoo.js"><\/script>';
document.write(str);
}
}
//-->
</script>
And that's how I can give the same page to everyone.
