Categories
JavaScript

Netscape Navigator’s JavaScript 1.1 vs Microsoft Internet Explorer’s JScript

Originally appeared in Digital Cats magazine. Found courtesy Wayback Machine.

Prior to Netscape implementing JavaScript in Netscape Navigator, web developers had few tools to create interactive content for their web pages. Now this scripting language gives developers the ability to do things such as check form contents, communicate with the user based on their actions, and modify the web page dynamically without the web page being re-loaded and without the use of Java, plug-ins or ActiveX controls.

Unfortunately, JavaScript was not usable by any other browser until Microsoft released Internet Explorer (IE) 3.0. With this release web developers could deliver interactive content that would at least work with the two most widely used browsers. Or could they?

On the surface, the JavaScript supported by both companies is identical. They both provide the same conditional control statements, have defined objects such as window or document,and can be used directly in HTML documents. They both support events based on user actions and support functions in a similar manner. However, this article will demonstrate that though the languages may look the same on the surface, there are differences that can trip the unwary developer.

JavaScript Objects

To understand the differences between the two implementations of JavaScript you must examine the objects both support. As an example, with Navigator 3.0 Netscape provides a new object image which is an array (defined as images that contains the images in the document currently loaded. This object allows the developer to change the images of a document without re-loading the document or using Java or other technique. With this capability the developer can write the following JavaScript code section without error:


sSelected = "http://www.some.com/some.gif"
document.images[iIndex].src = sSelected

This code will change the src property of the image that is contained in the array at the index given in the variable iIndex. If this variable contained the value 2, the 3rd image as loaded in the document (the array indices begin at 0) would be changed to the image located in the given URL. An example using images can be found here.

Running the same example with Internet Explorer will result in a alert message that states that “‘images’ is not an object”.

Other examples of objects that are defined for Netscape Navigator but not for Microsoft Internet Explorer are:

  • The Area object, which is an array of links for an image map that allows the developer to capture certain events for the image map that can be used to provide additional information to the user. With this, the developer can capture a mouseOver event to write out information about the link in the status bar.
  • The FileUpload object which provides a text like control and a button marked with “Browse” that will allow a reader to enter a file name. The JavaScript can then access the name of the file.
  • The Function object which allows the developer to define and assign a function to a variable which can then be assigned to an event.
  • The mimeTypes Array of supported MIME types.
  • The option object which is an array of the options implemented for SELECT and which allows the developer to change the text of the option at runtime
  • The applet object, which is an array of Applets in the document (read-only)
  • The plugin object, which is an array called embeds that contains the plug-ins contained in the document (read-only)
  • The plugins array, which is an array of plug-ins currently installed in the client browser

At this time there are no JavaScript or JScript objects defined for Internet Explorer that are also not defined for Netscape. However, as JScript is an implementation script for IE and Microsoft has defined their own IE scripting model, this could change in the future.

JavaScript Object Behavior and Ownership

Internet Explorer may not have additional objects but it has defined a different hierarchy and ownership for some of the objects that are used by both it and Navigator. All objects are contained within the window object in the IE scripting model, which can be viewed here, but not all objects are owned by window with the Navigator model, which can be viewed with the JavaScript Authoring Guide. The object Navigator, which is the object that stores information about the browser currently being used, is an example of an owned object by window in IE but not in Navigator.

This will not present an incompatibility problem between the two browsers as the developer will usually not preface the object with the term “window” as the following code demonstrates:


<FORM NAME="form1">
<input type=button value='press' onClick="alert(navigator.appName)">
</FORM>

The above code will work with both browsers.

The differences between the ownership can become a problem when an object is owned by different levels of objects. An example is the history object, which is owned by the window object in IE, but by the document object in Navigator. When used in the current window and document, the object will work the same as the following code will demonstrate:


<FORM NAME="form1">
<input type=button value='press' onClick="history.back()">
</FORM>
 

The reason the same code can work for both is that window is assumed for both IE and Netscape and document is assumed for Navigator, at least in this instance because history is also an object in its own right. In the case of a document being opened as part of a frame, the differences then become noticeable. The following code will work when the document is opened as a frame in IE, but will not work in Navigator:


<body>
<script>
function clicked() {
history.back()
}
</script>
<FORM NAME="form1">
<input type=button value='press' onClick="clicked()">
</FORM>
</body>

Clicking on the button from the code above will work for IE. The previous document in the History list will be opened, but the same code will not work for Navigator. Clicking on the button will result in neither a change of document nor an error. Prefacing the history object with parent will enable this code to work with both browsers.

JavaScript Properties

Even when IE and Navigator share a common object and a common object ownership, they can differ on the properties for an object. An example is the document object. The properties for both implementations are the same except for an URL property for the Navigator implementation and a location property for the IE implementation. However, if you examine both properties, they are identical! Both contain the URL of the document. Both are read-only. The following code will work with Navigator, but results in an empty Alert message box for IE:


<FORM NAME="form1">
<input type=button value='press' onClick="alert(document.URL)">
</FORM>

According to Microsoft documentation, the equivalent for IE would be to use document.location.href. However, though this does not result in an error, it also results in an empty alert box. The following code achieves the desired results and, happily, works in both browsers:


<FORM NAME="form1">
<input type=button value='press' onClick="alert(location.href)">
</FORM>

The above example does demonstrate another area of caution when using the JavaScript language: this language is unstable in both environments and is changing continuously. Don’t assume something will work because the documentation states it will, and don’t assume it will work the same on all operating systems. Both browsers can have different behaviors across different operating systems, sometimes because of operating system differences and sometimes because of bugs that were missed during testing on that specific OS.

JavaScript Methods and Events

A web developer can find ways of working around differences in objects and properties, but working around differences in methods may not be so easy. When we develop we expect a certain behavior to result when we call a specific function and pass to it certain parameters. With Microsoft Internet Explorer and Netscape Navigator, the best case scenario is that we can use a pre-defined object method with both browsers and have the same result. The worst case scenario is that the method works with both browsers, but the result is different.

An example of the best case scenario is to use JavaScript to validate form field contents which have changed or to use these contents to calculate a value used elsewhere. Calling a JavaScript function from the onChange event to process the changed contents as demonstrated below will work with both browsers:


<!--- Form fields
<p>Item Quantity: <INPUT TYPE="text" Name="qty">
Item Cost: <INPUT TYPE="text" Name="cost"
                onChange="NewCost()">
Total Cost: <INPUT TYPE="text" Name="total" Value=0>
…
<!--- Function
<SCRIPT LANGUAGE="javascript">
<!--- hide script from old browsers

// NewCost will
// calculate cost of qty and item
function NewCost() {
        var iCost = parseFloat(document.Item.cost.value)
        var iQty = parseInt(document.Item.qty.value)

        var iTotal = iCost * iQty
        document.Item.total.value = iTotal
        }

The above will work as expected with both IE and Navigator. When the user enters a quantity and a cost, the onChange event will fire for the cost field and a JavaScript function called NewCost() will be called. This function will call two built-in JavaScript functions, parseFloat() and parseInt(), to access and convert the form field values. These will then be used to compute a total which is placed in the total field.

So far so good. Another JavaScript function in the web page will be processed when the user presses the submit button. This pre-defined button style will normally submit the form. The developer can capture the submission and perform validation on the fields. Coding this for Navigator would look like the following:


<FORM NAME="Item"
        ACTION="some.cgi" onSubmit="return SendOrder()">
…
<!--- Function
// submit order
function SendOrder() {

        // validate data
        if (document.Item.Name.value == "") {
                alert("You must enter your name")
                return false
                }
        return true
        }

Capturing the onSubmit event will allow the developer to call a function to process the form fields. If they choose, they can perform validation in this function. If the validation fails, say the user did not provide a name, the function notifies the reader and returns false, preventing the form from being submitted. If the user did provide a name, the function would return true, and the form would be submitted.

Following the documentation that can be found at the Microsoft site, the developer would expect something like this to work for IE as well as Navigator. It does, to a point.

With IE the onSubmit event is captured and the SendOrder() function is called. If the user did not enter a name value, an alert would occur. The behavior is the same for both browsers at this point. However, if the user does provide a value, Navigator would then submit the form and a follow-up form would be displayed. This does NOT occur with IE IF you are testing the page locally, probably due to a bug missed during the testing. It does work if you run the web page documents through a web server.

However, without knowing that the difference between the two results was a matter of document location rather than document coding the web page developer could have spent considerable time trying to get the same behavior for both browsers.

Aside from the differences already noted, the browsers may process code in a funtionally identical manner and yet perform quite differently. This can be demonstrated with another popular use of JavaScript which is to open a secondary window for some purpose and to maintain communication between the two windows. This is widely used by Netscape for their tutorials.

Both browsers support a property for the window object called opener. This property can be used to contain a reference to the window that opened the secondary window.

The following code demonstrates using JavaScript to open a secondary window and to set the opener property to the original window:


<HTML>
<HEAD><TITLE> Original Window </TITLE>
<SCRIPT LANGUAGE="JavaScript">
<!--- hide script from old browsers
// OpenSecondary will open a second window
//
function OpenSecond(iType, sMessage) {
        // open window
        newWindow=window.open("second.htm","",
                "toolbar=no,directories=no,width=500,height=300")
        // modify the new windows opener value to
        // point to this window
        if (newWindow != null && newWindow.opener == null)
                newWindow.opener=window

        }
// end hiding from old browsers -->
</SCRIPT>
</HEAD>
<BODY>
<H1> Open a new Window and get information</H1>

<FORM NAME="CallWindow">
<p>Click to open Window:
<p>
<INPUT TYPE="button" NAME="OpenWin" VALUE="Click Here"
        onClick="OpenSecond()">
<p>
</FORM>
</BODY>
</HTML>

The above HTML and JavaScript creates a simple document with one button. Pressing the button opens a new window (creates a new instance of the browser) that does not have a toolbar or directories and is set to a certain width and height. The HTML source document that is opened into this new window is “second.htm”.

The HTML and JavaScript in the secondary window is shown below:


<HTML>
<HEAD><TITLE> Information</TITLE>

<SCRIPT LANGUAGE="JavaScript">
<!--- hide script from old browsers
// SetInformation
// function will get input values
// and set to calling window
function SetInformation() {
        opener.document.open()
        opener.document.write("<BODY>")
        opener.document.write("<H1> Return from Secondary</h1>")
        opener.document.write("</BODY>")
        opener.document.close()
        opener.document.bgColor="#ff0000"
        window.close()
        }
// end hiding from old browsers -->
</SCRIPT>
</HEAD>
<BODY>
<p><form>
Click on the button:<p>
<INPUT type="button" Value="Click on Me"
     onClick="SetInformation()">
</CENTER>
</FORM>
</BODY>
</HTML>

This code will display a button labeled “Click on Me”. Pressing this button will result in the document page for the original window being modified to display the words “Return from Secondary”. The JavaScript will also change the background color of the original document and then will close the secondary window. When run in Navigator, the sample behaves as expected. Not so, however, with IE.

First, when you open the secondary window in IE you will notice that the document in the original window seems to blank out for a moment. In addition, the secondary window opens at the top left hand side of the desktop with IE but opens directly over the original window with Navigator, no matter where that original window is.

When you press the button that modifies the original document, IE does modify the document with the new header, as Navigator does, and the background on the original document will change briefly. However, when the secondary window is closed the background color of the original document returns to the original color!

What is worse is that running this sample for a few times with IE will cause the browser to crash! How soon it will crash seems to suggest that resources are not being freed, or are being freed incorrectly. Whatever the cause, this behavior should make a developer feel cautious about opening up a secondary window within IE.

Solutions to working with both Internet Explorer and Navigator

JavaScript is a useful tool for creating interactive content without using Java or some other technique. As we have seen, problems arise out of the incompatibility between Navigator and IE. What are ways to avoid these problems?

  • Code for one browser only. This is not really a viable solution. While Netscape Navigator is the most popular browser in use today, Microsoft Internet Explorer is gaining quite a following. Using Navigator-only JavaScript that will limit your web page’s audience.
  • Code only to the least common denominator. By limiting the JavaScript to that which works for both Navigator and IE, developers will have access to most of the functionality they need. However, with this approach developers will need to be aware of the gotchas that have been discussed in this article. In other words, the developer has to test with both browsers; the tests will have to occur via the web server as well as run locally; the tests should be repeated several times to ensure that no adverse effects show up over time; the code should be tested with all possible environments.
  • Code for each browser within the same page. This is actually my favorite approach though it will require more effort by the developer. Both browsers will process JavaScript labeled as <SCRIPT LANGUAGE=”javascript”>, however only Navigator will process script labeled as <SCRIPT LANGUAGE=”javascript1.1″>. With this approach, the developer can place JavaScript common to both browsers in a SCRIPT tag labeled with “javascript” and Navigator specific code in a SCRIPT tag labeled with “javascript1.1”. To add in IE specific code, the developer would probably want to use VBScript code or use the tag JScript whenever applicable. At this time, JScript is implemented for scripting with events only, not as a language specification for the SCRIPT tag.

Summary

JavaScript is a very effective tool, and a relatively simple method for adding interactive content to a web page. With version 3.0 of Internet Explorer, using JavaScript is viable for both of the most popular browsers in use. However, developersneeds to be aware of the differences between Netscape Navigator and Microsoft Internet Explorer and should test thoroughly with both before posting the page to their site.

Categories
JavaScript

Netscape Navigator’s JavaScript 1.1 vs Microsoft Internet Explorer’s JScript

Originally published at Digital Cats, now archived at the Wayback Machine

Prior to Netscape implementing JavaScript in Netscape Navigator, web developers had few tools to create interactive content for their web pages. Now this scripting language gives developers the ability to do things such as check form contents, communicate with the user based on their actions, and modify the web page dynamically without the web page being re-loaded and without the use of Java, plug-ins or ActiveX controls.

Unfortunately, JavaScript was not usable by any other browser until Microsoft released Internet Explorer (IE) 3.0. With this release web developers could deliver interactive content that would at least work with the two most widely used browsers. Or could they?

On the surface, the JavaScript supported by both companies is identical. They both provide the same conditional control statements, have defined objects such as window or document,and can be used directly in HTML documents. They both support events based on user actions and support functions in a similar manner. However, this article will demonstrate that though the languages may look the same on the surface, there are differences that can trip the unwary developer.

JavaScript Objects

To understand the differences between the two implementations of JavaScript you must examine the objects both support. As an example, with Navigator 3.0 Netscape provides a new object image which is an array (defined as images that contains the images in the document currently loaded. This object allows the developer to change the images of a document without re-loading the document or using Java or other technique. With this capability the developer can write the following JavaScript code section without error:


sSelected = "http://www.some.com/some.gif"
document.images[iIndex].src = sSelected

This code will change the src property of the image that is contained in the array at the index given in the variable iIndex. If this variable contained the value 2, the 3rd image as loaded in the document (the array indices begin at 0) would be changed to the image located in the given URL. An example using images can be found here.

Running the same example with Internet Explorer will result in a alert message that states that “‘images’ is not an object”.

Other examples of objects that are defined for Netscape Navigator but not for Microsoft Internet Explorer are:

  • The Area object, which is an array of links for an image map that allows the developer to capture certain events for the image map that can be used to provide additional information to the user. With this, the developer can capture a mouseOver event to write out information about the link in the status bar.
  • The FileUpload object which provides a text like control and a button marked with “Browse” that will allow a reader to enter a file name. The JavaScript can then access the name of the file.
  • The Function object which allows the developer to define and assign a function to a variable which can then be assigned to an event.
  • The mimeTypes Array of supported MIME types.
  • The option object which is an array of the options implemented for SELECT and which allows the developer to change the text of the option at runtime
  • The applet object, which is an array of Applets in the document (read-only)
  • The plugin object, which is an array called embeds that contains the plug-ins contained in the document (read-only)
  • The plugins array, which is an array of plug-ins currently installed in the client browser

At this time there are no JavaScript or JScript objects defined for Internet Explorer that are also not defined for Netscape. However, as JScript is an implementation script for IE and Microsoft has defined their own IE scripting model, this could change in the future.

JavaScript Object Behavior and Ownership

Internet Explorer may not have additional objects but it has defined a different hierarchy and ownership for some of the objects that are used by both it and Navigator. All objects are contained within the window object in the IE scripting model, which can be viewed here, but not all objects are owned by window with the Navigator model, which can be viewed with the JavaScript Authoring Guide. The object Navigator, which is the object that stores information about the browser currently being used, is an example of an owned object by window in IE but not in Navigator.

This will not present an incompatibility problem between the two browsers as the developer will usually not preface the object with the term “window” as the following code demonstrates:


<FORM NAME="form1">
<input type=button value='press' onClick="alert(navigator.appName)">
</FORM>

The above code will work with both browsers.

The differences between the ownership can become a problem when an object is owned by different levels of objects. An example is the history object, which is owned by the window object in IE, but by the document object in Navigator. When used in the current window and document, the object will work the same as the following code will demonstrate:


<FORM NAME="form1">
<input type=button value='press' onClick="history.back()">
</FORM>

The reason the same code can work for both is that window is assumed for both IE and Netscape and document is assumed for Navigator, at least in this instance because history is also an object in its own right. In the case of a document being opened as part of a frame, the differences then become noticeable. The following code will work when the document is opened as a frame in IE, but will not work in Navigator:


<body>
<script>
function clicked() {
history.back()
}
</script>
<FORM NAME="form1">
<input type=button value='press' onClick="clicked()">
</FORM>
</body>

Clicking on the button from the code above will work for IE. The previous document in the History list will be opened, but the same code will not work for Navigator. Clicking on the button will result in neither a change of document nor an error. Prefacing the history object with parent will enable this code to work with both browsers.

JavaScript Properties

Even when IE and Navigator share a common object and a common object ownership, they can differ on the properties for an object. An example is the document object. The properties for both implementations are the same except for an URL property for the Navigator implementation and a location property for the IE implementation. However, if you examine both properties, they are identical! Both contain the URL of the document. Both are read-only. The following code will work with Navigator, but results in an empty Alert message box for IE:


<FORM NAME="form1">
<input type=button value='press' onClick="alert(document.URL)">
</FORM>

According to Microsoft documentation, the equivalent for IE would be to use document.location.href. However, though this does not result in an error, it also results in an empty alert box. The following code achieves the desired results and, happily, works in both browsers:


<FORM NAME="form1">
<input type=button value='press' onClick="alert(location.href)">
</FORM>

The above example does demonstrate another area of caution when using the JavaScript language: this language is unstable in both environments and is changing continuously. Don’t assume something will work because the documentation states it will, and don’t assume it will work the same on all operating systems. Both browsers can have different behaviors across different operating systems, sometimes because of operating system differences and sometimes because of bugs that were missed during testing on that specific OS.

JavaScript Methods and Events

A web developer can find ways of working around differences in objects and properties, but working around differences in methods may not be so easy. When we develop we expect a certain behavior to result when we call a specific function and pass to it certain parameters. With Microsoft Internet Explorer and Netscape Navigator, the best case scenario is that we can use a pre-defined object method with both browsers and have the same result. The worst case scenario is that the method works with both browsers, but the result is different.

An example of the best case scenario is to use JavaScript to validate form field contents which have changed or to use these contents to calculate a value used elsewhere. Calling a JavaScript function from the onChange event to process the changed contents as demonstrated below will work with both browsers:


<!--- Form fields
<p>Item Quantity: <INPUT TYPE="text" Name="qty">
Item Cost: <INPUT TYPE="text" Name="cost"
                onChange="NewCost()">
Total Cost: <INPUT TYPE="text" Name="total" Value=0>
…
<!--- Function
<SCRIPT LANGUAGE="javascript">
<!--- hide script from old browsers

// NewCost will
// calculate cost of qty and item
function NewCost() {
        var iCost = parseFloat(document.Item.cost.value)
        var iQty = parseInt(document.Item.qty.value)

        var iTotal = iCost * iQty
        document.Item.total.value = iTotal
        }

The above will work as expected with both IE and Navigator. When the user enters a quantity and a cost, the onChange event will fire for the cost field and a JavaScript function called NewCost() will be called. This function will call two built-in JavaScript functions, parseFloat() and parseInt(), to access and convert the form field values. These will then be used to compute a total which is placed in the total field.

So far so good. Another JavaScript function in the web page will be processed when the user presses the submit button. This pre-defined button style will normally submit the form. The developer can capture the submission and perform validation on the fields. Coding this for Navigator would look like the following:


<FORM NAME="Item"
        ACTION="some.cgi" onSubmit="return SendOrder()">
…
<!--- Function
// submit order
function SendOrder() {

        // validate data
        if (document.Item.Name.value == "") {
                alert("You must enter your name")
                return false
                }
        return true
        }

Capturing the onSubmit event will allow the developer to call a function to process the form fields. If they choose, they can perform validation in this function. If the validation fails, say the user did not provide a name, the function notifies the reader and returns false, preventing the form from being submitted. If the user did provide a name, the function would return true, and the form would be submitted.

Following the documentation that can be found at the Microsoft site, the developer would expect something like this to work for IE as well as Navigator. It does, to a point.

With IE the onSubmit event is captured and the SendOrder() function is called. If the user did not enter a name value, an alert would occur. The behavior is the same for both browsers at this point. However, if the user does provide a value, Navigator would then submit the form and a follow-up form would be displayed. This does NOT occur with IE IF you are testing the page locally, probably due to a bug missed during the testing. It does work if you run the web page documents through a web server.

However, without knowing that the difference between the two results was a matter of document location rather than document coding the web page developer could have spent considerable time trying to get the same behavior for both browsers.

Aside from the differences already noted, the browsers may process code in a funtionally identical manner and yet perform quite differently. This can be demonstrated with another popular use of JavaScript which is to open a secondary window for some purpose and to maintain communication between the two windows. This is widely used by Netscape for their tutorials.

Both browsers support a property for the window object called opener. This property can be used to contain a reference to the window that opened the secondary window.

The following code demonstrates using JavaScript to open a secondary window and to set the opener property to the original window:


<HTML>
<HEAD><TITLE> Original Window </TITLE>
<SCRIPT LANGUAGE="JavaScript">
<!--- hide script from old browsers
// OpenSecondary will open a second window
//
function OpenSecond(iType, sMessage) {
        // open window
        newWindow=window.open("second.htm","",
                "toolbar=no,directories=no,width=500,height=300")
        // modify the new windows opener value to
        // point to this window
        if (newWindow != null && newWindow.opener == null)
                newWindow.opener=window

        }
// end hiding from old browsers -->
</SCRIPT>
</HEAD>
<BODY>
<H1> Open a new Window and get information</H1>

<FORM NAME="CallWindow">
<p>Click to open Window:
<p>
<INPUT TYPE="button" NAME="OpenWin" VALUE="Click Here"
        onClick="OpenSecond()">
<p>
</FORM>
</BODY>
</HTML>

The above HTML and JavaScript creates a simple document with one button. Pressing the button opens a new window (creates a new instance of the browser) that does not have a toolbar or directories and is set to a certain width and height. The HTML source document that is opened into this new window is “second.htm”.

The HTML and JavaScript in the secondary window is shown below:


<HTML>
<HEAD><TITLE> Information</TITLE>

<SCRIPT LANGUAGE="JavaScript">
<!--- hide script from old browsers
// SetInformation
// function will get input values
// and set to calling window
function SetInformation() {
        opener.document.open()
        opener.document.write("<BODY>")
        opener.document.write("<H1> Return from Secondary</h1>")
        opener.document.write("</BODY>")
        opener.document.close()
        opener.document.bgColor="#ff0000"
        window.close()
        }
// end hiding from old browsers -->
</SCRIPT>
</HEAD>
<BODY>
<p><form>
Click on the button:<p>
<INPUT type="button" Value="Click on Me"
     onClick="SetInformation()">
</CENTER>
</FORM>
</BODY>
</HTML>

This code will display a button labeled “Click on Me”. Pressing this button will result in the document page for the original window being modified to display the words “Return from Secondary”. The JavaScript will also change the background color of the original document and then will close the secondary window. When run in Navigator, the sample behaves as expected. Not so, however, with IE.

First, when you open the secondary window in IE you will notice that the document in the original window seems to blank out for a moment. In addition, the secondary window opens at the top left hand side of the desktop with IE but opens directly over the original window with Navigator, no matter where that original window is.

When you press the button that modifies the original document, IE does modify the document with the new header, as Navigator does, and the background on the original document will change briefly. However, when the secondary window is closed the background color of the original document returns to the original color!

What is worse is that running this sample for a few times with IE will cause the browser to crash! How soon it will crash seems to suggest that resources are not being freed, or are being freed incorrectly. Whatever the cause, this behavior should make a developer feel cautious about opening up a secondary window within IE.

Solutions to working with both Internet Explorer and Navigator

JavaScript is a useful tool for creating interactive content without using Java or some other technique. As we have seen, problems arise out of the incompatibility between Navigator and IE. What are ways to avoid these problems?

  • Code for one browser only. This is not really a viable solution. While Netscape Navigator is the most popular browser in use today, Microsoft Internet Explorer is gaining quite a following. Using Navigator-only JavaScript that will limit your web page’s audience.
  • Code only to the least common denominator. By limiting the JavaScript to that which works for both Navigator and IE, developers will have access to most of the functionality they need. However, with this approach developers will need to be aware of the gotchas that have been discussed in this article. In other words, the developer has to test with both browsers; the tests will have to occur via the web server as well as run locally; the tests should be repeated several times to ensure that no adverse effects show up over time; the code should be tested with all possible environments.
  • Code for each browser within the same page. This is actually my favorite approach though it will require more effort by the developer. Both browsers will process JavaScript labeled as <SCRIPT LANGUAGE=”javascript”>, however only Navigator will process script labeled as <SCRIPT LANGUAGE=”javascript1.1″>. With this approach, the developer can place JavaScript common to both browsers in a SCRIPT tag labeled with “javascript” and Navigator specific code in a SCRIPT tag labeled with “javascript1.1”. To add in IE specific code, the developer would probably want to use VBScript code or use the tag JScript whenever applicable. At this time, JScript is implemented for scripting with events only, not as a language specification for the SCRIPT tag.

Summary

JavaScript is a very effective tool, and a relatively simple method for adding interactive content to a web page. With version 3.0 of Internet Explorer, using JavaScript is viable for both of the most popular browsers in use. However, developersneeds to be aware of the differences between Netscape Navigator and Microsoft Internet Explorer and should test thoroughly with both before posting the page to their site.

Categories
JavaScript Technology

Using Dynamic HTML to create an animated menubar

Originally published in Netscape World, now archived at the Wayback Machine

Microsoft and Netscape decided to use two different techniques for Dynamic HTML. Microsoft bases its approach on exposing CSS1 (Cascading Style Sheets) attributes to script, with a little help from some interesting new built-in, lightweight, and windowless ActiveX controls. Netscape bases much of its approach on the new LAYER tag.

At first glance, the approaches seem incompatible — using one browser’s techniques will not work with the other. However, you can use both browsers’ techniques within the same page and generate the exact same result.

In this article, I create an animated menu bar using a combination of CSS1 style sheets, the PATH ActiveX control, and dynamically modifying HTML elements to work with IE 4.0. I create the exact same effect using CSS1 style sheets and the LAYER tag for Navigator 4.0. Note, though, that both IE 4.0 and Navigator 4.0 are works in progress, and this example may need to be modified, slightly, for future versions of either product.

Creating style sheetsThe first section of the example page is the CSS1 style sheet settings. Both IE 4.0 and Navigator 4.0 process these style sheets, though Navigator does not seem to like setting images using the IMG tag at this time.

This example image uses headers for the text-based portion of a menu bar. To create the effect I want, I don’t want the standard underline that occurs with hypertext links, and I do want to modify the font size and color. As I don’t want either of these changes to impact on the rest of the document, I use the cascading effect of CSS1 to apply these changes only to links contained within <H2> header tags:

h2 A { text-decoration: none; color: gold } 
h2 A:link { color: gold } 
h2 A:visited { color: gold }

Next, I create the style sheet definitions for the menu images, for use with IE 4.0 only. I use absolute positioning to place the images exactly where I want on the page, and use the visibility property to hide the images when the page is first opened:

#menu1 { position: absolute; left: 0; top: 0; 
	visibility: hidden}
#menu2 { position: absolute; left: 142; top: 0; 
	visibility: hidden}
