Can't get Function to run from Include file

[Peter Bassett]

I have a .shtml file, that displays photos, in which I wish to pass some
functionality off to an Include file for reusability purposes.
Unfortunately, it's not working.

Here is a portion of the .shtml file:

======
<!--#include file="/tmb8/functions.inc"-->
<script type="text/javascript">
var title = "Noosa, Australia - October / November 2003"
..
..
..
displayphotos(photoarray, args, photosinarow)
======

Here is functions.inc:

========
<%
function displayphotos(photoarray, args, photosinarow)
document.write("hello, world<br>")
end function
%>
==========

To start, I just want to see Hello, World but I just get nothing - the page
is at http://www.solotraveller.com/tmb8/tmb8noosa1oct2003/index.shtml

I think I'm putting the #include statement in the wrong place.
I have been able to get functions to work earlier, but they were called
from .asp files, not .shtml files.

 

[Juliette]

I have a .shtml file, that displays photos, in which I wish to pass some
functionality off to an Include file for reusability purposes.
Unfortunately, it's not working.

Here is a portion of the .shtml file:

======
<!--#include file="/tmb8/functions.inc"-->
<script type="text/javascript">
var title = "Noosa, Australia - October / November 2003"
.
.
.
displayphotos(photoarray, args, photosinarow)
======

Here is functions.inc:

========
<%
function displayphotos(photoarray, args, photosinarow)
document.write("hello, world<br>")
end function
%>
==========

To start, I just want to see Hello, World but I just get nothing - the page
is at http://www.solotraveller.com/tmb8/tmb8noosa1oct2003/index.shtml

I think I'm putting the #include statement in the wrong place.
I have been able to get functions to work earlier, but they were called
from .asp files, not .shtml files.

Syntax problem:

For inline (i.e. included in a HTML document) javascript functions to
work the syntax should be:

<SCRIPT TYPE="text/javascript" LANGUAGE="javascript">
function displayphotos(photoarray, args, photosinarow) {
document.write('hello, world<br>');
}
</SCRIPT>

Gr, Juliette

 

[David Dorward]

<!--#include file="/tmb8/functions.inc"-->

This is executed on the server

<script type="text/javascript">
displayphotos(photoarray, args, photosinarow)

This is executed on the client

Here is functions.inc:
<%
function displayphotos(photoarray, args, photosinarow)
document.write("hello, world<br>")
end function
%>

This is executed on the server.

You can not call a function in the server environment using client side
scripting. You have to make a new request to the server, typically using a
form or a link.

 

[Michael Winter]

Juliette wrote on 16 Nov 2003:

For inline (i.e. included in a HTML document) javascript
functions to work the syntax should be:

<SCRIPT TYPE="text/javascript" LANGUAGE="javascript">

That is incorrect. The 'language' attribute has been deprecated for
almost five years. It should not be used. Although this is irrelevant
(do to my previous statement), the language attribute should include
the version of JavaScript that the SCRIPT block contains. Specifying
"JavaScript" indicates that JavaScript v1.0 objects, methods and
statements follow (and this is probably not the case).

One last point. You also neglected to wrap the JavaScript code in
HTML comments (<!--...-->).

Mike

 

[Michael Winter]

HikksNotAtHome wrote on 17 Nov 2003:

That is incorrect. The 'language' attribute has been deprecated
for almost five years. It should not be used. Although this is
irrelevant (do to my previous statement), the language attribute
should include the version of JavaScript that the SCRIPT block
contains. Specifying "JavaScript" indicates that JavaScript v1.0
objects, methods and statements follow (and this is probably not
the case).

First, you say "language attribute is deprecated" and then you
say that the "language attribute should include the version...".
How do you include the version if you don't use the "deprecated
language attribute"?[/QUOTE]

I said: "Although this is irrelevant (do to my previous
statement)...". The previous statement was that 'language' is
deprecated.

If you don't specify 'language' (i.e. only 'type'), the browser
should, based on browser/language version comparisons, default to the
latest version of the language it supports.

