Body tag preventing 'window.open' from executing

alanstew

With the body tag calling out 'window onload', a function with a
'window.open' fails at the 'window.open' line. If I cut out the body
tag, the function executes as normal.
At first I thought it was the entire function failing, but I tested
with alerts and found that it was only the 'window.open' that fails to
execute.
The function is being called by a link, and I suspected some problem
with the body alink/vlink but after cutting that out I saw no
improvement.
There is also a form in the page, and I need the 'window onload' to
set the focus to the proper control, thus I HAVE to have the Body tag,
right?

I have a workaround, but WHAT is causing this (seemingly) bizarre
behavior?

Thanks for any clues or outright explanations.
Alan

Jul 23 '05 #1

Subscribe Post Reply

2391

Reply Via Newsgroup

alanstew wrote:

With the body tag calling out 'window onload', a function with a
'window.open' fails at the 'window.open' line. If I cut out the body
tag, the function executes as normal.
At first I thought it was the entire function failing, but I tested
with alerts and found that it was only the 'window.open' that fails to
execute.
The function is being called by a link, and I suspected some problem
with the body alink/vlink but after cutting that out I saw no
improvement.
There is also a form in the page, and I need the 'window onload' to
set the focus to the proper control, thus I HAVE to have the Body tag,
right?

I have a workaround, but WHAT is causing this (seemingly) bizarre
behavior?

Thanks for any clues or outright explanations.
Alan

Perhaps including a URL or some of your code below might help someone to
help you...

randelld

Jul 23 '05 #2

alanstew

Reply Via Newsgroup <re****************@please.com> wrote in message news:<wvJdc.63564$oR5.22093@pd7tw3no>...

alanstew wrote:
With the body tag calling out 'window onload', a function with a
'window.open' fails at the 'window.open' line. If I cut out the body
tag, the function executes as normal.
At first I thought it was the entire function failing, but I tested
with alerts and found that it was only the 'window.open' that fails to
execute.
The function is being called by a link, and I suspected some problem
with the body alink/vlink but after cutting that out I saw no
improvement.
There is also a form in the page, and I need the 'window onload' to
set the focus to the proper control, thus I HAVE to have the Body tag,
right?

I have a workaround, but WHAT is causing this (seemingly) bizarre
behavior?

Thanks for any clues or outright explanations.
Alan

Perhaps including a URL or some of your code below might help someone to
help you...

randelld

OK, here is a summary of the page, once again, taking OUT the body
tag, 'window.open' returns to life...putting it back, 'window.open'
won't.
Thanks...
<SCRIPT ID=clientEventHandlersJS LANGUAGE=javascript>

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

</SCRIPT>

<%%>
<script>SetUp()</script>
<%
If Trim(Request.Form("txtPass")) <> "" And
Trim(Request.Form("txtUser")) <> "" Then
'Here where the log in validation code goes.
End If
%>

<HTML>
<title>Log In</title>
<BODY leftmargin="70" bgColor=lightyellow LANGUAGE=javascript
onload="return window_onload()">
<FORM method="POST" name="LogIn" LANGUAGE=javascript onsubmit="return
LogIn_onsubmit()">
<font color=green style="font-size:16pt;font-family:Times"><I>Please
Login</I></font><br><br>
<font color=green style="font-size:10pt;font-family:Times">Username:
</font><br>
<INPUT TYPE=text style="font-size:9pt;font-family:Times" NAME=txtUser>
<BR><BR>
<font color=green style="font-size:10pt;font-family:Times">Password:
</font><br>
<INPUT TYPE=Password style="font-size:9pt;font-family:Times"
NAME=txtPass>
<BR><BR>
<TABLE border=0>
<TR>
<TD align="center"><INPUT TYPE=submit style="Color:green" Value="
Enter " Name="btnSubmit"></TD>
<TD align="left" width=5></TD>
<TD align="left"><INPUT TYPE=reset style="Color:green" Value=Reset
Name="btnReset"></TD>
</TR>
</Table>
</FORM>
<INPUT TYPE=hidden NAME=hidBrowserName value="">
<br>
<font style="font-size:9pt;font-family:Times">
<A HREF="javascript:PassHelp()" title="Click to get help with
forgotten username/password.">Username/Password Help</A></font>
<br>
<font style="font-size:9pt;font-family:Times">
<A HREF="javascript:ContactUs()" title="Click to send us an email with
questions or comments.">Contact Us</A></font>
</BODY>
</HTML>

