473,386 Members | 1,821 Online
Bytes | Software Development & Data Engineering Community
Post Job

Home Posts Topics Members FAQ

Join Bytes to post your question to a community of 473,386 software developers and data experts.

Putting "javascript:" in front of code?

I see some code examples like this:

<DIV onmouseover="this.style.background='blue'">

and other code examples like this:

<DIV onmouseover="javascript:this.style.background='blu e'">

Which way is more proper? Or are both ways perfectly fine? Are there any
specifications that discuss when "javascript:" should be put in front of code?

Jul 20 '05 #1
25 3685

<de*******@no.spam.com> schreef in bericht
news:3f***************@news.md.comcast.giganews.co m...
I see some code examples like this:

<DIV onmouseover="this.style.background='blue'">

and other code examples like this:

<DIV onmouseover="javascript:this.style.background='blu e'">

Which way is more proper? Or are both ways perfectly fine? Are there any
specifications that discuss when "javascript:" should be put in front of code?


The first one is the proper way, because the onmouseover attribute (and
other event handlers) expects the value to contain JS code only.

What you will also see very often, is the usage of the javascript: pseudo
protocol in anchors:
<a href="javascript:popup('somepage')">...</a>

which should be replaced with:
<a href="somepage" onclick="popup(href); return false">...</a>

because the link will still be clickable when JS is disabled. When JS is
enabled, the function will be called with the href value as an argument and
the 'return false' at the end prevents that the default action will be
taken.

See also: http://jibbering.com/faq/#FAQ4_24
JW

Jul 20 '05 #2
Janwillem Borleffs wrote on 06 Dec 2003:

<de*******@no.spam.com> schreef in bericht
news:3f***************@news.md.comcast.giganews.co m...
I see some code examples like this:

<DIV onmouseover="this.style.background='blue'">

and other code examples like this:

<DIV onmouseover="javascript:this.style.background='blu e'">

Which way is more proper? Or are both ways perfectly fine?
Are there any specifications that discuss when "javascript:"
should be put in front of code?

The second way is incorrect. "javascript:" is a URI protocol
specifier, so it is only valid in a src or href attribute. However
(as J Borleffs stated), JavaScript URIs should not be used in case
JavaScript has been disabled by the user: the URI will be malformed
and useless to the user.
The first one is the proper way, because the onmouseover
attribute (and other event handlers) expects the value to
contain JS code only.


WHAT?!?! That is so WRONG it's untrue! The intrinsic events can be
used by ANY scripting language: that's why they are part of the HTML
specification, not solely JavaScript.

The language used in intrinsic events is specified either with a HTTP
header or, more commonly, a META element placed in the document's
HEAD:

<META http-equiv="Content-Script-Type" type="script_MIME_type">

For JavaScript, the MIME type is text/javascript, so the above should
read:

<META http-equiv="Content-Script-Type" type="text/javascript">

If you omit either the header or META element, but use intrinsic
events, your HTML document is invalid. The only reason why it would
work is because the browser makes assumptions about what the
intrinsic events contain (they usually assume JavaScript). However,
not all may assume JavaScript as there are no 'default' languages. In
fact, the HTML specification states clearly that NO assumption needs
to be made and any events can be ignored, if no default language has
been specified by the author (using META or HTTP header).

<snipped the rest of the reply, which is OK>

Mike

--
Michael Winter
M.******@blueyonder.co.invalid (replace ".invalid" with ".uk")
Jul 20 '05 #3

"Michael Winter" <M.******@blueyonder.co.invalid> schreef in bericht
news:Xn*******************************@193.38.113. 46...

WHAT?!?! That is so WRONG it's untrue! The intrinsic events can be
used by ANY scripting language: that's why they are part of the HTML
specification, not solely JavaScript.


Yeah, you're right of course.
JW

Jul 20 '05 #4

"Michael Winter" <M.******@blueyonder.co.invalid> schreef in bericht
news:Xn*******************************@193.38.113. 46...

WHAT?!?! That is so WRONG it's untrue! The intrinsic events can be
used by ANY scripting language: that's why they are part of the HTML
specification, not solely JavaScript.