<script type="text/javascript">

Is sufficient.


1) The language is javascript, to capitalize it JavaScript
implies that its a Script for Java, which is very much *not* the
case.

Netscape's own language guide and reference capitalises the language
in that manner, and Netscape created the language.

2) They are not "HTML Comments" in an HTML document.

I was distinguishing them from JavaScript comments.

3) If used, they are <!-- and //-->, not --> (even though a few
of the modern browsers accept the improper -->, it was started
as //-->)

It was to indicate further that I was referring to comments used in
HTML documents, rather than JavaScript comments.

4) They are *not* needed in an HTML document. The browsers that
can not handle javascript code without them are long out of use.

1) Can you *guarantee* that?
2) It doesn't adversely affect the content of the script or the HTML
document, does it?

Mike

 

[Lasse Reichstein Nielsen]

That is incorrect.

It is not.

The 'language' attribute has been deprecated for almost five
years.

It has, but that does not make it "incorrect", just deprecated (unless
you use a strict DTD, where it is incorrect).

It should not be used.

I agree, but it is a recommendation, not a rule. Code containing it
will still validate as HTML 4.01 Transitional.

Although this is irrelevant (do to my previous statement), the
language attribute should include the version of JavaScript that the
SCRIPT block contains. Specifying "JavaScript" indicates that
JavaScript v1.0 objects, methods and statements follow (and this is
probably not the case).

Can you give a reference for this claim? I believe writing
"JavaScript" with no version number would give the most recent
Javsacript version sipported by the client.

From the Netscape 4 HTML manual:
---
LANGUAGE="languageName"
specifies the program language. If the LANGUAGE attribute is not
specified, the default value is JavaScript.

You can specify JavaScript 1.1 for scripts to be executed by the 1.1
version of JavaScript (compatible with Navigator 3.0) or JavaScript
1.0 for scripts to be executed by the 1.0 version. *Navigator 3.0*
---
Since Netscape 4 supported JavaScript 1.2 (and later 1.3), I would have
expected them to say that you could write Javascript1.2 for that version.
They don't, leading me to believe that that is the default.

That is, 'language="Javascript"' is not specifying the version,
leaving that to the browser, and it is not specifying version 1.0.

What *is* bad is people writing language="javascript1.2" without
knowing the differences between that and later Javascript versions
(Javascript 1.2 was only present in Netscape navigator 4.0 - 4.05,
then they changed some of the new features back and became ECMA 262
compatible).

One last point. You also neglected to wrap the JavaScript code in
HTML comments (<!--...-->).

Keep it up. They are not needed, unless you are targeting browsers
from before 1997 (Netscape 1, IE 2, Opera 1). It is also a bad habit
to get, since in XHTML, it will actually remove the script.

/L

 

[Fabian]

Michael Winter hu kiteb:

One last point. You also neglected to wrap the JavaScript code in
HTML comments (<!--...-->).

Others o this group have noted that if you are using a browser that has
teh language attribute deprecated, that browser would also not need the
script commented out. Therefore, I can only assume that (<!--...-->) is
actually one of teh more obscure Japanese smilies (~-~)

 

[Lasse Reichstein Nielsen]

Netscape's own language guide and reference capitalises the language
in that manner, and Netscape created the language.

Yes. I would accept any (sub-)capitalization of Javascript, although
as a proper noun, I would expect the first letter to be capitalized.

1) Can you *guarantee* that?

Any browser that understands HTML 3, or that understands the script tag
at all, will not need HTML-like comments (actually, to those browsers,
it *would* be HTML comments).

Can I guarantee that nobody uses a browser so old that it doesn't know
what the script tag is? No.

If you check www.thecounter.com's browser statistics, they logged
72 accesses by Netscape 1, 21 by MSIE 1 and 11154 by MSIE 2. Those
browsers would need HTML comments. That was out of 38 million accesses,
a whooping 0.03 percent.

Then add the likelyhood of these being either falsified userAgent
strings or people using the browsers for testing only (compared to the
unlikely possibility of people actually using these browsers and
disguising them as other browsers)

