471,350 Members | 1,674 Online
Bytes | Software Development & Data Engineering Community
Post +

Home Posts Topics Members FAQ

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

IE6 blocking (safe) content

Jon
Hi there,

In many of my sites I have code like:

<SCRIPT language="JavaScript" type="text/javascript">
<!--
user = "USER";
isp = "DOMAINNAME.XXX";
document.write('<a href=\"mailto:' + user + '@' + isp + '\">');
document.write(user + '@' + isp + '<\/a>');
// -->
</SCRIPT>

on some I simply use:

<a href="javascript:void(window.open('XXX.htm', 'Picture',
'width=XXX,height=XXX'))">Text</a>

to open windows with zoomed pictures therein and

<a href="javascript:window.close()">Close</a> to close them.

However, IE6 thinks this is unsafe!!!! and blocks the script -

I can alter my settings to permit them, but visitors might not....

What can I do to resolve this? Any thoughts?

Thanks

Jon

jon - at - compasscomputing - dot - co - dot - uk
Jul 23 '05 #1
16 1278
"Jon" <jon@SPAM_OFFtheexperts.co.uk> wrote in
news:ci**********@hercules.btinternet.com:
Hi there,

In many of my sites I have code like:

<SCRIPT language="JavaScript" type="text/javascript">
<!--
user = "USER";
isp = "DOMAINNAME.XXX";
document.write('<a href=\"mailto:' + user + '@' + isp + '\">');
document.write(user + '@' + isp + '<\/a>');
// -->
</SCRIPT>

on some I simply use:

<a href="javascript:void(window.open('XXX.htm', 'Picture',
'width=XXX,height=XXX'))">Text</a>

to open windows with zoomed pictures therein and

<a href="javascript:window.close()">Close</a> to close them.

However, IE6 thinks this is unsafe!!!! and blocks the script -

I can alter my settings to permit them, but visitors might not....

What can I do to resolve this? Any thoughts?


Don't ever rely on javascript being enabled.
Use a form plus server-side script to process
'email enquiries', and don't force new windows
on your site visitors.

--
Dave Patton
Canadian Coordinator, Degree Confluence Project
http://www.confluence.org/
My website: http://members.shaw.ca/davepatton/
Jul 23 '05 #2
begin quote from Jon in <ci**********@hercules.btinternet.com>:
Hi there,

In many of my sites I have code like:

<SCRIPT language="JavaScript" type="text/javascript">
<!--
user = "USER";
isp = "DOMAINNAME.XXX";
document.write('<a href=\"mailto:' + user + '@' + isp + '\">');
document.write(user + '@' + isp + '<\/a>');
// -->
</SCRIPT>
[I'm writing from the HTML authoring perspective here, only crossposting
because the original was crossposted and I'm not sure if the OP reads
c.i.w.a.html, though followups are directed to this group.]

Which will break on browsers without scripting. How do you expect these
users to e-mail you? (And no, lack of scripting does not automatically mean
someone is a spammer, and e-mail harvesting bots will almost certainly
become sophisticated enough to get around this in the future.)
on some I simply use:

<a href="javascript:void(window.open('XXX.htm', 'Picture',
'width=XXX,height=XXX'))">Text</a>
Which will break on browsers without scripting, with the added problem that
users get something that looks like a link but doesn't actually take them
anywhere.
to open windows with zoomed pictures therein and

<a href="javascript:window.close()">Close</a> to close them.

However, IE6 thinks this is unsafe!!!! and blocks the script -
However clueless IE's behavior is (and of course, this is a Microsoft
product so it's likely the cluelessness detector will peg), you shouldn't
rely on scripting anyway.
I can alter my settings to permit them, but visitors might not....

What can I do to resolve this? Any thoughts?


Try browsing your own sites with scripting completely disabled for a while,
pretending the option to re-enable it doesn't even exist.

There are situations where depending on a user to have scripting enabled is
patently ridiculous. Essential functionality should never require it on a
properly authored site.

--
Shawn K. Quinn
Jul 23 '05 #3
DU
Jon wrote:
Hi there,

In many of my sites I have code like:

<SCRIPT language="JavaScript" type="text/javascript">
<!--
user = "USER";
isp = "DOMAINNAME.XXX";
document.write('<a href=\"mailto:' + user + '@' + isp + '\">');
document.write(user + '@' + isp + '<\/a>');
// -->
</SCRIPT>

on some I simply use:

<a href="javascript:void(window.open('XXX.htm', 'Picture',
'width=XXX,height=XXX'))">Text</a>

to open windows with zoomed pictures therein and

<a href="javascript:window.close()">Close</a> to close them.

You assume visitors have javascript support is enabled.
You also try to force new windows on visitors.
However, IE6 thinks this is unsafe!!!! and blocks the script -

The script to close the windows you created is excessive.
I can alter my settings to permit them, but visitors might not....

What can I do to resolve this? Any thoughts?

Thanks

Jon

jon - at - compasscomputing - dot - co - dot - uk


There is simple way to permit your pictures without having them blocked
by MSIE 6 or any popup blocker: don't try to force popup windows with
javascript pseudo-protocol (javascript links) which are known to just
create problems. Leave these issues to users themselves.

DU
--
The site said to use Internet Explorer 5 or better... so I switched to
Netscape 7.2 :)
Jul 23 '05 #4
Jon wrote:
Hi there,

In many of my sites I have code like:

<SCRIPT language="JavaScript" type="text/javascript">
<!--
user = "USER";
isp = "DOMAINNAME.XXX";
document.write('<a href=\"mailto:' + user + '@' + isp + '\">');
document.write(user + '@' + isp + '<\/a>');
// -->
</SCRIPT>
This should work fine if you upload the file to an HTTP server and
load it from there. IE will warn you if you attempt to
document.write() any content into a page when loading the page from
your local hard disk (or a network resource mapped to your computer).
<a href="javascript:void(window.open('XXX.htm', 'Picture',
'width=XXX,height=XXX'))">Text</a>
<a href="XXX.htm" target="Picture"
onclick="
window.open(
this.href,
this.target,
'width=XXX,height=XXX'
);
return false;
">Text</a>

Now regardless of whether the visitor has client-side JavaScript
available or not, they should get a new window (unless there popup
blocker is being overly agressive and blocking user-requested popups
as well, which is certainly possible).

If the user does not have client-side JavaScript enabled or available,
the TARGET attribute should, in most user agents, cause a new
window/tab to be opened.

IE doesn't complain about this code.
<a href="javascript:window.close()">Close</a> to close them.
<a href="#" onclick="window.close();return false;">Close</a>

IE doesn't complain about this code (although it may or may not close
the window, depending on which window you try to do it in and if that
window has history).
What can I do to resolve this? Any thoughts?


Test using an HTTP server and write JavaScript that doesn't cripple
the browser if JavaScript isn't available or enabled.

--
Grant Wagner <gw*****@agricoreunited.com>
comp.lang.javascript FAQ - http://jibbering.com/faq

Jul 23 '05 #5
Jon
DU,

<snip>
You assume visitors have javascript support is enabled. Yes! It only relies on javascript to show the email address, I guess if
someone doesn't like javascript then the user can live without an email from
that visitor - when a phone call will surfice!
You also try to force new windows on visitors. Well I don't insist on the visitor opening the window, this facility is
purely there to allow them to see a zoomed in version of the thumbnail image
they have seen - it their concious decision.
The script to close the windows you created is excessive. Excessive but useful, IMHO

<snip>
There is simple way to permit your pictures without having them blocked
by MSIE 6 or any popup blocker: don't try to force popup windows with
javascript pseudo-protocol (javascript links) which are known to just
create problems. Leave these issues to users themselves.


I see what you are saying about javascript links, except I'm not aware that
they "are known to just create problems".

I was hoping for a useful resolve to my technical issue, not insistance that
I change what is a very useful utility!!

Jon

DU
--
The site said to use Internet Explorer 5 or better... so I switched to
Netscape 7.2 :)
Jul 23 '05 #6
Jon
Grant,

I haven't yet tried this, but it looks spot on, thank you

Jon

"Grant Wagner" <gw*****@agricoreunited.com> wrote in message
news:41***************@agricoreunited.com...
Jon wrote:
Hi there,

In many of my sites I have code like:

<SCRIPT language="JavaScript" type="text/javascript">
<!--
user = "USER";
isp = "DOMAINNAME.XXX";
document.write('<a href=\"mailto:' + user + '@' + isp + '\">');
document.write(user + '@' + isp + '<\/a>');
// -->
</SCRIPT>
This should work fine if you upload the file to an HTTP server and
load it from there. IE will warn you if you attempt to
document.write() any content into a page when loading the page from
your local hard disk (or a network resource mapped to your computer).
<a href="javascript:void(window.open('XXX.htm', 'Picture',
'width=XXX,height=XXX'))">Text</a>
<a href="XXX.htm" target="Picture"
onclick="
window.open(
this.href,
this.target,
'width=XXX,height=XXX'
);
return false;
">Text</a>

Now regardless of whether the visitor has client-side JavaScript
available or not, they should get a new window (unless there popup
blocker is being overly agressive and blocking user-requested popups
as well, which is certainly possible).

If the user does not have client-side JavaScript enabled or available,
the TARGET attribute should, in most user agents, cause a new
window/tab to be opened.

IE doesn't complain about this code.
<a href="javascript:window.close()">Close</a> to close them.
<a href="#" onclick="window.close();return false;">Close</a>

IE doesn't complain about this code (although it may or may not close
the window, depending on which window you try to do it in and if that
window has history).
What can I do to resolve this? Any thoughts?


Test using an HTTP server and write JavaScript that doesn't cripple
the browser if JavaScript isn't available or enabled.