#menu3 { position: absolute; left: 284; top: 0; 
	visibility: hidden}
#menu4 { position: absolute; left: 192; top: 0; 
	visibility: hidden}
#menu5 { position: absolute; left: 142; top: 192;
	visibility: hidden }
#menu6 { position: absolute; left: 284; top: 192; 
	visibility: hidden}

The final part of the CSS1 style sheet definition creates the text-based menu components of the menu bar. These show as soon as the page is opened, and if the Web page reader does not want to wait for the images, or has image downloading turned off, they can access the links via the text menu. The size of the area for the menu text item should be large enough to contain the complete text, otherwise odd behavior will result with Internet Explorer: It does not display the text correctly when you click on a text-based menu item. Another text-based style sheet rule is provided for a message that is displayed while the images are loading. Whenever you create content that may be invisible or not displayed for a time, provide some kind of feedback to the user about what is happening:

This is the final section of the CSS style sheet definitions.

Adding images to a Web pageThe next section in the example page is the scripting, but I will talk about that a bit later. For now, I will add the images to the Web page using two different techniques, one for IE 4.0, and one for Navigator 4.0. IE 4.0 uses the style sheet settings defined for the images, and references the appropriate definition by using the identifier of the style sheet rule. The Navigator technique is to embed the images within layers that are hidden when the page first loads. IE 4.0 ignores the LAYER tag, and Navigator ignores the image style sheet rules:

Note that a hypertext link reference is applied to the image, and the border is set to 0. As the image style sheet rules seem to be ignored by Navigator, important image information such as widthheight, and border are specified within the image tag.

Next, the text objects are added to the menu bar. This includes a text-based alternative that labels each image when it is displayed, or can be accessed directly if the image is not displayed. This also includes a message stating that the images for the menu bar are being loaded:

The “waiting…” text is placed within a LAYER tag as I need to add script to modify it later, and only layer-based elements can be modified with Navigator at this time.

The final objects to add to the page are six ActiveX PATH objects, to control the menu bar animations for IE 4.0. A path object can be used to specify both X and Y coordinates at specific tick marks and moves the visual object associated with the control along that path. Two of the parameters for the control are the X path coordinates and the Y path coordinates. Another parameter could also control the timer, but I want to synchronize my image movement, so I use a different script-based approach later:

Notice that the X, Y coordinates for each path object are different, but all of them have the same number of timing ticks, which is the first parameter given in each of the coordinate pairings. The tick timings given are in microseconds.

The PATH ActiveX controls are the last elements placed into the page. Next comes the fun part, animating the menu bar.

Adding the script to animate the menu barThe animation is started when the page loads by trapping the onLoad event for the document. This calls a function called cycle. This function is implemented in both VBScript and JavaScript, and the appropriate browser picks the appropriate implementation, with Microsoft grabbing the VBscript version, Navigator grabbing the JavaScript version.