If you otherwise support these browsers, then I would also worry about
the HTML comments. Otherwise, I wouldn't.

2) It doesn't adversely affect the content of the script or the HTML
document, does it?

No. But I wouldn't say that omitting them does any harm either. I
definitly would't tell someone to put them in if they omitted them.


Personally, I think it is a bad habit, bordering on voodoo ("I put it
here because I think it makes a difference, but I don't know how"),
and I would like it stopped.

/L

 

[Michael Winter]

Lasse Reichstein Nielsen wrote on 17 Nov 2003:

It is not.


It has, but that does not make it "incorrect", just deprecated
(unless you use a strict DTD, where it is incorrect).


I agree, but it is a recommendation, not a rule. Code containing
it will still validate as HTML 4.01 Transitional.

True, but there is little reason to continue using the Transitional
DTD. The only reason I can see why browsers continue to support it is
due to the large number of 'legacy' websites that still use it. Why
bother adding to that list? The only attribute that I've ever wanted
from it is the 'target' attribute for use with tables. However, that
can avoided with JavaScript, and if JavaScript is not supported by a
client, a "no tables" layout can be used instead.

Can you give a reference for this claim? I believe writing
"JavaScript" with no version number would give the most recent
Javsacript version sipported by the client.

From the Netscape 4 HTML manual:

According to the Transitional DTD, the 'language' attribute is
defined by the user agent when not present. So, it is possible that
later browsers may use other values.

You can specify JavaScript 1.1 for scripts to be executed by
the 1.1 version of JavaScript (compatible with Navigator 3.0)
or JavaScript 1.0 for scripts to be executed by the 1.0
version. *Navigator 3.0*
---
Since Netscape 4 supported JavaScript 1.2 (and later 1.3), I
would have expected them to say that you could write
Javascript1.2 for that version. They don't, leading me to
believe that that is the default.

That is, 'language="Javascript"' is not specifying the version,
leaving that to the browser, and it is not specifying version
1.0.

What *is* bad is people writing language="javascript1.2" without
knowing the differences between that and later Javascript
versions (Javascript 1.2 was only present in Netscape navigator
4.0 - 4.05, then they changed some of the new features back and
became ECMA 262 compatible).

There is a table in the Client-Side JavaScript Guide (v1.3, Chapter 9
- Specifying the JavaScript Version) that shows what 'language'
values are supported by which NN versions.

The value 'JavaScript' is used with v1.0 and 'JavaScript1.?'
thereafter. In the table, 'JavaScript' is treated as an earlier
version compared to strings that specify a version number.

This is the table. The "Tags supported" column is verbatim - the
other columns are abbreviated to prevent too much wrapping.

NN ver. JS ver. Tags supported

<2.0 none n/a
2.0 1.0 <SCRIPT LANGUAGE="JavaScript">
3.0 1.1 <SCRIPT LANGUAGE="JavaScript1.1"> and all earlier
versions
4.0-.05 1.2 <SCRIPT LANGUAGE="JavaScript1.2"> and all earlier
versions

Keep it up. They are not needed, unless you are targeting
browsers from before 1997 (Netscape 1, IE 2, Opera 1). It is
also a bad habit to get, since in XHTML, it will actually remove
the script.

Interesting point, but I don't write using XHTML, and if I did, I'd
quickly notice that JavaScript code isn't being executed.

Mike

 

[Lasse Reichstein Nielsen]

True, but there is little reason to continue using the Transitional
DTD.

Little reason, yes, and I don't myself, but it is still *correct*.

The only reason I can see why browsers continue to support it is
due to the large number of 'legacy' websites that still use it.

Hardly. That is the reason why they support tag soup parsing.
I have yet to see a browser that honors the DOCTYPE declaration to the
point where they refuse features not in the chosen document type. They
might separate between HTML and XHTML, but that is it.

Why bother adding to that list?

Some people would claim that XHTML is the future of the web, and people
using HTML are holding us back. You are adding to their list.

It is all a matter of perspective.

I am satisfied if somebody else's page validates. That is far better
than the prevailing mindset: "as long as it works" (for some definition
of "works" that mostly refer to IE).

The only attribute that I've ever wanted from it is the 'target'
attribute for use with tables. However, that can avoided with
JavaScript, and if JavaScript is not supported by a client, a "no
tables" layout can be used instead.

I guess you mean "no frames".

....
There is a table in the Client-Side JavaScript Guide (v1.3, Chapter 9
- Specifying the JavaScript Version) that shows what 'language'
values are supported by which NN versions.

Thanks, reference accepted.

All the more reason to not use the language attribute. And it only
refer to the Netscape browser. Except for Mozilla, I don't believe
other browsers respect the version number, since they only have one
Javascript engine available (e.g. JScript through the WSH).

/L

 

[Michael Winter]

Lasse Reichstein Nielsen wrote on 17 Nov 2003:

Any browser that understands HTML 3, or that understands the
script tag at all, will not need HTML-like comments (actually,
to those browsers, it *would* be HTML comments).

Can I guarantee that nobody uses a browser so old that it
doesn't know what the script tag is? No.

If you check www.thecounter.com's browser statistics, they
logged 72 accesses by Netscape 1, 21 by MSIE 1 and 11154 by MSIE
2. Those browsers would need HTML comments. That was out of 38
million accesses, a whooping 0.03 percent.

Then add the likelyhood of these being either falsified
userAgent strings or people using the browsers for testing only
(compared to the unlikely possibility of people actually using
these browsers and disguising them as other browsers)

If you otherwise support these browsers, then I would also worry
about the HTML comments. Otherwise, I wouldn't.

No. But I wouldn't say that omitting them does any harm either.
I definitly would't tell someone to put them in if they omitted
them.

Personally, I think it is a bad habit, bordering on voodoo ("I
put it here because I think it makes a difference, but I don't
know how"), and I would like it stopped.

The problem with legacy support is clearly: where to draw the line.
It would appear that hiding scripts from old browsers is one such
place.

Mike

 

[GIMME]

For inline (i.e. included in a HTML document) javascript
Wrong. You need an end-script tag , as in </script>

 

[GIMME]

<!--#include file="/tmb8/functions.inc"-->

This is an apache server side include ...

Your server has to be configured to support it.

By default it is not supported.

 

[Thomas 'PointedEars' Lahn]

I have yet to see a browser that honors the DOCTYPE declaration to the
point where they refuse features not in the chosen document type. They
might separate between HTML and XHTML, but that is it.

Take Mozilla/5.0 and an XHTML DOCTYPE (or one of any other XML
application). It does not even matter if XHTML it is served
(correctly) as application/xhtml+xml. You are right for HTML
DOCTYPES, though, because both Mozilla/5.0 and IE then switch
to Quirks Mode.


PointedEars

 

[Lasse Reichstein Nielsen]

Lasse Reichstein Nielsen wrote:

Take Mozilla/5.0 and an XHTML DOCTYPE (or one of any other XML
application). It does not even matter if XHTML it is served
(correctly) as application/xhtml+xml.

How about this code then:
---
<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>Skeleton</title>
</head>
<body>
<p>a<font color="red">bcd</font>efg<br/>
<script type="text/javascript">
document.write(document.compatMode);
document.write(" XML-version: " + document.xmlVersion);

</script></p>
</body>
</html>
---
This is XHTML 1.0 *strict*, so the font tag is not legal. Mozilla
changes the color to red anyway, i.e., it doesn't ignore the tag even
though it is not defined in the version of XHTML that the document
contains. It is in standards mode ("CSS1Compat").

You are right for HTML DOCTYPES, though, because both Mozilla/5.0
and IE then switch to Quirks Mode.

Not necessarily. I always use HTML 4.01 Strict with and URL. It
triggers standards mode in Mozilla, IE and Opera.

/L

 

[Québec]

Hi everybody,

How do you know when IExplorer switch to Quirks
Mode or stays standards mode?


Jean Pierre

 

[Lasse Reichstein Nielsen]

How do you know when IExplorer switch to Quirks Mode or stays
standards mode?

This page tells you which DOCTYPEs trigger quirks mode:
<URL:http://msdn.microsoft.com/library/en-us/dnie60/html/cssenhancements.asp>

This page tells you how to check when the page has loaded:
<URL:http://msdn.microsoft.com/workshop/author/dhtml/reference/properties/compatmode.asp>

I have a bookmarklet that checks it:
<URL:javascript:alert(document.compatMode);>

/L

 

[Jim Ley]

Some people would claim that XHTML is the future of the web, and people
using HTML are holding us back. You are adding to their list.

And some people would claim that XHTML is what is actually holding us
back from the future of the web, XHTML 1.0 being a total failure,
XHTML 1.1 being better, but no features worth using, and XHTML 2.0
still tinkering around at edges fixing up a bit, but leaving much
still broken, and a long way behind other available XML formats.

XHTML should at most be a clue, and authoring HTML as anything is not
going to change that.

All the more reason to not use the language attribute. And it only
refer to the Netscape browser. Except for Mozilla, I don't believe
other browsers respect the version number, since they only have one
Javascript engine available (e.g. JScript through the WSH).

IIRC IE can be configured to use different script engines - they'd
have to be ActiveScripting capable though, so you could make it run
DScript instead of JScript (or even perlscript if you wanted to be
particularly perverse.) but I think I agree in principle.

Jim.

 

[Thomas 'PointedEars' Lahn]

Take Mozilla/5.0 and an XHTML DOCTYPE (or one of any other XML
application). It does not even matter if XHTML it is served
(correctly) as application/xhtml+xml.

How about this code then:
[...]
This is XHTML 1.0 *strict*, so the font tag is not legal. Mozilla
changes the color to red anyway, i.e., it doesn't ignore the tag even
though it is not defined in the version of XHTML that the document
contains. It is in standards mode ("CSS1Compat").

Putting the above code in a document reveals another error:

| XML Parsing Error: not well-formed
| Location: file:///[...]/text.xhtml
| Line Number 4, Column 43:
|
| <html xmlns="http://www.w3.org/1999/xhtml"" xml:lang="en" lang="en">
| ------------------------------------------^

Having corrected it, I see you are right (the same here, using `Mozilla/5.0
(Windows; U; Windows NT 5.0; en-US; rv:1.6a) Gecko/20031028') and have found
nothing but a bug. I cannot use Bugzilla now, please be so kind and file
the bug if it is not already filed.

Not necessarily. I always use HTML 4.01 Strict with and URL. It
triggers standards mode in Mozilla, IE and Opera.

You misread my statement. Leaving the DOCTYPE declaration out triggers
"Quirks Mode" in both of the mentioned UAs. I do not know if Opera has
a "Quirks Mode" and when it is triggered.


PointedEars

 

[Lasse Reichstein Nielsen]

Putting the above code in a document reveals another error:

Oops. How did I put that quote there? It wasn't in the file.

Having corrected it, I see you are right (the same here, using `Mozilla/5.0
(Windows; U; Windows NT 5.0; en-US; rv:1.6a) Gecko/20031028') and have found
nothing but a bug. I cannot use Bugzilla now, please be so kind and file
the bug if it is not already filed.

I don't know the first thing about bugzilla (I couldn't find it
without Google), so i think I'll leave that to someone more familiar
with the process (it requires an account, right?).

Give me an Opera bug, I'm used to reporting those

You misread my statement. Leaving the DOCTYPE declaration out triggers
"Quirks Mode" in both of the mentioned UAs.

Ah yes, I read it as including an HTML doctype would trigger Quirks mode.

I do not know if Opera has a "Quirks Mode" and when it is triggered.

It has, and it triggers exactly the same way as IE.
<URL:http://www.opera.com/docs/specs/doctype/>

/L