Jul 23 '05 #3

Ivo

> > alanstew wrote:

OK, here is a summary of the page, once again, taking OUT the body
tag, 'window.open' returns to life...putting it back, 'window.open'
won't.
Thanks...
<SCRIPT ID=clientEventHandlersJS LANGUAGE=javascript> <snip rest>
That code is so full of bad habits that it is not possible to determine the
actual fault producing the error you reported. Quite possibly, other
problems become visible once this is solved.
1. Scripts don't have id's.
2. Scripts don't have languages.
3. Scripts have types. Usually like this:
<script type="text/javascript">

In the code as posted, the script is located before the <HTML> opening tag.
Then comes a <title> element, which really should be inside a <head>, and
then this crazy body tag: <BODY leftmargin="70" bgColor=lightyellow
LANGUAGE=javascript onload="return window_onload()">
The leftmargin attribute is supported by less and less browsers, as is the
bgcolor. They are being replaced by stylesheets. The onload event handler
may run some javascript, but what would you like any return value to do?
Btw, function window_onload() does not return anything.
The language attribute is certainly confusing. The <body> element should NOT
contain a language attribute, and if it ever did, it should not be a script.
I am quite hopeful that lights will go green if you remove it.

For reference:
On html, head, title and body tags:
<URL: http://www.w3.org/TR/REC-html40/struct/global.html >
On scripts:
<URL: http://www.w3.org/TR/REC-html40/interact/scripts.html >
Also, unrelated to your current question, links like <A HREF="javascript:ContactUs()" title="Click to send us an
email with questions or comments.">Contact Us</A></font>

may look very inviting, but will lead nowhere for users without javascript
(by restriction or choice). See the FAQ of this newsgroup:
<URL: http://jibbering.com/faq/#FAQ4_24 >

HTH
Ivo

Jul 23 '05 #4

alanstew

"Ivo" <no@thank.you> wrote in message news:<40***********************@news.wanadoo.nl>.. .

alanstew wrote: OK, here is a summary of the page, once again, taking OUT the body
tag, 'window.open' returns to life...putting it back, 'window.open'
won't.
Thanks...
<SCRIPT ID=clientEventHandlersJS LANGUAGE=javascript>

<snip rest>
That code is so full of bad habits that it is not possible to determine the
actual fault producing the error you reported. Quite possibly, other
problems become visible once this is solved.
1. Scripts don't have id's.
2. Scripts don't have languages.
3. Scripts have types. Usually like this:
<script type="text/javascript">

OK, Ivo, I confess, I've been using Microsoft DevelopmentEnvironment
and it puts those tags in, and I just, well, used them.
In the code as posted, the script is located before the <HTML> opening tag.
Then comes a <title> element, which really should be inside a <head>, and
then this crazy body tag:
<BODY leftmargin="70" bgColor=lightyellow
LANGUAGE=javascript onload="return window_onload()">

That's what MDE does when you click to add a client object event. I
never questioned it before, after all, Microsoft, right? They MUST
know what they're doing.....and gosh durn it...it works. BUT, you're
right, when I take those out, it still works....and the "<script
type="text/javascript">" works also!
The leftmargin attribute is supported by less and less browsers, as is the
bgcolor. They are being replaced by stylesheets. The onload event handler
may run some javascript, but what would you like any return value to do?
Btw, function window_onload() does not return anything.
I'm not really trying to return anything, just put the cursor in the
right text box when the page loads...and since you've been right about
everything else, does the onload HAVE to return something?
The language attribute is certainly confusing. The <body> element should NOT
contain a language attribute, and if it ever did, it should not be a script.
I am quite hopeful that lights will go green if you remove it.
For reference:
On html, head, title and body tags:
<URL: http://www.w3.org/TR/REC-html40/struct/global.html >
On scripts:
<URL: http://www.w3.org/TR/REC-html40/interact/scripts.html >
Thanks for the informational urls, I've bookmarked them already.
Also, unrelated to your current question, links like
<A HREF="javascript:ContactUs()" title="Click to send us an
email with questions or comments.">Contact Us</A></font> may look very inviting, but will lead nowhere for users without javascript
(by restriction or choice). See the FAQ of this newsgroup:
<URL: http://jibbering.com/faq/#FAQ4_24 >

