JavaScript confirmation dialog

[Tomislav]

Hello,

I tried to use "javascript:return confirm();" function in following
manner ( triggered by form onSubmit event ):

**

<form method="post" action="mail.php" onSubmit="javascript:return
confirm('Do you really want to send this order ?);">

**

When I include Submit button in this form form action should be
performed after "OK" is clicked on confirmation dialog e.g. "mail.php"
should be then executed. Only thing is that it is executed directly
without any confirm windows.

JS is enabled and browser is Firefox 2.0. What is more I frequently use
JS in my designs and this very site I am working on now has plenty of JS
included. That is a bit confusing - that code above does not work.

Did I miss something when I incorporated JS in form ?

Thanks,

Tomislav

 

[VK]

I tried to use "javascript:return confirm();" function in following
manner ( triggered by form onSubmit event ):

**

<form method="post" action="mail.php" onSubmit="javascript:return
confirm('Do you really want to send this order ?);">

**

See my P.S. comment at
http://groups.google.com/group/comp.lang.javascript/msg/06f9475caf8ee778
While IE tolerates javascript: pseudo-protocol misuse, many other UAs
do not.

 

[VK]

It isn't a protocol, it's a label. Spurious but mostly harmless.

I am taking my hat off over such creative interpretation. Really, all
these years I never thought of onclick="javascript:something()" as of
a Javascript label in front of a statement. I guess such view was
always shadowed by the usage in links like
href="javascript:something()". - I hope there is no doubts that in the
latter case it is pseudo-protocol?

However cool such interpretation would be (and it is cool) in the
original Microsoft proposal - who is the inventor of this syntax - it
is spelled as "place javascript: before your JScript code" so
"javascript:" part is clearly excluded from the code itself - at least
in mind of authors of the proposal. I remind that it is one of ways
Microsoft suggested to use for mixed pages where both VBScript and
JScript are used. If the first script block on the page is VBScript
then all consecutive script blocks w/o explicit type or language
declaration _and_ all intrinsic event handlers on the page will be
parsed using VBScript engine. Naturally if they are written in JScript
the whole page will get broken. The simplest way would be of course to
support meta tag Script-Content-Type but it would be too easy for such
big corporation So they suggested a few alternate solutions for
the developers:
1) If intrinsic event handlers are written in JScript then:
a) ensure that the very first script block on the page is JScript, one
may simply place bogus block before anything else:
<script type="text/javascript"></script>
b) ensure that all consecutive script blocks have type or language
declaration: or at least all blocks using VBScript

2) If the page is a holly mix of VBScript and JScript coding including
intrinsic event handlers - but with VBScript as the default one - then
place a marker in intrinsic event handlers like
onclick="javascript:mycode()"
Respectively they instructed the engine to treat that javascript: as a
marker "JScript code further follows" which is obviously out of any
connection with Javascript labels.

I can tell that IE7 is much smarter than IE4-6 with its code type
detection. Alas I also can tell that javascript: "prefix" in event
handlers had time to become another classical Cargo Cult phenomenon.

 

[Lee]

VK said:

I am taking my hat off over such creative interpretation. Really, all
these years I never thought of onclick="javascript:something()" as of
a Javascript label in front of a statement. I guess such view was
always shadowed by the usage in links like
href="javascript:something()". - I hope there is no doubts that in the
latter case it is pseudo-protocol?

However cool such interpretation would be (and it is cool) in the
original Microsoft proposal - who is the inventor of this syntax - it
is spelled as "place javascript: before your JScript code" so
"javascript:" part is clearly excluded from the code itself - at least
in mind of authors of the proposal.

Microsoft took advantage of the existing label syntax to give
special meanings to certain label values. This had the
advantage that any browser that didn't interpret their meaning
would simply ignore it as a valid (albeit useless) label.

onclick="userAbort:self.close()"

is also valid, of course.


--