Frames using javascripts to open external sites cause problems in IE (not Netscape)

[sdvoranchik]

We have an application that contains links that run javascripts to
create pages in a separate frame. When these links open an external
site, it causes the javascripts to no longer function. When we
modified the links that invoke the javascripts from:
<a href=javascript: top.doSomething> text </a>
To:
<span onclick=javascript:top.doSomething> text </span>
The javascripts worked properly. Any ideas on why this now works or
other solutions? This site works fine when viewed using Netscape
4.76.

[HikksNotAtHome]

In article <b9**************************@posting.google.com >,
sd*********@cizer.com (sdvoranchik) writes:

We have an application that contains links that run javascripts to
create pages in a separate frame. When these links open an external
site, it causes the javascripts to no longer function. When we
modified the links that invoke the javascripts from:
<a href=javascript: top.doSomething> text </a>
http://www.jibbering.com/faq/#FAQ4_24
To:
<span onclick=javascript:top.doSomething> text </span>
The javascripts worked properly. Any ideas on why this now works or
other solutions? This site works fine when viewed using Netscape
4.76.

NN4 supports onclick on a span?

<span onclick="alert('I support onclick in a span')">Test</span> gives no alert
in NN4.77, so what "works fine"? And it depends on your definition of "works
fine".
--
Randy

[Thomas 'PointedEars' Lahn]

sdvoranchik wrote:

We have an application that contains links that run javascripts to
create pages in a separate frame. When these links open an external
site, it causes the javascripts to no longer function.
"Does not work" is a useless error description. [psf 4.11]

You have had a look into the JavaScript Console and/or enabled
the display of script errors before posting, have you not?
When we modified the links that invoke the javascripts from:
<a href=javascript: top.doSomething> text </a>
You have been misusing the "javascript:" URI scheme. It is designed
to generate (HTML) content from evaluated values, not to run code that
does not do so. It is likely that, if top.doSomething is a method,
a temporary document will be created with the return value of
top.doSomething(...) as its content or with the definition string of
top.doSomething(...) if you leave the call operator's parantheses out.
If it is a non-function property, that document should contain its value.

Since a URI is expected, you are not allowed to use unescaped spaces and
special characters within it, so if you did, it explains why it did not
work.
To:
<span onclick=javascript:top.doSomething> text </span>

Since "javascript:" is a URI scheme, it does not belong into intrinsic
event handlers' attribute values. Only Internet Explorer considers
"javascript:" to be a semantical label defining the scripting language
for that handler, other UAs will either consider it a label with no
meaning and ignore it because there is no jump statement to refer to it,
or show a script error if that language construct is unsupported for
some reason. And (X)HTML attribute values need to be delimited by
single or double quotes, if they are not only composed of a small subset
of characters, so write

<span onclick="top.doSomething">text</span>

instead (use ' within the script code if you need string delimiters) and
declare the default scripting language for event handlers within the
HEAD element:

<meta http-equiv="Content-Script-Type" content="text/javascript">

What about users without support for client-side scripting?
PointedEars