Sheesh, right again Ivo, I've reconstructed for the reasons you
mention, but INSIDE the members area, we're requiring javascript be
enabled, so I'll keep using that on the inside where I try to maintain
my illusion of control.
In summary, thanks very much....can you tell I'm a slash and burn
type? That's why I need this newsgroup, cause I'm an undisciplined
flailer, but I appreciate people like you who actually take the time
to help us 'monkey see, monkey do' types.
Finally, the REAL problem turned out to be that some dork enabled
popup blocking on my machine. There was an interesting thread about
it on this group just the other day....
Alan
HTH
Ivo

Jul 23 '05 #5

Michael Winter

On 12 Apr 2004 22:55:20 -0700, alanstew <al*******@yahoo.com> wrote:

"Ivo" <no@thank.you> wrote in message
news:<40***********************@news.wanadoo.nl>.. .
[snip]

In the code as posted, the script is located before the <HTML> opening
tag.
Then comes a <title> element, which really should be inside a <head>,
and then this crazy body tag:
alanstew wrote:

<BODY leftmargin="70" bgColor=lightyellow
LANGUAGE=javascript onload="return window_onload()">

That's what MDE does when you click to add a client object event. I
never questioned it before, after all, Microsoft, right? They MUST
know what they're doing.....and gosh durn it...it works.

You'd hope that Microsoft knew what they were doing.

Most of the things that Ivo singles out in your HTML are proprietary
attributes that only IE understands and everything else ignores. It's
actually invalid HTML as passing it though the World Wide Web Consortium's
(W3C) validator will show you:

<URL:http://validator.w3c.org/>
BUT, you're right, when I take those out, it still works....and the
"<script type="text/javascript">" works also!
Though both may work, Ivo's suggestions are infinitely better.
[...] and since you've been right about everything else, does the onload
HAVE to return something?

No. When intrinsic events return a value, that value is evaluated as a
boolean. Some events can be cancelled, such as clicks, and the boolean
decides whether cancellation should occur (false meaning to cancel). As
you can't, and shouldn't be able to, cancel the load event, returning a
value does nothing.

[snip]

Hope that helps,
Mike

--
Michael Winter
M.******@blueyonder.co.invalid (replace ".invalid" with ".uk" to reply)

Jul 23 '05 #6

alanstew

Michael Winter <M.******@blueyonder.co.invalid> wrote in message news:<op**************@news-text.blueyonder.co.uk>...

On 12 Apr 2004 22:55:20 -0700, alanstew <al*******@yahoo.com> wrote:
"Ivo" <no@thank.you> wrote in message
news:<40***********************@news.wanadoo.nl>.. .

[snip]
In the code as posted, the script is located before the <HTML> opening
tag.
Then comes a <title> element, which really should be inside a <head>,
and then this crazy body tag:

> alanstew wrote:

<BODY leftmargin="70" bgColor=lightyellow
LANGUAGE=javascript onload="return window_onload()">

That's what MDE does when you click to add a client object event. I
never questioned it before, after all, Microsoft, right? They MUST
know what they're doing.....and gosh durn it...it works.

You'd hope that Microsoft knew what they were doing.

Most of the things that Ivo singles out in your HTML are proprietary
attributes that only IE understands and everything else ignores. It's
actually invalid HTML as passing it though the World Wide Web Consortium's
(W3C) validator will show you:

<URL:http://validator.w3c.org/>
BUT, you're right, when I take those out, it still works....and the
"<script type="text/javascript">" works also!

Though both may work, Ivo's suggestions are infinitely better.
[...] and since you've been right about everything else, does the onload
HAVE to return something?

No. When intrinsic events return a value, that value is evaluated as a
boolean. Some events can be cancelled, such as clicks, and the boolean
decides whether cancellation should occur (false meaning to cancel). As
you can't, and shouldn't be able to, cancel the load event, returning a
value does nothing.

[snip]

Hope that helps,
Mike

Mike,
Thanks for the link, I'll check that out, when I have time. But I
really am curious why Ivo's suggestions are "infinitely better". If
two ways work, WHY does it MATTER which is used? Is this aesthetics,
or is there a practical reason why I should stop doing things the way
I've been doing them and spend the time to learn a different way? Not
trying to start a war, but really, in my life, I need results not
manners, if you get the way I'm driftin'
Alan

Jul 23 '05 #7

Richard Cornford

alanstew wrote:
<snip>

Thanks for the link, I'll check that out, when I have time. But I
really am curious why Ivo's suggestions are "infinitely better".
Ivo was presented with code that is structurally nonsense, filled with
bogus attributes and deprecated mark-up (and perverse formulations of
that deprecated mark-up); more a sequence of HTML-like mystical
incantations than a hypertext document, and he proposed formally valid
HTML 4 as an alternative.

