IE6 blocking (safe) content

[Jon]

Hi there,

In many of my sites I have code like:

<SCRIPT language="JavaS cript" 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="javascrip t:void(window.o pen('XXX.htm', 'Picture',
'width=XXX,heig ht=XXX'))">Text </a>

to open windows with zoomed pictures therein and

<a href="javascrip t: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 - compasscomputin g - dot - co - dot - uk

[Dave Patton]

"Jon" <jon@SPAM_OFFth eexperts.co.uk> wrote in
news:ci******** **@hercules.bti nternet.com:

Hi there,

In many of my sites I have code like:

<SCRIPT language="JavaS cript" 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="javascrip t:void(window.o pen('XXX.htm', 'Picture',
'width=XXX,heig ht=XXX'))">Text </a>

to open windows with zoomed pictures therein and

<a href="javascrip t: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/

[Shawn K. Quinn]

begin quote from Jon in <ci**********@h ercules.btinter net.com>:

Hi there,

In many of my sites I have code like:

<SCRIPT language="JavaS cript" 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="javascrip t:void(window.o pen('XXX.htm', 'Picture',
'width=XXX,heig ht=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="javascrip t: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

[DU]

Jon wrote:

Hi there,

In many of my sites I have code like:

<SCRIPT language="JavaS cript" 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="javascrip t:void(window.o pen('XXX.htm', 'Picture',
'width=XXX,heig ht=XXX'))">Text </a>

to open windows with zoomed pictures therein and

<a href="javascrip t: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 - compasscomputin g - 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 :)

[Grant Wagner]

Jon wrote:

Hi there,

In many of my sites I have code like:

<SCRIPT language="JavaS cript" 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="javascrip t:void(window.o pen('XXX.htm', 'Picture',
'width=XXX,heig ht=XXX'))">Text </a>
<a href="XXX.htm" target="Picture "
onclick="
window.open(
this.href,
this.target,
'width=XXX,heig ht=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="javascrip t: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*****@agrico reunited.com>
comp.lang.javas cript FAQ - http://jibbering.com/faq

[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 :)

[Jon]

Grant,

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

Jon

"Grant Wagner" <gw*****@agrico reunited.com> wrote in message
news:41******** *******@agricor eunited.com...
Jon wrote:

Hi there,

In many of my sites I have code like:

<SCRIPT language="JavaS cript" 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="javascrip t:void(window.o pen('XXX.htm', 'Picture',
'width=XXX,heig ht=XXX'))">Text </a>
<a href="XXX.htm" target="Picture "
onclick="
window.open(
this.href,
this.target,
'width=XXX,heig ht=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="javascrip t: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*****@agrico reunited.com>
comp.lang.javas cript FAQ - http://jibbering.com/faq

[Alan J. Flavell]

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.

[Darin McGrew]

[attributions restored]

DU <dr*******@hotN OSPAMmail.com> wrote:

The script to close the windows you created is excessive.

Jon <jon@SPAM_OFFth eexperts.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****@stanford alumni.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?"

[Grant Wagner]

"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*****@agrico reunited.com>
comp.lang.javas cript FAQ - http://jibbering.com/faq