The language used in intrinsic events is specified either with a HTTP
header or, more commonly, a META element placed in the document's
HEAD:

<META http-equiv="Content-Script-Type" type="script_MIME_type">


Did some research on this header, and it seems that at least IE totally
ignores it and always defaults to JS.

Try:

<html>
<head>
<title> New Document </title>
<meta http-equiv="Content-Script-Type" content="text/vbscript" />
</head>

<body>
<a href="#" onclick="MsgBox('Hello')">Say...</a>
</body>
</html>

Read:

http://www.bauser.com/websnob/meta/browsers.html
JW

Jul 20 '05 #5
de*******@no.spam.com writes:
I see some code examples like this:

<DIV onmouseover="this.style.background='blue'">

and other code examples like this:

<DIV onmouseover="javascript:this.style.background='blu e'">

Which way is more proper?
The former. Personally, I would write:
<div onmouseover="this.style.backgroundColor='blue';">
but that's leaving correct and passing on to pedantic :)
Or are both ways perfectly fine?
The "javascript:" is not necessary, doesn't mean what the author think
it means, and at best does no damage.

The author probably thinks that it specifies that what comes after is
Javascript. It doesn't [1]. Instead it is read by the Javascript
interpreter as a label with the name "javascript:". You can try this
(in a non-IE browser):

<div onclick="javascript:while(true){break javascript;};alert('exit');">
XXX
</div>

The "break javascript" statement breaks the loop labeled "javascript"
by the initial label. It doesn't work in IE [1].
Are there any specifications that discuss when "javascript:" should
be put in front of code?


Yes. The short summary is: Almost never.