He also pointed out (as we all do on a regular basis) that javascript:
HREFs cause problems and are completely unnecessary anyway (given that
the oldest browsers in use are version 4 era browsers that support
cancellable onclick attributes on links).

The argument for formally valid HTML is quite simple: A browser
presented with valid HTML can follow a clearly specified series of rules
when creating a corresponding scriptable DOM from that mark-up, so they
produce consistent results. Presented with nonsense HTML the browsers
will make an attempt to error-correct that HTML and build a DOM with the
results. But there are no public standards or specifications for error
correcting, so each browser does it to the best of its abilities, but
inevitably differently. The resulting DOMs are not necessarily
consistent (indeed presented with particular formulations of common
invalid HTML they have been demonstrated to diverge considerably in
structure), and doing anything to provoke browsers into being any more
inconsistent than they already are is asking for trouble.

The javascript HREFs are another known troublemaker. Apart form their
obvious non-functionality when scripting is not supported on the client,
from the point of view of a web browser they represent navigation. And
navigation implies that the current page is finished with and about to
be replaced. Browsers (including IE) take the fact that the current page
is about to be replace as an opportunity to stop maintaining activity on
the current page that is considered costly. Again there are no formal
rules so different browsers behave differently, but following the
activation of a javascript HREF the consequences of the browser getting
the impression that it has been navigated mean that all bets ore off as
to what scriptable activity the browser will still be supporting.

Javascript HREFs were introduced as a kludge that allowed browsers that
had no link onclick event handlers to do things when a link was clicked
that they could not otherwise do. Unfortunately scripting books,
Internet tutorials and the like hang around suggesting particular
practices long after those practices have become outdated and
superfluous. They are now unnecessary, and they have harmful side
effects. Two factors that, in combination, suggest that they should
never be used.
If two ways work, WHY does it MATTER which is used?
Define "work". If one practice is known to provoke problems, while an
alternative avoids them, but an application of the first does not
manifest problems (under the conditions in which it is tested) that does
not render the two equivalent, it just means you got lucky (or are not
testing adequately).
Is this aesthetics, or is there a practical reason why I should
stop doing things the way I've been doing them and spend the
time to learn a different way?
From one point of view the history of the development of programming
practices can be looked upon as the development of techniques for the
management of complexity. Humans are limited in their ability to
perceive complex systems and once complexity gets out of hand chaos
ensues.

Many of the tools used to manage complexity consist of nothing more than
formal disciplines applied to the process of code design and authoring.
They aren't hard and fast rules, or absolute truths, they are tools that
contribute to making it easier to do a difficult task well. And
conscientious programmers don't need much experience to appreciate the
contribution of the application of appropriate formal disciplines to
their work. So they will tent to seek out the disciplines that should be
applied to particular tasks.

In the authoring of HTML one of the obvious disciplines that can be
applied is the creation of documents that conform to the specifications
for HTML. And the results can be directly tested by exposing the
documents to an HTML validator.

As a stage in the development of HTML, validation does not tell you that
the results are good HTML, optimum, ideal or anything beyond that it is
valid, but that does rule out, at a stroke, any and all problems
resulting from invalid HTML. Meaning that if any problems remain you
know to look elsewhere for their cause (and ruling out causes is
normally a huge aid in the solving of problems, because that means that
the problems are less complex than they would be otherwise).
Not trying to start a war, but really,
in my life, I need results not manners,
if you get the way I'm driftin'

Did you get results? Results don't usually prompt questions on
newsgroups. But the application of appropriate formal disciplines to the
process of creation is not about "manners" as such, it is about getting
better quality results, quicker. These concepts don't arise from some
sadistic desire to burden the world with pointless extra tasks, they are
tools, they make life easier, and they are promoted for the benefit of
the people involved.

Richard.

Jul 23 '05 #8

alanstew

"Richard Cornford" <Ri*****@litotes.demon.co.uk> wrote in message news:<c5*******************@news.demon.co.uk>...

alanstew wrote:
<snip>
Thanks for the link, I'll check that out, when I have time. But I
really am curious why Ivo's suggestions are "infinitely better".

Ivo was presented with code that is structurally nonsense, filled with
bogus attributes and deprecated mark-up (and perverse formulations of
that deprecated mark-up); more a sequence of HTML-like mystical
incantations than a hypertext document, and he proposed formally valid
HTML 4 as an alternative.