The first script controls the menu bar for IE 4.0. This is written entirely in VBScript, though JavaScript could be used if browser differences are handled correctly. The cycle function sets the Target properties of the path objects to the style sheet rules of the menu bar images. This associates each path control with its visual object. Next, the images are set to be visible, and the “waiting..” text is hidden.

The Play method for each path control is called, beginning the animation process, though no movement occurs yet. Why? No movement occurs because no timing mechanism has been associated with each control. The timing is handled by using the setTimeout function and calling a second subroutine that handles the image animation. The complete text of the cycle subroutine is here:

I use my own timer to synchronize the images, a technique that Microsoft recommends when using more than one PATH control on the same Web page.

The MoveIEObjects subroutine calls the Tick method for each of the path controls, moving each of the objects to the next coordinate defined for the specific control. It issues another setTimeout function call to continue the animation process, after first testing to see if the last movement of the path has occurred (the last of the ticks, of which there are eight for this particular demonstration). Note that I did not necessarily have to test the tick movement because after the path has completely played, it no longer moves unless it is rewound. However, I want to make sure the timer is not still operating. The complete text of MoveIEObjects is given next:

Next, I add the JavaScript to control the animation for Navigator 4.0. The cycle function for Navigator is similar to that for IE 4.0, except that I need to create my own arrays of X and Y coordinates. These arrays, in turn, are set to hold other arrays holding the actual coordinates. After the arrays are created, the images are displayed and the timer is started, as seen next:

The final script is for the MoveObjects function for Navigator. The LAYER tag method moveTo is used to move each of the images to the new coordinate for this timer event. Note that the timer values are set to be much larger than the ones set for IE 4.0 as the PATH control does run a bit slower than using the LAYER tag approach, and I wanted both effects to be as similar as possible. MoveObjects can be seen next:

Note that resizing Navigator can misalign the images. Netscape recommends a blank document.write statement in JavaScript to compensate for this type of problem, but this does not work for this example. I will continue to investigate this and will post a fix to my Web site when one appears. In the meantime, if you resize the Web page you need to reload the example. No problem occurs when you resize IE.

That’s it for the scripting. You can test the example yourself if you are using either IE 4.0 or Netscape 4 (this script will not work on earlier browsers). View the complete source by using the appropriate “View Source” option of your browser.

 

Categories
Critters Writing

A Tale of 2 Monsters Part 4: Nessie, the Loch Ness Monster

Recovered from the Wayback Machine.

There are many creatures that live in our myths and our minds, but the most famous is probably Scotland’s Nessie, or the Loch Ness Monster. But first, let me digress and talk about another lake monster, one a little closer to home: Lake Champlain’s Champ.

We used to live on a farm on the shore of Lake Champlain in Vermont. You might know Lake Champlain as home of, among other things, Champ, the Lake Champlain Monster.

Between our home and our next door neighbor’s home was a large and dense stand of old trees and brush.

One night, and I’ll never forget it, I and my husband listened to the sound of crashing from the woods as huge limbs were torn from trees at least 30 feet in height. No other sound penetrated the night, not a breath of wind, not a yip from one of the local foxes, no cars, no trucks, nothing — just the sound of smashed brush and crashing trees.

The sound continued long into the night and the next morning, the stand of trees was decimated.

 

Yes, I did live on the Lake Champlain islands in 1997-1998, and the incident I mentioned did occur — during the great ice storm of January, 1998, when the weight of the ice decimated many of the trees on the island.

Now, fess up — I bet you thought I was going to describe an incident involving Champ, the Lake Champlain monster, didn’t you? However, it is just acts of nature such as this that can sometimes generate tales of monsters, especially when one is searching for these same monsters.

However, sometimes, there just isn’t an explanation for what someone sees, or hears, or believes. It is then that some monsters enter the ranks of the legendary, monsters such as Nessie, the Loch Ness Monster.

Nessie: Origins of a Legend

 

During the Twentieth century, several photos of Nessie have been published, and in one very well known case, been proven to be a forgery. Numerous eye witness accounts of Nessie have been chronicled, and drawings made of eye witness accounts, such as those shown in this page, but there has never actual physical verification that Nessie exists.

Nessie’s beginnings, though, go back to an earlier time. According to folk lore, and a PBS Nova special on the monster2, the Scottish Highlands has had legends of a strange water-based creature since the Romans first entered the territory over 1500 years ago.