The place where it belongs is in javascript:-URL's. Example:
<a href="javascript:generatePage()">generate new page</a>
The meaning of that is, that the result of the Javascript expression
after the "javascript:" becomes the new content of the page.
Anotheer example:
<a href="javascript:'<p>this page has no content</p>'">generate
new page</a>
That form of javascript:-URL is often misused where the onclick
event handler is more appropriate (see the FAQ:
<URL:http://jibbering.com/faq/#FAQ4_24>).
These URLs are very rarely needed in actual pages.

javascript: URLs are also very useful as bookmarks, where they can be
used to execute code in the context of the current page (I have
several, e.g.,
javascript:alert(document.compatMode)

The other time when you might need it is if you write a page
specifically to IE, and where you have set the default script language
to, e.g., VBScript. Your page will only work in IE, so you might
as well use other IE-specific features, like the "javascript:" intrinsic
event language selection. Such a page doesn't belong on the internet,
but on intranets where you know only IE will access it, it can make
sense.
Summary: You can appropriately use "javascript:"
- in href/URL - when it generates the new page, or
- as bookmarks/favorites (aka. bookmarklets/favlets)
- in onclick etc - in IE-specific pages only.

You can most likely make a living as a web designer without ever
using "javascript:" again.
/L

[1] IE is special. It actually uses the "javascript:" to specify the
language of the following code. That is only necessary if the language
is different from the default script language of the page, which by
default is JScript/Javascript for IE. You set the default script
language for intrinsic events (e.g., onclick) using, e.g.,
<meta http-equiv="Content-Script-Type" content="text/javascript">
Not a bad idea in itself, and if other browsers supported more than
one language, it would probably become a standard. Right now it
isn't, and IE is the only browser with this behavior.

--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
Jul 20 '05 #6
"Michael Winter" <M.******@blueyonder.co.invalid> wrote in message
news:Xn*******************************@193.38.113. 46...
<snip>
<DIV onmouseover="this.style.background='blue'">

and other code examples like this:

<DIV onmouseover="javascript:this.style.background='blu e'">

Which way is more proper? Or are both ways perfectly fine?
Are there any specifications that discuss when "javascript:"
should be put in front of code?

The second way is incorrect.


Incorrect might be a bit strong as it implies something contrary to some
criteria of validity or syntactic correctness. Though that may just be a
matter of interpretation (of English).
"javascript:" is a URI protocol specifier, so it
is only valid in a src or href attribute.
In JavaScript source code (which is what the string provided as the
value for an event handling attribute is (assuming JavaScript is the
default language for such attributes) a character sequence that
qualifies as an identifier followed by a colon is a label[1] (ECMA 262
3rd Ed. Section 12.12). And the character sequence "javascript" fulfils
the requirements to be considered an identifier so "javascrpt:" will be
interpreted as a label by conforming interpreters.

As a result its inclusion at the start of the code for an event
handeling attribute string is completely valid, in the sense of being
completely legal JavaScript source code, it is just utterly pointless.
Unless, of course, there was a corresponding - break - or - continue -
statement that employed that label. However, IE unfortunately does place
a special interpretation on the character sequence "javascrpt:"
appearing in that context and does not use it as a label within the
resulting event handling function. So while prefixing the string
provided for an event handling attribute with "javascript:" normally
represents the valid (but pointless) introduction of a label into the
function the fact that IE treats it differently means that if the code
should have a label in that context "javascript:" would be an unwise
label to use (along with, for example, "vbscript:").

So the inclusion of "javascript:" as a prefix for event handling
attributes is incorrect (when used in a non-IE specific (Intranet)
context) in the sense that including a label that is never used in
source code is pointless and if a label was required "javascrpt:" would
be predictably unsuitable as a label because of the way that it is
handled by IE. Just 11 extra bytes of download which contribute nothing
but to potentially induce confusion in the minds of inexperienced
readers.
However (as J Borleffs stated), JavaScript URIs should not be
used in case JavaScript has been disabled by the user: the URI
will be malformed and useless to the user.

<snip>

JavaScript URIs are known causers of problems even when JavaScript is
enabled/available (just another reason for never using them).

Richard.

[1] Except possibly when it occurs within a switch statement or the
conditional ( ? : ) operator.
Jul 20 '05 #7
Richard Cornford wrote on 06 Dec 2003:
"Michael Winter" <M.******@blueyonder.co.invalid> wrote in
message news:Xn*******************************@193.38.113. 46...
<snip>
The second way is incorrect.


Incorrect might be a bit strong as it implies something contrary
to some criteria of validity or syntactic correctness. Though
that may just be a matter of interpretation (of English).


Incorrect, meaning: the wrong way of specifying the language of an
intrinsic event.
"javascript:" is a URI protocol specifier, so it
is only valid in a src or href attribute.


In JavaScript source code (which is what the string provided as
the value for an event handling attribute is (assuming
JavaScript is the default language for such attributes) a
character sequence that qualifies as an identifier followed by a
colon is a label[1] (ECMA 262 3rd Ed. Section 12.12). And the
character sequence "javascript" fulfils the requirements to be
considered an identifier so "javascrpt:" will be interpreted as
a label by conforming interpreters.


[moved] [1] Except possibly when it occurs within a switch statement or
the conditional ( ? : ) operator.
That's true, but the topic isn't (quite) relating to JavaScript
source code. This is regarding the use of the string, "javascript:",
to actually perform some specific action. The OP assumed that using
javascript: in an intrinsic event specified the language of that
event handling code (which is incorrect). The only special nature of
the string should be as (defined by Netscape - so possibly not a
global standard) a protocol specifier in the context of a URI.

<snip>
JavaScript URIs are known causers of problems even when
JavaScript is enabled/available (just another reason for never
using them).


Agreed

Mike

--
Michael Winter
M.******@blueyonder.co.invalid (replace ".invalid" with ".uk")
Jul 20 '05 #8
On Sat, 06 Dec 2003 12:10:04 GMT, Michael Winter
<M.******@blueyonder.co.invalid> wrote:
For JavaScript, the MIME type is text/javascript, so the above should
read:
Could you cite the relevant RFC which indicates this please? for
JavaScript (capatilised like that) the relevant one would be
application/x-javascript surely?
If you omit either the header or META element, but use intrinsic
events, your HTML document is invalid.


No, invalid has a technical meaning in HTML, and that does not make it
invalid, it may make it a non-conforming HTML 4 document, but then
that's only a tiny subset of HTML. ( RFC 2854 blesses all tag-soup to
be html)

Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/

Jul 20 '05 #9
Lee
Michael Winter said:

Richard Cornford wrote on 06 Dec 2003:
"Michael Winter" <M.******@blueyonder.co.invalid> wrote in
message news:Xn*******************************@193.38.113. 46...
<snip>
The second way is incorrect.


Incorrect might be a bit strong as it implies something contrary
to some criteria of validity or syntactic correctness. Though
that may just be a matter of interpretation (of English).


Incorrect, meaning: the wrong way of specifying the language of an
intrinsic event.


The OP didn't ask how to specify the language, he asked
which syntax was more proper.
That's true, but the topic isn't (quite) relating to JavaScript
source code. This is regarding the use of the string, "javascript:",
to actually perform some specific action.


That's not how I interpret the topic. I suspect the OP
didn't know that other languages were even available.

Jul 20 '05 #10
Waaaaay back on 06-Dec-03 03:58:11, delerious said this about Putting "javascript:" in front of code?:
I see some code examples like this: <DIV onmouseover="this.style.background='blue'"> and other code examples like this: <DIV onmouseover="javascript:this.style.background='blu e'"> Which way is more proper? Or are both ways perfectly fine? Are there any
specifications that discuss when "javascript:" should be put in front of
code?


The "javascript:" prefix, seriously, is a gift from Satan. It's horrible.
Most browsers I've used don't know what the fleeick to do with that.

If it works without the "javascript:" prefix, I say don't use it. If it
works WITH it, find an alternate way.

--
da****@banana-and-louie.org * dauber.50megs.com
* ICQ: 28677921 * YIM: dau_ber * AIM: ddaauubbeerr

Jul 20 '05 #11
On Sat, 06 Dec 2003 15:00:01 +0100, Lasse Reichstein Nielsen <lr*@hotpop.com>
wrote:
Which way is more proper?


The former. Personally, I would write:
<div onmouseover="this.style.backgroundColor='blue';">
but that's leaving correct and passing on to pedantic :)


Oh this was another thing I was wondering about. :) I tried to do
"this.style.background-color='blue'" but got an error. So in order to get
those CSS properties to work in Javascript, I should remove the hyphens and
capitalize the first letter of the words after hyphens?

Thanks for the great, informative responses everyone!

Jul 20 '05 #12
de*******@no.spam.com writes:
Oh this was another thing I was wondering about. :) I tried to do
"this.style.background-color='blue'" but got an error. So in order to get
those CSS properties to work in Javascript, I should remove the hyphens and
capitalize the first letter of the words after hyphens?


Yes, that is the way CSS properties are mapped into Style Object
properties in the W3C DOM (and supported in most modern browsers).
<URL:http://www.w3.org/TR/DOM-Level-2-Style/css.html#CSS-CSS2Properties>

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
Jul 20 '05 #13
Jim Ley wrote on 06 Dec 2003:
On Sat, 06 Dec 2003 12:10:04 GMT, Michael Winter
<M.******@blueyonder.co.invalid> wrote:
For JavaScript, the MIME type is text/javascript, so the above
should read:


Could you cite the relevant RFC which indicates this please?
for JavaScript (capatilised like that) the relevant one would be
application/x-javascript surely?


The HTML specification itself uses text/javascript as the MIME type
for JavaScript (though that doesn't necessarily make it correct).

This issue was raised in W3C's public HTML mailing list two years ago
(http://lists.w3.org/Archives/Public/...Sep/0020.html). It
comments that then, various script MIME types (of both text and
application types) were not registered. Looking on IANA's website, I
found that they're /still/ not registered. Mentioned in that mailing
list was the fact that browsers are split on what types to use: IE
with text and Netscape with application. However, as neither types
have been registered, neither browser is correct. I don't know what
various browsers consider the proper JavaScript MIME type. However, I
do agree that an application type is the better choice.
If you omit either the header or META element, but use intrinsic
events, your HTML document is invalid.


No, invalid has a technical meaning in HTML, and that does not
make it invalid, it may make it a non-conforming HTML 4
document, but then that's only a tiny subset of HTML. ( RFC
2854 blesses all tag-soup to be html)


Do the semantics really matter? Yes, if you attempted to validate the
document it would succeed, but the document is still incorrect and
relies on behaviour that is not guaranteed.

Mike

--
Michael Winter
M.******@blueyonder.co.invalid (replace ".invalid" with ".uk")
Jul 20 '05 #14
Lee wrote on 06 Dec 2003:
Michael Winter said:

Richard Cornford wrote on 06 Dec 2003:
"Michael Winter" <M.******@blueyonder.co.invalid> wrote in
message
news:Xn*******************************@193.38.113. 46...


<snip>
The second way is incorrect.

Incorrect might be a bit strong as it implies something
contrary to some criteria of validity or syntactic
correctness. Though that may just be a matter of
interpretation (of English).


Incorrect, meaning: the wrong way of specifying the language of
an intrinsic event.


The OP didn't ask how to specify the language, he asked
which syntax was more proper.


I know what the OP asked.
That's true, but the topic isn't (quite) relating to JavaScript
source code. This is regarding the use of the string,
"javascript:", to actually perform some specific action.


That's not how I interpret the topic. I suspect the OP
didn't know that other languages were even available.


The original question was: Is "javascript:some_javascript_code"
syntactically correct? The answer is yes. But leaving it at that
neglects the assumption upon which the inclusion of "javascript:" is
based. Some authors that post to this group attach a special meaning
to that string in an intrinsic event, and that association needs to
be dispelled.

Mike

--
Michael Winter
M.******@blueyonder.co.invalid (replace ".invalid" with ".uk")
Jul 20 '05 #15
Lee
Michael Winter said:
The original question was: Is "javascript:some_javascript_code"
syntactically correct? The answer is yes. But leaving it at that
neglects the assumption upon which the inclusion of "javascript:" is
based. Some authors that post to this group attach a special meaning
to that string in an intrinsic event, and that association needs to
be dispelled.


Certainly, but not by replacing it with the false belief that
it is incorrect JavaScript. The message that you responded
to had made the actual facts clear. You muddied the waters
by suggesting that his explanation was wrong.

Jul 20 '05 #16
On Sun, 07 Dec 2003 02:11:17 GMT, Michael Winter
<M.******@blueyonder.co.invalid> wrote:
Jim Ley wrote on 06 Dec 2003:
The HTML specification itself uses text/javascript as the MIME type
for JavaScript (though that doesn't necessarily make it correct).
Good for it, it has no change control or anything else over
javascript, The HTML WG has no more status than me or you on what is
the mime-type for js, you'll note the SVG WG say it's text/ecmascript.

However, as neither types
have been registered, neither browser is correct.
You don't seem to understand the x- tree, whilst you shouldn't use an
x-tree in public really, there we'ren't vnd. trees for it to go, there
is nothing wrong in using an x-tree.
I don't know what
various browsers consider the proper JavaScript MIME type. However, I
do agree that an application type is the better choice.


No it's not, it's a private namespace for development/experimental
purposes and should only be used by agreement of what it means at
boths ends, that's never happened. x-trees should not be used on the
web, and they should not be used at all now (the vnd. and prs. trees
are better for what it achieves)
If you omit either the header or META element, but use intrinsic
events, your HTML document is invalid.


No, invalid has a technical meaning in HTML, and that does not
make it invalid, it may make it a non-conforming HTML 4
document, but then that's only a tiny subset of HTML. ( RFC
2854 blesses all tag-soup to be html)


Do the semantics really matter?


Yes, the meaning of VALID matters, the more important fact though is
it is only HTML 4 where the above rules come into play, as most people
author tag-soup, or other HTML types, the rules do not exist.

Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/

Jul 20 '05 #17
Jim Ley wrote on 07 Dec 2003:
On Sun, 07 Dec 2003 02:11:17 GMT, Michael Winter
<M.******@blueyonder.co.invalid> wrote:
Jim Ley wrote on 06 Dec 2003:
The HTML specification itself uses text/javascript as the MIME
type for JavaScript (though that doesn't necessarily make it
correct).
Good for it, it has no change control or anything else over
javascript, The HTML WG has no more status than me or you on
what is the mime-type for js, you'll note the SVG WG say it's
text/ecmascript.


That's why I said: "though that doesn't necessarily make it correct".
I realise that they have no say over the MIME type for JS. However, I
would of thought that they made the decision to use that type in
their specifications for a good reason.

<snip>
I don't know what
various browsers consider the proper JavaScript MIME type.
However, I do agree that an application type is the better
choice.


No it's not, it's a private namespace for
development/experimental purposes and should only be used by
agreement of what it means at boths ends, that's never happened.
x-trees should not be used on the web, and they should not be
used at all now (the vnd. and prs. trees are better for what it
achieves)


Where in that paragraph (specifically that last sentence) do I
mention application/x-javascript?
Yes, the meaning of VALID matters, the more important fact
though is it is only HTML 4 where the above rules come into
play, as most people author tag-soup, or other HTML types, the
rules do not exist.


As you say, most people write tag soup. It stands to reason that most
wouldn't understand (or care about) the distinction between invalid
and incorrect. I used 'invalid' as a synonym of wrong. It didn't
occur to me at the time that it could be interpreted any other way.
It is for that reason that I refer (and anticipate references) to
validation of a HTML document explictly.

Mike

--
Michael Winter
M.******@blueyonder.co.invalid (replace ".invalid" with ".uk")
Jul 20 '05 #18
On Sun, 07 Dec 2003 13:31:41 GMT, Michael Winter
<M.******@blueyonder.co.invalid> wrote:
That's why I said: "though that doesn't necessarily make it correct".
I realise that they have no say over the MIME type for JS. However, I
would of thought that they made the decision to use that type in
their specifications for a good reason.
Such as? - If the reason is "it's what works in current UA's" then
others are free to argue that the defaulting to ecmascript for
intrinsic events is just as legitimate.
Where in that paragraph (specifically that last sentence) do I
mention application/x-javascript?


sorry, I misread an "an" for a "the" there, and thought you were
talking about the x-javascript one.

Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/

Jul 20 '05 #19
Jim Ley wrote:
Michael Winter wrote:
The HTML specification itself uses text/javascript as the MIME type
for JavaScript (though that doesn't necessarily make it correct).
Good for it, it has no change control or anything else over
javascript,


It is used in the Recommendation because it is widely supported.
The HTML WG has no more status than me or you on what is the mime-type
for js, you'll note the SVG WG say it's text/ecmascript.


You know that text/ecmascript targets a different language. Besides,
that is not standardized as well. Since the W3C does not watch over
either ECMAScript or JavaScript, as you wrote before (but ECMA does),
one of W3C's working groups is not the appropriate standardization
board to decide what is the proper MIME type for JavaScript. And last
but not least, what about

http://lists.w3.org/Archives/Public/...2Aug/0008.html

?
PointedEars
--
The Internet is filled with people trying to make a name for themselves by
breaking your code, crashing your site, posting inappropriate content, and
otherwise making your day interesting. (from: The PHP manual, 5. Security)
Jul 20 '05 #20
Janwillem Borleffs wrote:
<de*******@no.spam.com> schreef in bericht
news:3f***************@news.md.comcast.giganews.co m...
Please shorten your attribution to one line, leaving
out information not vital to follow the discussion.
I see some code examples like this:

<DIV onmouseover="this.style.background='blue'">

and other code examples like this:

<DIV onmouseover="javascript:this.style.background='blu e'">

Which way is more proper? Or are both ways perfectly fine? Are there any
specifications that discuss when "javascript:" should be put in front of

code?

^^
OE Quotefix repairs borken quotes. OTOH, you could switch
to NetNews client software that works by default.
The first one is the proper way,
The statement is correct.
because the onmouseover attribute (and other event handlers)
expects the value to contain JS code only.
However, the explanation is awfully wrong.

First, values of the intrinsic event handler attributes may be of *any*
script language. The default script language can be specified with the

<meta http-equiv="Content-Script-Type" content="...">

element, defining it with the value of the `content' attribute. For
JavaScript, a value of `text/javascript' is appropriate.

The default script language is text/javascript in Mozilla/5.0 and
JScript (text/jscript?) in Internet Explorer.
Second, the `javascript:' within the event handler is considered one of
the following:

A) UAs using the IE browser component: A label specifying the script
language
B) Other UAs: A label that is ignored since no statement refers to it.
C) Incorrect syntax, which triggers a script error.

*That* is why it is wrong.
What you will also see very often, is the usage of the javascript: pseudo
protocol in anchors:


Third, `javascript:' is not a pseudo protocol (I would like give the
person who introduced that ridiculous term a good kick in the ass),
but an URI scheme.
PointedEars
Jul 20 '05 #21
Jim Ley wrote:
Michael Winter wrote:
For JavaScript, the MIME type is text/javascript [...]


Could you cite the relevant RFC which indicates this please? for
JavaScript (capatilised like that) the relevant one would be
application/x-javascript surely?


No for both answers. Alas, there is no standardized MIME type for
JavaScript code. Nevertheless, text/javascript is, in contrast to
application/x-javascript, widely supported and therefore used in
the HTML 4.01 Specification itself.
PointedEars
Jul 20 '05 #22
Thomas 'PointedEars' Lahn <Po*********@web.de> writes:
The default script language is text/javascript in Mozilla/5.0 and
JScript (text/jscript?) in Internet Explorer.
Both text/jscript and text/javascript will work in IE. They both
trigger the same (JScrip) interpreter.
Second, the `javascript:' within the event handler is considered one of
the following:

A) UAs using the IE browser component: A label specifying the script
language
B) Other UAs: A label that is ignored since no statement refers to it.
It can, but then it will fail in IE.
C) Incorrect syntax, which triggers a script error.
Which will not happen in any browser I have seen, since it would require
the browser to interpret the contents as something other than Javascript,
and only IE allows other languages at all.
*That* is why it is wrong.
For some value of "wrong" :)
Third, `javascript:' is not a pseudo protocol (I would like give the
person who introduced that ridiculous term a good kick in the ass),
but an URI scheme.


So, http is a protocol, but http: is an URI scheme, correct?

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
Jul 20 '05 #23
On Mon, 08 Dec 2003 00:56:36 +0100, Thomas 'PointedEars' Lahn
<Po*********@web.de> wrote:
It is used in the Recommendation because it is widely supported.
That doesn't work, so are lots of HTML features not included in the
spec.
The HTML WG has no more status than me or you on what is the mime-type
for js, you'll note the SVG WG say it's text/ecmascript.


You know that text/ecmascript targets a different language.


WHAT? what "different language" does it target?
Besides, that is not standardized as well.
Indeed, but it's widely supported... these should not be using any
examples that are wrong.
http://lists.w3.org/Archives/Public/...2Aug/0008.html


What about it? It's not different to what I was arguing here, it's
wrong for W3 WG's to recommend unregistered mime-types not in the x-
tree.

Jim.
--
comp.lang.javascript FAQ - http://jibbering.com/faq/

Jul 20 '05 #24
"Lasse Reichstein Nielsen" <lr*@hotpop.com> wrote in message
news:y8**********@hotpop.com...
<snip>
C) Incorrect syntax, which triggers a script error.