He also pointed out (as we all do on a regular basis) that javascript:
HREFs cause problems and are completely unnecessary anyway (given that
the oldest browsers in use are version 4 era browsers that support
cancellable onclick attributes on links).

The argument for formally valid HTML is quite simple: A browser
presented with valid HTML can follow a clearly specified series of rules
when creating a corresponding scriptable DOM from that mark-up, so they
produce consistent results. Presented with nonsense HTML the browsers
will make an attempt to error-correct that HTML and build a DOM with the
results. But there are no public standards or specifications for error
correcting, so each browser does it to the best of its abilities, but
inevitably differently. The resulting DOMs are not necessarily
consistent (indeed presented with particular formulations of common
invalid HTML they have been demonstrated to diverge considerably in
structure), and doing anything to provoke browsers into being any more
inconsistent than they already are is asking for trouble.

The javascript HREFs are another known troublemaker. Apart form their
obvious non-functionality when scripting is not supported on the client,
from the point of view of a web browser they represent navigation. And
navigation implies that the current page is finished with and about to
be replaced. Browsers (including IE) take the fact that the current page
is about to be replace as an opportunity to stop maintaining activity on
the current page that is considered costly. Again there are no formal
rules so different browsers behave differently, but following the
activation of a javascript HREF the consequences of the browser getting
the impression that it has been navigated mean that all bets ore off as
to what scriptable activity the browser will still be supporting.

Javascript HREFs were introduced as a kludge that allowed browsers that
had no link onclick event handlers to do things when a link was clicked
that they could not otherwise do. Unfortunately scripting books,
Internet tutorials and the like hang around suggesting particular
practices long after those practices have become outdated and
superfluous. They are now unnecessary, and they have harmful side
effects. Two factors that, in combination, suggest that they should
never be used.
If two ways work, WHY does it MATTER which is used?

Define "work". If one practice is known to provoke problems, while an
alternative avoids them, but an application of the first does not
manifest problems (under the conditions in which it is tested) that does
not render the two equivalent, it just means you got lucky (or are not
testing adequately).
Is this aesthetics, or is there a practical reason why I should
stop doing things the way I've been doing them and spend the
time to learn a different way?

From one point of view the history of the development of programming
practices can be looked upon as the development of techniques for the
management of complexity. Humans are limited in their ability to
perceive complex systems and once complexity gets out of hand chaos
ensues.

Many of the tools used to manage complexity consist of nothing more than
formal disciplines applied to the process of code design and authoring.
They aren't hard and fast rules, or absolute truths, they are tools that
contribute to making it easier to do a difficult task well. And
conscientious programmers don't need much experience to appreciate the
contribution of the application of appropriate formal disciplines to
their work. So they will tent to seek out the disciplines that should be
applied to particular tasks.

In the authoring of HTML one of the obvious disciplines that can be
applied is the creation of documents that conform to the specifications
for HTML. And the results can be directly tested by exposing the
documents to an HTML validator.

As a stage in the development of HTML, validation does not tell you that
the results are good HTML, optimum, ideal or anything beyond that it is
valid, but that does rule out, at a stroke, any and all problems
resulting from invalid HTML. Meaning that if any problems remain you
know to look elsewhere for their cause (and ruling out causes is
normally a huge aid in the solving of problems, because that means that
the problems are less complex than they would be otherwise).
Not trying to start a war, but really,
in my life, I need results not manners,
if you get the way I'm driftin'

Did you get results? Results don't usually prompt questions on
newsgroups. But the application of appropriate formal disciplines to the
process of creation is not about "manners" as such, it is about getting
better quality results, quicker. These concepts don't arise from some
sadistic desire to burden the world with pointless extra tasks, they are
tools, they make life easier, and they are promoted for the benefit of
the people involved.

Richard.

Thanks Richard...very cogent....believe me, I take it all with more
than a grain of salt...all of you guys are obviously intelligent and
knowledgeable, but I'm driven back to two points: One) It turned out
that the original problem was caused by a popup blocker preventing my
window.open from executing, not by my sloppy code. Two) What should I
do, throw away the Microsoft Developemnt Environment, and rewrite
everything that it has inserted in my pages that is non-standard?
What do you guys use to develop asps?

That's it, even if anybody responds I'm not replying anymore...I've
got too much work to do!!!
Alan

Jul 23 '05 #9

Body tag preventing 'window.open' from executing

Similar topics