--
Grant Wagner <gw*****@agricoreunited.com>
comp.lang.javascript FAQ - http://jibbering.com/faq
Jul 23 '05 #7
On Thu, 16 Sep 2004, Grant Wagner wrote:
Now regardless of whether the visitor has client-side JavaScript
available or not, they should get a new window
Some client agents don't even have one window - let alone multiple
ones.
(unless there popup blocker is being overly agressive ^^^^^^

The aggression level of my popup blocker is for me to determine, not
left to some untrusted document author, thank you.
Test using an HTTP server and write JavaScript that doesn't cripple
the browser if JavaScript isn't available or enabled.


Good advice, indeed.
Jul 23 '05 #8
[attributions restored]

DU <dr*******@hotNOSPAMmail.com> wrote:
The script to close the windows you created is excessive.

Jon <jon@SPAM_OFFtheexperts.co.uk> wrote: Excessive but useful, IMHO
Closing a window is a basic function in any windowing environment, and
there is usually more than one standard way to do it. Users who don't know
how to use basic functions of their browsers will only be confused when
various pages imitate those functions in different ways.
I see what you are saying about javascript links, except I'm not aware that
they "are known to just create problems".


If I want to open a link in a new window, I can do it easily (shift-click
works in most browsers). That is, unless the author has tried to open a new
window for me. Then, the only way to open the link in a new window is to
try to open it normally.
--
Darin McGrew, mc****@stanfordalumni.org, http://www.rahul.net/mcgrew/
Web Design Group, da***@htmlhelp.com, http://www.HTMLHelp.com/

"What is the use of running when you are not on the right road?"
Jul 23 '05 #9
"Alan J. Flavell" wrote:
On Thu, 16 Sep 2004, Grant Wagner wrote:
Now regardless of whether the visitor has client-side JavaScript
available or not, they should get a new window


Some client agents don't even have one window - let alone multiple
ones.


Unfortunately it gets exhausting writing paragraphs on the arguments
against opening new windows. A simple "don't do it" is usually not
sufficient and to do the subject justice requires several paragraphs of
explanation regarding the state of popups and various popup blocking
techniques.

My intent was to repair the most damaged portions of his existing code so
they would function correctly in Internet Explorer under Windows XP
Service Pack 2.

If, prior to my recommendations, he was losing business, and consequently
money, by not supporting browsers which do not support opening new
windows at all, I have certainly not made matters any worse. In fact, I
have made the situation better by including Internet Explorer under
Windows XP Service Pack 2, as well as browsers that do not support
JavaScript, or have it disabled.

Perhaps I should have added a disclaimer regarding the evils of opening
new windows at all, but I had read several prior posts which made points
on that matter, and did not feel the need to repeat them.
(unless there popup blocker is being overly agressive

^^^^^^

The aggression level of my popup blocker is for me to determine, not
left to some untrusted document author, thank you.


I'm not sure what "untrusted document author" you are referring to.
However, in general, I would say that any popup blocker that blocks new
windows that are a direct result of a user action are overly aggressive.
Specifically I would say that any popup blocker that blocks user
initiated popups in such a way as to break code which would fail
gracefully if it were not for the popup blocker are hostile.

Any popup blocker that simply replaces window.open() with a function that
does nothing (or returns an object that appears to be a Window object,
but in fact does nothing) makes writing "safe" code that opens new
windows impossible. And while that may be a desirable outcome, it is
entirely unfair considering that in most user agents a new window would
open as a result of a non-JavaScript link consisting of:

<a href="url" target="_blank">Opens in new window</a>

In any browser that opens a new window as a result of the code above, you
should be able to "safely" substitute the following:

<a href="url" target="_blank" onclick="window.open(this.href,
this.target, '...chrome...');return false;">Opens in new window</a>

It is precisely analogous to the first line, with the difference being
you have at least _some_ illusion of control over the chrome. And in any
cases where you can't directly control the aspects of the chrome you wish
to control, you are no worse off than you would be with the first
example. In other words, if your browser prevents me from removing the
menubar, allows me to provide a size, but not position for, the new
window, I am still slightly better off than using target="_blank" in
providing you with the desired outcome.

A popup blocker that chooses to make the second line completely
non-functional by removing the ability for window.open() to do anything,
but not removing the fact that JavaScript has executed and the link will
now not be followed is hostile. If your popup blocker chooses to disable
user initiated window.open()s, it should do so in a way that does not
cripple script written with an achievable non-scripted fall-back.

--
Grant Wagner <gw*****@agricoreunited.com>
comp.lang.javascript FAQ - http://jibbering.com/faq

Jul 23 '05 #10
Grant Wagner wrote:
<a href="#" onclick="window.close();return false;">Close</a>
Why have a link that goes nowhere? It will only bump the user to the top
of the document in many browsers. Annoying, or perhaps even confusing.
comp.lang.javascript FAQ - http://jibbering.com/faq


Have you read the faq that's in your sig? Specifically section 4.24
dealing with the javascript pseudo protocol?

[quote from http://jibbering.com/faq/#FAQ4_24 ]
<a href="something.html" onclick="somefunction();return false"> where
something.html is meaningful to the non-javascript capable, is nearly
always preferable. Or use onclick on another element so users without
javascript aren't even led to believe it does anything.
[/quote]

href="#" is not meaningful to any user.

--
Brian (remove "invalid" to email me)
http://www.tsmchughs.com/
Jul 23 '05 #11
Grant Wagner wrote:
in general, I would say that any popup blocker that blocks new
windows that are a direct result of a user action are overly
aggressive.
Alan Flavell's point still stands. You can configure your popup blocker
to allow requested popups if you choose. But another user can choose
otherwise. Whether that is "overly aggressive" or not is really not
for the author to decide.
Any popup blocker that simply replaces window.open() with a function
that does nothing (or returns an object that appears to be a Window
object, but in fact does nothing) makes writing "safe" code that
opens new windows impossible.
But surely a link will have some meaningful action if the js window
opener is ignored, right?
<a href="url" target="_blank">Opens in new window</a>


A good browser lets the user decide on new windows. Mozilla Firefox, for
example, allows me to ignore target="_blank" and open the link in the
same window, exactly as I want when I left click or tab-and-enter a link.

--
Brian (remove "invalid" to email me)
http://www.tsmchughs.com/
Jul 23 '05 #12

"Grant Wagner" <gw*****@agricoreunited.com> wrote in message
news:41***************@agricoreunited.com...
I'm not sure what "untrusted document author" you are referring to.
However, in general, I would say that any popup blocker that blocks new
windows that are a direct result of a user action are overly aggressive.


The browser only knows that a user has executed a particular action. It has
no way to know whether the user was made aware that that action would result
in a pop-up. If the user has configured the browser not to open pop-ups,
it's not the browser role to guess whether the user, by virtue of a
particular action, has chosen to make an exception.

Jul 23 '05 #13
On Thu, 16 Sep 2004, Grant Wagner wrote:
The aggression level of my popup blocker is for me to determine, not
left to some untrusted document author, thank you.


I'm not sure what "untrusted document author" you are referring to.


In a WWW context, the reader would be advised to treat any document
author as /prima facie/ untrusted.

Jul 23 '05 #14
Brian wrote:
Grant Wagner wrote:
Any popup blocker that simply replaces window.open() with a function
that does nothing (or returns an object that appears to be a Window
object, but in fact does nothing) makes writing "safe" code that
opens new windows impossible.


But surely a link will have some meaningful action if the js window
opener is ignored, right?


Not in the case of <a href="url" target="_blank"
onclick="window.open(this.href, this.target, '...chrome...');return
false;">Text</a>. If window.open() is ignored or subverted in some way:

<script type="text/javascript">
window.open = function() {
return null;
}

the link does _nothing_. The entire onclick event would have to be ignored
(including the "return false;" portion) for the browser to follow the link
and perform it's default task.
<a href="url" target="_blank">Opens in new window</a>


A good browser lets the user decide on new windows. Mozilla Firefox, for
example, allows me to ignore target="_blank" and open the link in the
same window, exactly as I want when I left click or tab-and-enter a link.


As I said, and I'll repeat:

In any browser in which <a href="url" target="_blank">Opens in a new
window</a> would open a new window, you should be able to replace it with <a
href="url" target="_blank" onclick="window.open(this.href, this.target,
'...chrome...');return false;">Opens in a new window</a> with reasonable
assurance that the link will behave the same, even in the presence of a popup
blocker. If a popup blocker defeats window.open() in such a way that the the
default action of the link is not performed (in your case opening the link in
the same window), it is broken.

This would most likely require the popup blocker to be aware of your desire
to subvert target="...", be aware the window.open() is targeting the target
attribute, and produce the following script:

<script type="text/javascript">
window.open = function (l) {
window.location.href = l;
}
</script>

While some highly configurable popup blockers might be capable of such logic
(or allow custom scripting to perform user-defined actions), it is unlikely
the vast majority of users have the skills necessary to configure their
browsers to handle situations like this.
In your particular browser configuration, <a href="url"
target="_blank">Link</a> does _not_ open in a new window, as a result, I
would expect <a href="url" target="_blank" onclick="window.open(this.href,
this.target, '...chrome...');return false;">Link</a> to result in the same
outcome (or perhaps even open the window, or create a new tab). I would not
expect your popup blocker to break the existing functionality of the link in
an attempt to stop a new window from appearing.

