Include JavaScript??

J

JS

I have a rather long JavaScript in my <HEAD> </HEAD> part. I would like to
put this javaScript in another file and then just include it instead. Is
that possible and what should files containing only javascript be called??
 
R

Random

JS said:
I have a rather long JavaScript in my <HEAD> </HEAD> part. I would like to
put this javaScript in another file and then just include it instead. Is
that possible and what should files containing only javascript be called??

<script type=text/javascript src=myJSFile.js></script>

The </script> is important: some older browsers will not understand />,
and a closing of some kind is required.

JavaScript files are best named with a .js extension.
 
M

Michael Winter

<script type=text/javascript src=myJSFile.js></script>

The type attribute contains a slash, so it must be quoted. The src
attribute doesn't need to be quoted in snippet shown above, but there is
no harm in doing so.
The </script> is important

Of course. Closing tags are required for SCRIPT elements.
some older browsers will not understand />, [...]

That's because it creates HTML that is gibberish. I know you're
inferring the use of XHTML, but that isn't viable on the Web anyway.
Moreover, element minimisation for non-empty elements is not permitted
by XHTML 1.0 - Appendix C (though that section is only informative).
JavaScript files are best named with a .js extension.

Unless the server has been configured differently, they should always be
named with a .js extension otherwise the correct content type will not
be sent.

Mike
 
R

Random

Michael said:
The type attribute contains a slash, so it must be quoted. The src
attribute doesn't need to be quoted in snippet shown above, but there is
no harm in doing so.

Call me a minimalist. I've never seen a single browser that needed
quotes on it-- even Lynx understands barewords, slash or no slash.
Hitting that damned quote key so often hurts my pinky.
Of course. Closing tags are required for SCRIPT elements.

Go on, really?
some older browsers will not understand />, [...]

That's because it creates HTML that is gibberish. I know you're
inferring the use of XHTML, but that isn't viable on the Web anyway.
Moreover, element minimisation for non-empty elements is not permitted
by XHTML 1.0 - Appendix C (though that section is only informative).

Fortunately or unfortunately, some newer browsers do support minimising
even in HTML. Hence the distinguishment.

Unless the server has been configured differently, they should always be
named with a .js extension otherwise the correct content type will not
be sent.

Which is why it is best, but not necessarily required, to use a .js
extension.

Did you have something helpful to add here, Mr. Winter?
 
M

Michael Winter

Call me a minimalist.

There may be better adjectives.
I've never seen a single browser that needed quotes on it [...]

I can't say I've come across a user agent that can't handle tag soup.
That doesn't mean I make a habit of writing it, and I would certainly
never recommend it.

[snip]
Go on, really?

If it's so obvious, why did you even mention it in the first place? I
would hope that the OP knows enough about HTML to understand the
difference between empty and non-empty elements. It just seems that the
OP was unaware of the src attribute, or the perhaps the precise details
of using it. A section of the updated FAQ[1] notes (yet to be
introduced) will include detailed information on this topic.

[snip]
Fortunately or unfortunately, some newer browsers do support minimising
even in HTML. Hence the distinguishment.

Looking here, only Mozilla does. All other user agents I currently have
to hand fail, whether it be in executing the script, parsing subsequent
markup, or both. Therefore, the minimisation of non-empty elements in
HTML should always be avoided; there's no value in making distinctions.

[snip]
Did you have something helpful to add here, Mr. Winter?

Pointing out dubious advice is helpful, in my opinion.

Mike


[1] The current draft:
<URL:http://www.litotes.demon.co.uk/js_info/FAQ8_1_Draft.html>
 
R

Richard Cornford

Random said:
Call me a minimalist. I've never seen a single browser that
needed quotes on it-- even Lynx understands barewords, slash
or no slash. Hitting that damned quote key so often hurts my
pinky.

The "I have never seen a browser that ..." argument may just be an
indicator of having not looked at many browsers. The THML specification
is very clear on the circumstances where quotes may be omitted from
attribute values. That browsers are forced, by the prevalence of
incompetent web authoring, to be more tolerant is not an exclude for
encouraging the authoring of incorrect HTML. Among other things, how is
someone going to see the significant problems when validating their HTML
if the validator is spewing out error reports every time it encounters
an attribute value that should be quoted but has not been.
Go on, really?