Which will not happen in any browser I have seen, since it would
require the browser to interpret the contents as something other
than Javascript, and only IE allows other languages at all.

<snip>

According to my Netscape JavaScript 1.5 reference labels were introduced
in JavaScript 1.2 so in principal an environment supporting only
JavaScript <= 1.1 probably will consider event handling attribute code
prefixed with "javascript:" as a syntax error. But then, anyone still
using a JavaScript <= 1.1. UA is likely to be finding its use nearly
totally unproductive anyway.

Richard.
Jul 20 '05 #25
JRS: In article <3F**************@PointedEars.de>, seen in
news:comp.lang.javascript, Thomas 'PointedEars' Lahn
<Po*********@web.de> posted at Mon, 8 Dec 2003 00:38:14 :-
Janwillem Borleffs wrote:
<de*******@no.spam.com> schreef in bericht
news:3f***************@news.md.comcast.giganews.co m...


Please shorten your attribution to one line, leaving
out information not vital to follow the discussion.


Please stop nagging on this matter.

There is no known support for your attitude in applicable standards
documents; nor in the Newsgroup FAQ.

Please also include in your own attributions sufficient material to put
the quoted material fully in context for those using off-line
newsreaders, when re-quoted in a further response.

--
© John Stockton, Surrey, UK. ?@merlyn.demon.co.uk Turnpike v4.00 MIME ©
Web <URL:http://www.uwasa.fi/~ts/http/tsfaq.html> -> Timo Salmi: Usenet Q&A.
Web <URL:http://www.merlyn.demon.co.uk/news-use.htm> : about usage of News.
No Encoding. Quotes before replies. Snip well. Write clearly. Don't Mail News.
Jul 20 '05 #26