--
Grant Wagner <gw*****@agricoreunited.com>
comp.lang.javascript FAQ - http://jibbering.com/faq

Jul 23 '05 #15
Jon wrote:
DU,
This is not a 1:1 medium.

Who wrote that?
vvvvvvvvvvvvvvv
You assume visitors have javascript support is enabled.

Yes! It only relies on javascript to show the email address, I guess if
someone doesn't like javascript then the user can live without an email
from that visitor - when a phone call will surfice!


I really find you amusing, insisting on the usage of irritating
techniques due to your very limited knowledge about the used media
and its users.
I was hoping for a useful resolve to my technical issue, not insistance
that I change what is a very useful utility!!


Please, dance faster!
PointedEars, F'up2 cljs
--
I wanted to be a monkey, until I found out what they ate...
Jul 23 '05 #16
Jon wrote:
DU,
This is not a 1:1 medium.

Who wrote that?
vvvvvvvvvvvvvvv
You assume visitors have javascript support is enabled.

Yes! It only relies on javascript to show the email address, I guess if
someone doesn't like javascript then the user can live without an email
from that visitor - when a phone call will surfice!


I really find you amusing, insisting on the usage of irritating
techniques due to your very limited knowledge about the used media
and their users.
I was hoping for a useful resolve to my technical issue, not insistance
that I change what is a very useful utility!!


Please, dance faster!
PointedEars, F'up2 cljs
--
I wanted to be a monkey, until I found out what they ate...
Jul 23 '05 #17

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

reply views Thread by Rick Robinson | last post: by
4 posts views Thread by Christopher H. Laco | last post: by
23 posts views Thread by David McCulloch | last post: by
38 posts views Thread by Emmett | last post: by
16 posts views Thread by Jon | last post: by
12 posts views Thread by puzzlecracker | last post: by

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.