Yes, they are not optional in the HTML DTDs.

Fortunately or unfortunately, some newer browsers do support
minimising even in HTML. Hence the distinguishment.
<snip>

Such an HTML browser would be very broken, can you name one?

Richard.
 
R

Richard Cornford

Michael said:
On 30/05/2005 10:41, Random wrote:

Unless the server has been configured differently, they
should always be named with a .js extension otherwise the
correct content type will not be sent.

A server cannot be configured to send JS files with the correct content
type as there is no correct content type for JS. They may be configured
to send JS with an incorrect content type (text/css would be incorrect)
but my experiments, outputting incorrect content types with dynamically
generated JS, suggest that web browsers consistently disregard the
content-type headers sent with JS files, which is reasonable given that
there is no correct content type. (I think that Netscape 2 was the only
browser that had an attitude towards JS content type, and it wanted and
application-x version).

I suspect that character encoding is all the browser will be interested
in when it comes to imported JS files, and whatever shows up will be
passed to the JS interpreter to syntax-error or not (assuming HTTP
status 200). Hence the reoccurring problems with servers sending custom
HTML 404 pages with HTTP 200 statuses making it look like JS is not
working when it is in fact not being found.

Richard.
 
M

Michael Winter

Michael Winter wrote:
[snip]
Unless the server has been configured differently, [scripts]
should always be named with a .js extension otherwise the
correct content type will not be sent.

A server cannot be configured to send JS files with the correct content
type as there is no correct content type for JS.

:p True. There are MIME types that are generally understood to be
Javascript (application/x-javascript and text/javascript), but there is
no registered value. I remember the lecture from Jim Ley well. :)
They may be configured to send JS with an incorrect content type [...]

Yes. What I was trying to say is that using a .js extension will send a
reasonable value with a properly configured server, but unless the
server is prepared for such an event, using a different extension will
result in an inappropriate value (possibly one of text/plain or text/html).

[snip]

Mike
 
T

Thomas 'PointedEars' Lahn

Random said:
<script type=text/javascript src=myJSFile.js></script>

The </script> is important: some older browsers will not understand />,

It is a matter of the markup language, not of the age of the browser.
`/>' (XML NET/Web Annex NESTC-NET) is not a tag close delimiter in HTML,
only in XHTML[1]. Instead, `/' in a HTML start tag, as introducing an
SGML SHORTTAG feature not widely implemented but commonly misused in
cluelessly called "HTML compatible XHTML" alas proposed by the XHTML 1.0
Specification, serves a completely different purpose:

<http://www.dodabo.de/html+css/tests/shorttag.html>


PointedEars
___________
[1] ref. HTML 4.01, chapter 20,
and <http://www.w3.org/TR/NOTE-sgml-xml.html>
 
T

Thomas 'PointedEars' Lahn

Richard said:
Random said:
Fortunately or unfortunately, some newer browsers do support
minimising even in HTML. Hence the distinguishment.
[...]

Such an HTML browser would be very broken,

It would not, iff it properly implements HTML SHORTTAG features.
can you name one?

See the last URI in my other followup.


PointedEars
 
R

Richard Cornford

Thomas said:
Richard said:
Random said:
Fortunately or unfortunately, some newer browsers do support
minimising even in HTML. Hence the distinguishment.
[...]

Such an HTML browser would be very broken,

It would not, iff it properly implements HTML SHORTTAG
features.
<snip>

If you didn't backtrack this thread how did you know what Random was
referring to as 'minimising', and if you did backtrack the thread how
come you did not observe that Random's comment was in response to Mike's
comments relating to XHTML 'minimising'? And an HTML browser that
interprets that style of syntax in the way an XHTML browser would is
broken.

But we still have no evidence of any HTML browsers interpreting <script
.... /> in an XHTML style so this is academic.

Richard.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,768
Messages
2,569,574
Members
45,048
Latest member
verona

Latest Threads

Top