The Romans met up with the Picts in Scotland. The Picts were a pretty feisty group of people that liked to among other things, carve realistic images of animals, including the water-based creature mentioned in the last paragraph. Though it isn’t that unusual for primitive tribes to create stylized images of animals, the Picts concentrated only on images of real world animals. Well, if this was true, what was the water-based beast they represented? It is from simple roots that legends can spring.

The first “modern recording” of the Loch Ness Monster was made by a Saint Columbia, who wrote about saving a swimming man from a large creature by invoking the name of God, an incident occurring in the 500’s.

Of course, it wasn’t that unusual for the early Christians to weave themselves and their beliefs into folk legends and practices of areas they hoped to convert.

Nessie Sightings

Though Nessie achieved most of its fame based on sightings in the 1900’s, there are also eye witness accounts of seeing a the creature of Loch Ness in the 17th through the 19th century3, where it was also known as a water-kelpie or water horse, though without the frequency of this century’s sightings.

However, it was in 1933 that a sighting occurred that put Loch Ness on the map, and Nessie in the news. In 1933, a Mr. Spicer and his wife were driving by Loch Ness when they saw a creature crossing the road, a creature unlike any they had ever seen before. They described the beast as having a long neck followed a large, ponderous body, and they watched it until it left the road and entered the water.

The Spicer sighting was only the first of a plethora of sightings of Nessie, and it seemed the world just couldn’t get its fill of hearing stories about this mythical water beast. According to the Legend of Nessie site6, over 32 sightings occurred in the 1930’s alone.

What accounts for such a sudden surge in Nessie sightings? Well, one main reason is that roads were built around the Loch, increasing exposure of the lake to many more people. Another probable cause is that the idea of Nessie was planted in people’s minds. Where before a person may have seen a stick floating in the water, they may now see a tail. Where before a wave is only a natural movement of water, it now becomes the wake of a creature hidden from sight.

Perhaps it is also a matter a person seeing something that they can’t explain and where before they dismissed the sight as a stick or the natural movement of water, now they consider another source for what they are seeing: Nessie5.

The larger number of sightings of Nessie continued until the advent of World War II turned people’s minds to other monsters, in other places.

Century’s Greatest Hoax?

Many if not most of the Loch Ness sightings are from folks reporting what they genuinely see, and genuinely believe they are seeing. However, you can’t have the interest in something such as Nessie without attracting hoaxes, and the Loch Ness Monster had its share.

One of the first hoaxes was the finding of large and unusual footprints, discovered by a big game hunter of the time, Marmaduke Wetherell. He found large footprints, freshly made, in December of 1933, made casts of the prints and sent them off to the Natural Museum in London.

Well, there was a whole lot of excitement about the first physical “evidence” of the Loch Ness Monster. However, the excitement didn’t last long: the January following the finding of the prints, scientists announced that not only were the prints not that of an unknown beast, they were the prints of a hippopotamus foot, and a stuffed hippo foot, at that.

The footprint hoax definitely cooled interest in the Loch, at least from the basis of serious study. But it wasn’t the most famous hoax that came from Loch Ness. This dubious honor belongs to a photo taken by a Dr. Robert Kenneth Wilson in 1934.

This photo shows what looks like a sea serpent with a small head on a long neck, and resembling known images of a prehistoric dinosaur known as the plesiosaur.

The photo was examined and was determined to be genuine, not the result of camera trickery, and investigation of the creature in comparison to the wave sizes put the creature’s neck to be a couple of feet in length. All well and good, except that the “creature” in the photo was nothing more than a fake serpent neck attached to the back of a toy submarine.

How was the information about the faking of the photo discovered? One of the people that was involved with the hoax made a death bed confession in 1994 to that effect. And the person who was responsible for the hoax? None other than our friend, Marmaduke Wetherell.

After the debacle of the fake serpent footprint, Wetherell contacted his stepson, Christian Spurling, about creating the fake monster and setting up the hoax. With the help of Spurling, Wetherell’s son Ian, and two friends, Colonel Wilson and Maurice Chambers. the latter with Dr. Wilson at the famous sighting, the hoax was on.

Why did Wetherell do this? A possible reason could be revenge after the embarrassment he received because of the fake footprint. However, once the photo was published by the Daily Mail, and once the world reacted so strongly to the photo, all involved probably felt it wouldn’t be too good an idea to come forward with a confession about what they had done, even if this was the intention.

Loch Ness researcher Allister Boyd helped to uncover the hoax when he had discovered a story published years before by Ian Wetherell confessing to the hoax—a story that had been originally ignored. Boyd and fellow researcher David Martin contacted the last living representative of the hoax, Spurling, who confessed that he had helped fake the photo10.

Despite the two uncovered hoaxes, folks still believe in Nessie and every year people go to considerable lengths to try to find physical evidence of the Loch Ness Monster.

Current Research Efforts and Findings

In the 1970’s, Dr. Robert Rines from the Academy of Applied Science in Boston, Massachusetts, began to use sonar to attempt to obtain images of the Loch Ness Monster. He and his crew did obtain images of what they say are the flipper and head and upper body of a creature that they believe can only be the Loch Ness Monster11.

In addition to the work performed by Dr. Rines, other folks have dedicated their lives to finding physical proof of Nessie, folks such as Tim Dinsdale, who literally spent his life looking for proof of Nessie.

Another research project is being conducted by Dan Scott Taylor and is known as the Nessa Project12. The Nessa Project is based on the search for Nessie using a small 4-person submarine. Taylor used a smaller submarine, the Viperfish, to search for Nessie in the 1960’s—though without success and with many mechanical problems (though he believes that he was turned around on the bottom once by Nessie passing). Taylor hopes to try again as soon as he has funding for his new, homemade submarine, the “Nessa”.

Not all those who research the Loch Ness Monster are seeking actual proof of the existence of the creature. For instance, as mentioned earlier, Allister Boyd helped to debunk the Nessie photo hoax, even though he says he has witnessed an actual appearance of Nessie and seeks proof of the monster’s existence. Another more cautious researcher is Richard Carter, who also investigates the existence of Nessie, but also investigates the “evidence” of sightings, to see which is genuine, which hopeful thinking and bad camera shots13.

Of the research against the existence of Nessie, two areas that form the focus of this research is that the lake could not support enough of the Loch Ness creatures to form a viable population without much more evidence of their existence; and that there is not enough food within the lake to support any such population of larger creatures. Another scientific fact that makes the Loch a difficult home for a creature that could possibly be the last remnant of the dinosaur age, the plesiosaur, is that Loch Ness was a glacier until a scant 10,000 years ago — long after the dinosaurs were extinct14.

However, the searches still continue, the hunt is still on.

A Tale of Two Monsters: Summary

The Tale of Two Monsters takes a look at two legendary beasts, one proven to physically exist, the other still considered myth. We’ve covered how legends can arise, and how these same legends have influenced our currently popular form of storytelling: the movies.

The series also looked at cryptozoology or the study of animals without physical verification and that are discovered first through legends, tales, and folklore. In the last two sections of the series, we got a chance to meet the two stars of the series: the giant squid and Nessie, the Loch Ness Monster.