This thread has been closed and replies have been disabled. Please start a new discussion.

Similar topics

6
by: Yvan J. Gagnon | last post by:
I am currenly developing a web site using Macromedia fireworks, and am trying to figure out a way (through hand-coding) of attaching a javascript function (onClick="doit=false") to each of the...
9
by: David D. | last post by:
Does the file extension matter when including a JavaScript file in an HTML page? Normally, one would include a JavaScript file in an HTML page using <script src="foo.JS" type="text/javascript">...
3
by: TC | last post by:
Hello, I am using the script below to open a new window and once opened, redirect to that open window from the original window: private void btnNewPDFWindow_Click(object sender,...
1
by: Slavo Smutny | last post by:
Hi, which is better approach to store my JavaScript code, to store it in separate .js file or to embed the code within HTML attributes (e.g. <p onclick="javascript:submit();">click this</p>)? I...
2
by: TastyKarma | last post by:
Was hoping somebody might have experienced this before. I have client-side javascript in my aspx files. For some reason when I place the "debugger;" keyword in my javascript, Visual Studio no...
3
by: kaston3 | last post by:
I use screen.width to check escreen resolution and then document.write to write different width tables accordingly. It all works OK with Mozilla Firefox, however it seems that in IExplorer it only...
1
by: morgan.chengmo | last post by:
Hi, I am wandering whether all javascript code in one page is executed in one thread. I know that javascript has no threading mechansim. No way to tell which thread is running by code iteself. ...
10
by: FAQ server | last post by:
----------------------------------------------------------------------- FAQ Topic - How do I protect my javascript code? ----------------------------------------------------------------------- ...
2
drhowarddrfine
by: drhowarddrfine | last post by:
When I visit this board, I see this frequently: <script language=javascript> but "language=javascript" was deprecated in 1996. So, why do people still use it? It doesn't do anything.
0
by: Charles Arthur | last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
0
by: aa123db | last post by:
Variable and constants Use var or let for variables and const fror constants. Var foo ='bar'; Let foo ='bar';const baz ='bar'; Functions function $name$ ($parameters$) { } ...
0
by: ryjfgjl | last post by:
If we have dozens or hundreds of excel to import into the database, if we use the excel import function provided by database editors such as navicat, it will be extremely tedious and time-consuming...
0
by: ryjfgjl | last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
0
BarryA
by: BarryA | last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
1
by: nemocccc | last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
1
by: Sonnysonu | last post by:
This is the data of csv file 1 2 3 1 2 3 1 2 3 1 2 3 2 3 2 3 3 the lengths should be different i have to store the data by column-wise with in the specific length. suppose the i have to...
0
by: Hystou | last post by:
There are some requirements for setting up RAID: 1. The motherboard and BIOS support RAID configuration. 2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
0
jinu1996
by: jinu1996 | last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...

By using Bytes.com and it's services, you agree to our Privacy Policy and Terms of Use.

To disable or enable advertisements and analytics tracking please visit the manage ads & tracking page.