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

[Reply Via Newsgroup]

Re: Body tag preventing 'window.open' from executing

alanstew wrote:
[color=blue]
> 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[/color]

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

randelld

[alanstew]

Re: Body tag preventing 'window.open' from executing (with code added)

Reply Via Newsgroup <reply-to-newsgroup@pleas e.com> wrote in message news:<wvJdc.635 64$oR5.22093@pd 7tw3no>...[color=blue]
> alanstew wrote:
>[color=green]
> > 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[/color]
>
> Perhaps including a URL or some of your code below might help someone to
> help you...
>
> randelld[/color]

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=clientEventH andlersJS LANGUAGE=javasc ript>
<!--
function LogIn_onsubmit( )
{
if ((document.LogI n.txtUser.value == "") ||
(document.LogIn .txtPass.value == ""))
{
window.alert("U sername AND Password must be entered!!");
}
}
function window_onload()
{
//Save Browser values for future use.
document.LogIn. hidBrowserName. value = strCsBrowser;

//Set focus.
document.LogIn. txtUser.focus() ;
}
-->
</SCRIPT>
<SCRIPT LANGUAGE="javas cript">
<!--
function ContactUs()
{
window.location = "mailer.asp?Sou rce=Login";
}

function PassHelp()
{
var w = 400;
var h = 300;
var x = Math.round((scr een.availWidth - w) / 2);
var y = Math.round((scr een.availHeight - h) / 2);

window.open('he lpmailer.asp', 'windowName', 'left=' + x + ',top=' + y
+ ',width=' + (w - 5) + ',height=' + (h - 33));
}
-->
</SCRIPT>

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

<HTML>
<title>Log In</title>
<BODY leftmargin="70" bgColor=lightye llow LANGUAGE=javasc ript
onload="return window_onload() ">
<FORM method="POST" name="LogIn" LANGUAGE=javasc ript onsubmit="retur n
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">U sername:
</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">P assword:
</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:gr een" Value="
Enter " Name="btnSubmit "></TD>
<TD align="left" width=5></TD>
<TD align="left"><I NPUT TYPE=reset style="Color:gr een" Value=Reset
Name="btnReset" ></TD>
</TR>
</Table>
</FORM>
<INPUT TYPE=hidden NAME=hidBrowser Name value="">
<br>
<font style="font-size:9pt;font-family:Times">
<A HREF="javascrip t:PassHelp()" title="Click to get help with
forgotten username/password.">User name/Password Help</A></font>
<br>
<font style="font-size:9pt;font-family:Times">
<A HREF="javascrip t:ContactUs()" title="Click to send us an email with
questions or comments.">Cont act Us</A></font>
</BODY>
</HTML>

[Ivo]

Re: Body tag preventing 'window.open' from executing (with code added)

> > alanstew wrote:[color=blue]
> 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=clientEventH andlersJS LANGUAGE=javasc ript>[/color]
<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:[color=blue]
> <BODY leftmargin="70" bgColor=lightye llow
> LANGUAGE=javasc ript onload="return window_onload() ">[/color]

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[color=blue]
> <A HREF="javascrip t:ContactUs()" title="Click to send us an
> email with questions or comments.">Cont act Us</A></font>[/color]
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

[alanstew]

Re: Body tag preventing 'window.open' from executing (with code added)

"Ivo" <no@thank.you > wrote in message news:<407b5012$ 0$64639$4a44175 0@news.wanadoo. nl>...[color=blue][color=green][color=darkred]
> > > alanstew wrote:[/color]
> > 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=clientEventH andlersJS LANGUAGE=javasc ript>[/color]
> <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">[/color]

OK, Ivo, I confess, I've been using Microsoft DevelopmentEnvi ronment
and it puts those tags in, and I just, well, used them.
[color=blue]
> 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:[color=green]
> > <BODY leftmargin="70" bgColor=lightye llow
> > LANGUAGE=javasc ript onload="return window_onload() ">[/color][/color]

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!
[color=blue]
> 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.[/color]

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?
[color=blue]
> 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.
>[/color]
[color=blue]
> 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 >
>[/color]
Thanks for the informational urls, I've bookmarked them already.[color=blue]
>
> Also, unrelated to your current question, links like[color=green]
> > <A HREF="javascrip t:ContactUs()" title="Click to send us an
> > email with questions or comments.">Cont act Us</A></font>[/color]
> 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 >
>[/color]
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
[color=blue]
> HTH
> Ivo[/color]

[Michael Winter]

Re: Body tag preventing 'window.open' from executing (with code added)

On 12 Apr 2004 22:55:20 -0700, alanstew <alan_stew@yaho o.com> wrote:
[color=blue]
> "Ivo" <no@thank.you > wrote in message
> news:<407b5012$ 0$64639$4a44175 0@news.wanadoo. nl>...[/color]

[snip]
[color=blue][color=green]
>> 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:
>>[color=darkred]
>>>> alanstew wrote:
>>>
>>> <BODY leftmargin="70" bgColor=lightye llow
>>> LANGUAGE=javasc ript onload="return window_onload() ">[/color][/color]
>
> 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.[/color]

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.o rg/>
[color=blue]
> BUT, you're right, when I take those out, it still works....and the
> "<script type="text/javascript">" works also![/color]

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

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.Winter@blueyo nder.co.invalid (replace ".invalid" with ".uk" to reply)

[alanstew]

Re: Body tag preventing 'window.open' from executing (with code added)

Michael Winter <M.Winter@bluey onder.co.invali d> wrote in message news:<opr6e69hg c5vklcq@news-text.blueyonder .co.uk>...[color=blue]
> On 12 Apr 2004 22:55:20 -0700, alanstew <alan_stew@yaho o.com> wrote:
>[color=green]
> > "Ivo" <no@thank.you > wrote in message
> > news:<407b5012$ 0$64639$4a44175 0@news.wanadoo. nl>...[/color]
>
> [snip]
>[color=green][color=darkred]
> >> 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=lightye llow
> >>> LANGUAGE=javasc ript onload="return window_onload() ">[/color]
> >
> > 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.[/color]
>
> 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.o rg/>
>[color=green]
> > BUT, you're right, when I take those out, it still works....and the
> > "<script type="text/javascript">" works also![/color]
>
> Though both may work, Ivo's suggestions are infinitely better.
>[color=green]
> > [...] and since you've been right about everything else, does the onload
> > HAVE to return something?[/color]
>
> 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[/color]

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

[Richard Cornford]

Re: Body tag preventing 'window.open' from executing (with code added)

alanstew wrote:
<snip>[color=blue]
> 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".[/color]

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.
[color=blue]
> If two ways work, WHY does it MATTER which is used?[/color]

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).
[color=blue]
> 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?[/color]

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).
[color=blue]
> Not trying to start a war, but really,
> in my life, I need results not manners,
> if you get the way I'm driftin'[/color]

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.

[alanstew]

Re: Body tag preventing 'window.open' from executing (with code added)

"Richard Cornford" <Richard@litote s.demon.co.uk> wrote in message news:<c5jssd$km 6$1$8300dec7@ne ws.demon.co.uk> ...[color=blue]
> alanstew wrote:
> <snip>[color=green]
> > 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".[/color]
>
> 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.
>[color=green]
> > If two ways work, WHY does it MATTER which is used?[/color]
>
> 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).
>[color=green]
> > 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?[/color]
>
> 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).
>[color=green]
> > Not trying to start a war, but really,
> > in my life, I need results not manners,
> > if you get the way I'm driftin'[/color]
>
> 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.[/color]

Thanks Richard...very cogent....belie ve 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