You may be asking whether I personally believe in the existence of the Loch Ness Monster. I would hope that I’m an open minded person, but the existence of the giant squid leads me to doubt the existence of the Loch Ness Monster, and it’s this relationship that tied these two creatures together for me and led to the articles you are reading.

As you saw in Part 3 of this article, the giant squid is a large creature, most likely up to a maximum of 60 feet in length, inhabiting the deepest depths of the oceans. To approach the surface is basically a death sentence for these creatures, yet we have physical evidence of the giant squid, including several well preserved examples in museums such as the Smithsonian.

Consider this: the Loch Ness Monster is not as large as the giant squid, but is much bulkier and would be much heavier. It’s supposedly located in a body of water that is much, much, much smaller than the ocean. The Loch Ness monster is also an air breather, meaning that it must surface to breath, unlike the giant squid—to reiterate, surfacing for the giant squid is death. Yet, we have physical evidence of the giant squid, and nothing more than faint, fuzzy images and highly scattered (yes, scattered) eye witness accounts of Nessie. I can’t help but believe that we would have physical evidence, hard evidence, of Nessie by now if it existed.

Regardless of my personal viewpoint, I respect the beliefs of others and I respect the beliefs of those who feel that Nessie does exist. There is no harm in this belief, no one suffers because of it. Something such as the Skeptic’s Dictionary can scorn this belief15, but those who tear down beliefs with such joy are not scientists—they are most likely nothing more than frustrated believers themselves who had their own beliefs shattered and now obtain considerable satisfaction is destroying the beliefs of others.

I started Part 4 of this article with a description of an incident that happened when I lived on the shores of Lake Champlain. I talked about how “normal” events can achieve significance when they occur out of context, or when our expectations are set— I believe in something therefore when something unexplained happens, the unexplained takes shape rather than staying as something unexplained, and therefore easily dismissed.

Scientifically, I may doubt the existence of Champ16, the Lake Champlain equivalent of Nessie, yet there is a part of me that wonders…

This is the part of me that peers into the darkness when I cross the lake on the ferry. This is the part of me that turns towards the lake when I hear an odd sound in the pattern of the waves. This is the part of me that looks to the lake during the full moon, with just a slight bit of expectation and curiosity. Not a lot, just a slight bit. This is the part of me that gives me soul.

Categories
Critters Writing

A Tale of 2 Monsters Part 3: Architeuthis Dux

Recovered from the Wayback Machine.

 


Below the thunders of the upper deep;
Far, far beneath in the abysmal sea,
His ancient, dreamless, uninvaded sleep,
The Kraken sleepeth: faintest sunlights flee
Above his shadowy sides: above him swell
Huge sponges of millennial growth and height;
And far away into the sickly light,
From many a wondrous grot and secret cell
Unnumber'd and enormous polypi
Winnow with giant arms the slumbering green,
There hath he lain for ages and will lie
Battening upon huge seaworms in his sleep,
Until the latter fire shall heat the deep;
Then once by men and angels to be seen,
In roaring he shall rise and on the surface die.
The Kraken — Albert, Lord Tennyson

The Giant Squid

The next time you sink your teeth into some calimari think of this: The giant squid has been measured to a length of 60 feet, and weighs in the neighborhood of between 1 and 2 tons. It has eight arms, each lined with two rows of suckers. The giant squid also has the largest eyes of any known creature, over a foot in diameter.

If the giant squid is like its smaller cousins, it is a predator. To make the giant squid an ideal predator, its suckers are ringed with a hard, jagged edge, resembling teeth, in order to better enable the squid to hold onto its prey. Additionally, two longer tentacles are also used to help move the prey to the large, sharp parrot-like beak.

Needless to say, you will not sink your teeth into this creature without a fight.

The Stuff of Legends

I looked in my turn, and could not repress a gesture of disgust. Before my eyes was a horrible monster worthy to figure in the legends of the marvelous. It was an immense cuttlefish, being eight yards long. It swam crossways in the direction of the Nautilus with great speed, watching us with its enormous staring green eyes.

So says the Naturalist, in the Jules Vern classic 20,000 Leagues Under the Sea 18. Though this book is a work of fiction, the squid encounter that Vern wrote about was based on fact, or at least a story that Vern heard about at the time. The story states that a French naval ship was attacked by a giant squid in 18611.

Since earliest times, there have been legends of sea serpents and large, many-armed creatures attacking boats. One of the fiercest creatures was the legendary beast known as the Kraken, discussed in Part 1 of Tale of Two Monsters.

Now, modern belief is that the kraken was a giant squid, and that the size of the creature has grown through numerous re-tellings of ancient stories; from creatures of 50 feet to creatures the size of islands.

A Norwegian Bishop, one Erik Ludvigsen Pontoppidan, wrote in his journals about the kraken and mentions the size of the creature as being one and one-half miles long 3! More recently, another eyewitness account of the size of the giant squid is given by an A.G. Starkey, who was stationed on a British trawler in World War. Starkey tells of being on deck in the evening when he notices a light in the water next to the boat. As he tells it, “As I gazed, fascinated, a circle of green light glowed in my area of illumination. This green unwinking orb I suddenly realized was an eye. The surface of the water undulated with some strange disturbance. Gradually I realized that I was gazing at almost point-black range at a huge squid.”

According to the Starkey account, he walked along the boat, measuring the giant squid and realized that it was as long as the boat he was on. It is at this point that accounts may differ. According to a Discovery Channel special on the Giant Squid (telecast July 31, at 8:00 pm in a show titled “X Creatures”), the boat Starkey was on measured 60 feet. According to the account given in the Museum of Unnatural Mystery4, where I pulled the quote, the boat measured 175 feet!

Eyewitness accounts of the size of the giant squid are matched by tales of squid behavior, specifically stories of squids attacking ships.

As said earlier, Jules Verne based his squid fight in 20,000 Leagues Under the Sea on an eyewitness account of a giant squid attacking a French naval ship1. Another account of a giant squid attacking a ship is given in the logs of the Brunswick, a Norwegian Trawler. In the logs an account is given of a giant squid attacking this large ship three different times, before the squid finally slid into the ship’s propellers and was killed.

A third account tells of nuclear submarine losing the use of its sonar equipment on the ship’s maiden voyage. When the submarine returned to port, the Navy found that the covering on the Sonar had been torn lose and that hooks remained in the material, hooks from a giant squid.

Other accounts tell of giant squid grabbing men from the waters as ships were sank in World War I and II, and also of giant squid attacking small fishing boats. Two South African lighthouse workers reported in 1966 about seeing a giant squid wrapped around a baby whale, in a ferocious fight, with the baby whale surfacing and being pulled back under before it finally stopped rising to the surface4

So, are there giant squid lurking off our coasts that reach a size of 150 feet and that pull folks off boats? Well, behind every tale, there is a seed of truth, and now its time to take a look at what we do know about the giant squid.

What We Think We Know

Amid rumor and scant eyewitness accounts, we have little knowledge of the giant squid and its behavior. Giant squid have washed up on shore sporadically so we have had a chance to examine dead specimens. We also know that the giant squid forms part of the diet for toothed whales such as the sperm whale. Outside of that, though, we have little knowledge of these of the largest known invertebrate. We have never successfully viewed the giant squid in its natural environment, and we have never had a chance to examine a living specimen. But what we do know makes this an incredibly interesting creature.

First of all, when discussing giant squid, most folks are discussing the squid known as Architeuthis Dux. There are other large species of squid, some of which have been seen in the wild. For instance, the Navy provides an audio account of an encounter between a robotic research submersible and a variety of squid known as Moroteuthis. In the account, the squid was six feet in length5. Compared to its larger cousin, though, Moroteuthis is pretty small: Architeuthis Dux, or the Giant Squid by its popular name, has been measured at close to 60 feet in length.

The first recorded physical record of the giant squid was made by a Reverend Moses Harvey in Newfoundland, based on a dead giant squid that had been caught by local fishermen. Dead giant squid had been washed up on shore before, but this was the first time a person had taken samples of the squid, and made scientific observations of the creature — due to the foresight demonstrated by Rev. Harvey as he sent the creature to Yale University for study6.

Since that time, more creatures have been washed on shore or been pulled up, dead, in fishing nets. However, no live giant squid has been captured, nor has one been seen in its native element. Most of what is known about giant squid has been derived from these specimens and from the remains of giant squid specimens found in the stomachs of whales, primarily sperm whales.

Consider the giant squid: the largest size of the giant squid is between 60-70 feet as determined from pieces of the creatures that have been found7. It should weigh in at close to 1 to 2 tons. In addition to its large size, the giant squid also has the largest eyes in the animal kingdom, with each larger than your typical dinner plate!

The giant squid’s territory is in the depths of the ocean, up to 3000 feet below the surface of the ocean, in a world that is as foreign and deadly to us as is the vacuum of space8. It, as with other squid, does not live on the ocean floor, as an octopus does, but lives, instead, between the surface and the bottom, a state easily maintained by its natural buoyancy.

In addition to its size and habitat, the giant squid’s physical makeup also differs from the squid normally consumed by people: instead of sodium chloride in its system, biologists have found ammonium chloride. Snacking on Architeuthis would be similar to sucking on a bottle of your favorite ammonia floor cleaner, without the lemon scent. Nummy.

Other than these small differences, the giant squid is similar to other species of squid. It has a mantle, which is where its internal organs are found. Along the length of the mantle is a funnel, used for expelling waste, water, and for locomotion10 — the squid ejects water through the funnel to push it along the water.

The giant squid has eight arms, each containing several suckers; to make the suckers even more interesting, the edges of the suckers have a jagged set of “teeth”11 to help the squid grasp prey.

The giant squid also has two longer feeding tentacles used to push food into the squid’s mouth, which resembles a parrot’s beak. A large parrot. A large beak. It also can squirt ink to confuse predators, matching its smaller cousins capability 12.

Other than these facts about the squid’s physical makeup, little is known about how the squid acts in its environment, a void that scientists have been trying to fill for the last several years.

In Search of…

There have been numerous attempts to study giant squid in its natural environment. Two expeditions have been sent to Kaikoura Canyon, off of New Zealand, the first in 199713, and the second of which occurred in February and March of 199914. Both of these expeditions were under the leadership of Dr. Clyde Roper from the Smithsonian Museum, probably the world’s leading expert on the giant squid. He is also one of the few people to actually taste a sample of giant squid, and it is from his reaction that I pull my “ammonia without the lemon scent” taste description.

The Kairkoura Canyon is considered a favorable spot for finding the giant squid because several specimens have been found by fishermen in the area, and sperm whales also like to hunt in the area — a good indication as sperm whales feed on giant squid.

While neither expedition was able to capture images of the giant squid, neither trip was considered a failure due to the other information the scientists were able to find, and the observations they were able to make. In addition, during the trip in 1999, Dr. Roper was able to examine a captured, dead giant squid that was in very good shape, something that doesn’t always happen when squid are caught up in fishing nets as the creatures are very fragile.

Using manned submersibles isn’t the only approach to filming giant squids. Another approach used whales, with scientists attaching video cameras to whales before they begin their hunting dives. I have seen these films, and though they haven’t, yet, been successful (the cameras tend to get knocked off by other whales), this approach is an innovative effort17.

Robotic submersibles have also been used to try and capture images of the giant squid, including the MIT Sea Grant Autonomous underwater robot16. Unfortunately, all of these efforts have not succeeded in filming a giant squid in its natural habitat.

However, folks like Dr. Roper aren’t giving up in their efforts. Dr. Roper is already talking about an expedition back to Kairkoura in the Spring of 2000.

Unfortunately, the 2000 expedition wasn’t successful. Here’s hoping that Dr. Roper continues with his quests.

So What About the Attacks?

One major question that remains about the giant squid is its behavior; specifically would the giant squid attack boats and people. The more I learn about this creature, the more I wonder whether the giant squid was attacking boats and people as food sources — or perhaps just trying to find a ride home.

The giant squid inhabits that nether region of the ocean that is hundreds to thousands of feet below the surface, but not at the bottom of the ocean. Its entire physical makeup is suited specifically to this environment. The main reason that the giant squid has been found dead and washed up on shore is most likely because of clashing ocean streams, cold water meeting warm water.

The giant squid lives in cold water that can get trapped above a layer of warm water. This pushes the poor creature to the surface. The squid’s natural boyancy makes it difficult for it to sink beneath this warm water, and I imagine the hostile surface area weakens the giant squid to a point of desperation. So, what’s a good way to return to the depths? Why, hitch a ride on one creature it knows dives to the depths: whales. And since boats can look like whales…

Now, attacking a submarine as a food source makes a bit more sense, as these craft are much closer to the giant squid’s preferred environment than a boat on the surface of the water. However, a submarine would strongly resemble a whale, a creature the squid knows it can’t beat, so its hard for me to believe that the squid would attack a naval submarine because it considers it “food”.

As for giant squids attacking a whale, a creature the same size as it but weighing many, many times more than the squid — again, this doesn’t make sense unless the squid is desperately hungry. We know, though, that a giant squid defends itself from the feeding whale, which is why there are squid sucker scars found on whales, but the giant squid wouldn’t have a chance against an adult whale. However, it might have a fighting chance against a smaller, juvenile whale, which would explain the sighting of a young whale fighting with the squid, and the squid shown at the surface mentioned by the lighthouse men earlier — the giant squid was still wrapped around the young whale in combat, and the whale dragged the creature to the surface. Going back to my original hypothesis about why a giant squid would grab a boat, the giant squid attached to the young whale is not going to let go when it’ s on the surface. Hence, the look of a battle.

Okay, so my guess is just that, a guess, and most likely not an accurate guess at that. But I can’t help thinking its a better interpretation of the boat attacks then the giant squid leaving its perfect little world to venture to the surface, an almost guaranteed act of death for the squid, just to nosh on a tasty new takeout.

The truth of giant squid behavior is out there, waiting for folks like Dr. Roper to find.

Summary of a Millennium Squid

I have to say, in summary, that I’m a bit glad that images of a living giant squid have not been captured in the last century. What a wonderful way to enter a new millennium, in quest of a creature that still exists half in legend and which has been the focus of so many stories of the millennium that is ending.

Continue to Part 4 of Tale of 2 Monsters: The Loch Ness Monster.