Opening image in new window without padding

[D. Alvarado]

Hello,
I am trying to open a window containing an image and I would like
the image to be flush against the window -- i.e. have no padding or
border. Can I make this happen with a single call to a window.open
function? I would prefer not to create a separate HTML page. So far
all I have is the basic

var cwin = window.open('images/KJV-THANKS.gif',
'Thanks', 'width=243,height=420,');
cwin.focus();

If there's any cross-browser JS I can add to eliminate padding in the
new window, that would be awesome.

Thanks, - Dave

[Spartanicus]

la***********@gmail.com (D. Alvarado) wrote:

I am trying to open a window containing an image

Don't, it breaks a users back function, if a user wants a new window
they can open it themselves. Don't force your preference onto others.

--
Spartanicus

[Neal]

On 23 Aug 2004 10:50:57 -0700, D. Alvarado <la***********@gmail.com> wrote:

Hello,
I am trying to open a window containing an image and I would like
the image to be flush against the window -- i.e. have no padding or
border. Can I make this happen with a single call to a window.open
function? I would prefer not to create a separate HTML page. So far
all I have is the basic

var cwin = window.open('images/KJV-THANKS.gif',
'Thanks', 'width=243,height=420,');
cwin.focus();

If there's any cross-browser JS I can add to eliminate padding in the
new window, that would be awesome.

Thanks, - Dave

How many of this type of post have I read this past week alone?

Opening new windows like this with javascript is not worth it.

1) Users w/o Javascript can't see it anyhow.
2) Users with pop-up blockers can't see it either.
3) If there is some good reason to open a new window, the user can do it
himself quite easily.

I find a little irony in forcing a new window to thank the user - thanks
for not leaving a site which uses popups, perhaps?

[DU]

Neal wrote:

On 23 Aug 2004 10:50:57 -0700, D. Alvarado <la***********@gmail.com> wrote:

Hello,
I am trying to open a window containing an image and I would like
the image to be flush against the window -- i.e. have no padding or
border. Can I make this happen with a single call to a window.open
function? I would prefer not to create a separate HTML page. So far
all I have is the basic

var cwin = window.open('images/KJV-THANKS.gif',
'Thanks', 'width=243,height=420,');
cwin.focus();

If there's any cross-browser JS I can add to eliminate padding in the
new window, that would be awesome.

Thanks, - Dave

How many of this type of post have I read this past week alone?

Opening new windows like this with javascript is not worth it.

1) Users w/o Javascript can't see it anyhow.

Not if you code accordingly the target attribute of the link.
<a href="images/KJV-THANKS.gif" target="Thanks"
onclick="OpenRequestedPopup(this.href, this.target); return false;">
2) Users with pop-up blockers can't see it either.
Not true. Usually, popup blockers are set to prevent opening of
unsollicited popup windows, unexpected windows opening during the onload
event and during the onunload event.
3) If there is some good reason to open a new window, the user can do it
himself quite easily.

As long as you don't open multiple popup windows, as long as you recycle
a single popup window, as long as your webpage design justifies this
scenario without imposing it to the user, as long as you follow WAI
guidelines regarding popups, then I don't see a major issue.
I find a little irony in forcing
forcing is always bad; proposing this as a scenario to the user (and
generally speaking: coding webpage flexibility and accessibility) and
then letting him free to choose his own path is another story.

a new window to thank the user - thanks for not leaving a site which uses popups, perhaps?

Usability studies regarding popups have demonstrated that the actual
results reached, created by the use of popups is generally the exact
opposite of the web author's original intents. In other words, people
leave a site which uses popups more often than they stay.

Coding requested popups is generally poorly done in books, tutorials and
in javascript copy-N-paste sites. The above chunk of code provided by
the original poster is another typical example of this.

var cwin = window.open('images/KJV-THANKS.gif',
'Thanks', 'width=243,height=420,');

cwin which is a reference to the window object should be global, not a
local variable. As coded, the popup window won't be resizable in MSIE
5+, it won't render scrollbars if by any chance the content exceeds the
requested window dimensions and it won't render status bar... which is a
thing that SP2 will change for good and hopefully forever

"if the feature is turned on for Windows Restrictions, this feature:
Forces the status bar to be present in script-initiated Internet
Explorer windows with the title bar [those that were created with
window.open()]. (...) to ensure that the title bar and the status bar in
these windows is always visible to the user."
Changes to Functionality in Microsoft Windows XP Service Pack 2
Part 5: Enhanced Browsing Security
http://www.microsoft.com/technet/pro.../sp2brows.mspx

cwin.focus();

Again, this is badly coded. The reference should be tested for returning
an object and then if it exists but is not closed, then you should bring
in on top. The coded makes no smart testing of this sort.

DU

[D. Alvarado]

Gentlemen, let me assuage your rage. There would be a link that reads
"Click here for full image". The "THANKS.gif" was just an example I
threw in.

Knowing my innocuous intentions, is it possible to achieve what I am
asking? How?

Thanks, I'm on your side, -

Neal <ne*****@yahoo.com> wrote in message news:<op**************@news.individual.net>...

On 23 Aug 2004 10:50:57 -0700, D. Alvarado <la***********@gmail.com> wrote:

Hello,
I am trying to open a window containing an image and I would like
the image to be flush against the window -- i.e. have no padding or
border. Can I make this happen with a single call to a window.open
function? I would prefer not to create a separate HTML page. So far
all I have is the basic

var cwin = window.open('images/KJV-THANKS.gif',
'Thanks', 'width=243,height=420,');
cwin.focus();

If there's any cross-browser JS I can add to eliminate padding in the
new window, that would be awesome.

Thanks, - Dave

How many of this type of post have I read this past week alone?

Opening new windows like this with javascript is not worth it.

1) Users w/o Javascript can't see it anyhow.
2) Users with pop-up blockers can't see it either.
3) If there is some good reason to open a new window, the user can do it
himself quite easily.

I find a little irony in forcing a new window to thank the user - thanks
for not leaving a site which uses popups, perhaps?

[Spartanicus]

la***********@zipmail.com (D. Alvarado) wrote:

Top posting is not appreciated in this group, corrected this once.

Opening new windows like this with javascript is not worth it.

1) Users w/o Javascript can't see it anyhow.
2) Users with pop-up blockers can't see it either.
3) If there is some good reason to open a new window, the user can do it
himself quite easily.

I find a little irony in forcing a new window to thank the user - thanks
for not leaving a site which uses popups, perhaps?

Gentlemen, let me assuage your rage. There would be a link that reads
"Click here for full image".

Replicating a UI element on page that is built into the UA is equally
silly, so the answer stands: don't.

--
Spartanicus

[Dr.Tube]

Hi Dave,

I am trying to open a window containing an image and I would like
the image to be flush against the window -- i.e. have no padding or
border. Can I make this happen with a single call to a window.open
function? I would prefer not to create a separate HTML page. So far all I have is the basic
If there's any cross-browser JS I can add to eliminate padding in the new window, that would be awesome.

Here follows the JS code and HTML code which I use on my sites to open
custom windows containing a JPG or GIF.
As far as I have been able to test this, this works OK on IE5+,
Mozilla 1.0+ and Opera 3.5+.
By using the onClick event handler, the HTML part will still open the
image in a "standard" window when JS is turned off in the users UA.
Having noted all the comments of other posters on this topic I feel
that there are indeed circumstances in which it is legitimate to open
a (relatively small) image in a new window, especially if the refering
page is a large page which takes a while to load when hitting the back
function (even from the cache).

HTML Code
<A HRef="pic.gif" onClick="OpenImgXY('pic.gif',150,100,'Title');
return false"><IMG Src="icon-gif.gif" Alt=""></A>

150 and 100 are in this example the X and Y size of the image in
pixels. Title is the window title.

JS Code:
function OpenImgXY(FileName,W,H,Title)
{
var Str="", Max=false;
var X=0,Y=0,oW=0,oH=0;
var aW=0,aH=0;xc=0,yc=0;

if (window.screen) { // centre it on the screen...
aW=screen.availWidth;
aH=screen.availHeight;
xc=(aW-W)/2;
yc=(aH-H)/2;
}

if (W!=null) {
if (W>0) { X=W }
if (W>(aW-10) || W<0) {
Max=true;
oW=aW;
W=aW-10;
xc=0;
}
}

if (H!=null) {
if (H>0) { Y=H }
if (H>(aH-30) || H<0) {
Max=true;
oH=aH; H=aH-30;
yc=0;
}
}

if (Max)
{Str="scrollbars=yes,resizable=yes,width="+W+",hei ght="+H+",outerWidth
="+oW+",outerHeight="+oH}
else
{Str="scrollbars=no,status=no,menubar=no,width="+W +",height="+H+",inne
rWidth="+W+",innerHeight="+H}
Str +=",left="+xc+",top="+yc+",screenX="+xc+",screenY= "+yc;

myWin=window.open("",'_blank',Str);
if (myWin) {

myWin.document.writeln("<HTML><HEAD><TITLE>"+Title +"</TITLE></HEAD>");
myWin.document.writeln("<BODY BGColor=#FFFFFF LeftMargin=0
TopMargin=0 MarginWidth=0 MarginHeight=0>");
myWin.document.write("<IMG Src="+FileName);
if (X!=0) { myWin.document.write(" Width="+X) }
if (Y!=0) { myWin.document.write(" Height="+Y) }
myWin.document.writeln(">");
myWin.document.writeln("</BODY></HTML>");
myWin.document.close;
}
return myWin;
}

I've made this JS function so that it'll open a correctly sized window
in which the image will snuggly fit or it'll open a maxed window when
given -1, -1 as X,Y dimensions. While it isn't perfect it works quite
nicely most of the time.

Regards
Xavier van Unen.

[DU]

Dr.Tube wrote:

Hi Dave,

I am trying to open a window containing an image and I would like
the image to be flush against the window -- i.e. have no padding or
border. Can I make this happen with a single call to a window.open
function? I would prefer not to create a separate HTML page. So
far

all I have is the basic
If there's any cross-browser JS I can add to eliminate padding in

the

new window, that would be awesome.

Here follows the JS code and HTML code which I use on my sites to open
custom windows containing a JPG or GIF.
As far as I have been able to test this, this works OK on IE5+,
Mozilla 1.0+ and Opera 3.5+.
By using the onClick event handler, the HTML part will still open the
image in a "standard" window when JS is turned off in the users UA.
Having noted all the comments of other posters on this topic I feel
that there are indeed circumstances in which it is legitimate to open
a (relatively small) image in a new window, especially if the refering
page is a large page which takes a while to load when hitting the back
function (even from the cache).

HTML Code
<A HRef="pic.gif" onClick="OpenImgXY('pic.gif',150,100,'Title');
return false"><IMG Src="icon-gif.gif" Alt=""></A>

What Neal said about js support disabled applies perfectly to your code.
With javascript support disabled, the image pic.gif won't be viewed when
it *should* be and it could be.

Also, you do not follow none of the WAI Guidelines regarding requested
popups (secondary windows) nor J. Nielsen's. No warning. No title
attribute. No cursor in the link. No indication whatsoever that clicking
that icon-gif.gif will open a new separate window:

"if your link spawns a new window, or causes another windows to 'pop up'
on your display, or move the focus of the system to a new FRAME or
Window, then the nice thing to do is to tell the user that something
like that will happen."
WAI guidelines on popups
http://www.w3.org/WAI/wcag-curric/sam77-0.htm

"Use link titles to provide users with a preview of where each link will
take them, *_before_* they have clicked on it."
Ten Good Deeds in Web Design
http://www.useit.com/alertbox/991003.html

150 and 100 are in this example the X and Y size of the image in
pixels. Title is the window title.

JS Code:
function OpenImgXY(FileName,W,H,Title)
{
var Str="", Max=false;
var X=0,Y=0,oW=0,oH=0;
var aW=0,aH=0;xc=0,yc=0;

You need 10 local variables and 1 global variable for your code
notwithstanding 4 parameters: I already doubt your code very much.
if (window.screen) { // centre it on the screen...
aW=screen.availWidth;
aH=screen.availHeight;
xc=(aW-W)/2;
yc=(aH-H)/2;
}

if (W!=null) {
if (W>0) { X=W }
if (W>(aW-10) || W<0)
Your code assumes that there is 10 pixels granted to window resizing
handles/borders. Already here, your calculations are wrong.

{ Max=true;
oW=aW;
W=aW-10;
xc=0;
}
}

if (H!=null) {
if (H>0) { Y=H }
if (H>(aH-30)
From where comes this 30 value? The height of the titlebar is not 30
pixels. In fact, the height of the titlebar of windows is entirely
configurable in Windows XP and will affect Opera 7 and MSIE 6 users.
Again, your calculations ignore all this.

|| H<0) { Max=true;
oH=aH; H=aH-30;
yc=0;
}
}

if (Max)
{Str="scrollbars=yes,resizable=yes,width="+W+",hei ght="+H+",outerWidth
="+oW+",outerHeight="+oH}
else
{Str="scrollbars=no,status=no,menubar=no,width="+W +",height="+H+",inne
rWidth="+W+",innerHeight="+H}
1- innerWidth and width (innerHeight and height) refer to the same value
in NS 4, NS 6, NS 7 and Mozilla-based browsers.
2- Since the windowFeatures string list will not be empty, then there is
no need to define those with a no value.
3- You are willing to take a chance on the window dimensions fitting the
embedded picture up to a point of disabling scrollbars if needed, if
content overflows your requested window dimensions. From an
accessibility issue and usability issue, what you do is illogical and
not recommendable. As a normal accessibility fallback, every single
requested popup window opened via window.open() should have
scrollbars=yes. If you're sure about your inner and outer values, then
why would you want to remove scrollbars just in case and exactly when
your calculations do not work as expected, are wrong.
4- You're willing to assume your code will work and that you'll remove
status bar in both cases; this is one other area where your code fails.
Right now, you have to assume that 90% of all users out there (because
XP SP2 users will soon join Mozilla-based users and Opera 7.x users) can
force the presence of a status bar on all secondary window... but your
code assume you'll be able to remove that. So, your calculations get
wrong 90% of the time.
5- Notwithstanding the fact that Mozilla-based users and Opera 7.x users
can force the presence of scrollbars if needed (if content overflows
requested dimensions), menubar, statusbar and personalbar that your code
explicitly or implicitly tries to remove.
Str +=",left="+xc+",top="+yc+",screenX="+xc+",screenY= "+yc;

myWin=window.open("",'_blank',Str);

myWin was not properly declared before: that's another thing with js
function code being robust and working as efficiently as possible: scope
appropriately all variables.

You're creating a whole html document from a blank one.
1- Not what the original poster requested.
2- You're going to dynamically populate it with appending string
involving 7 document.write[ln] commands when at most 3 would have been
sufficient. (document.write[ln] is not the most efficient too)
I hope you see the considerable amount of time, cpu, RAM all this will
involve....
if (myWin) {

myWin could exist (typeof object) and the window being referenced by it
could be closed: your code makes no difference, no distinction at all
here, just doesn't care about it. So, if the window is behind the
opener, the window will be recreated and dynamically repopulated all
over again. What a waste of the user's system resources.
myWin.document.writeln("<HTML><HEAD><TITLE>"+Title +"</TITLE></HEAD>");
myWin.document.writeln("<BODY BGColor=#FFFFFF LeftMargin=0
TopMargin=0 MarginWidth=0 MarginHeight=0>");
Invalid code here. These *Margin attributes are non-standard markup.
myWin.document.write("<IMG Src="+FileName);
if (X!=0) { myWin.document.write(" Width="+X) }
if (Y!=0) { myWin.document.write(" Height="+Y) }
myWin.document.writeln(">");
myWin.document.writeln("</BODY></HTML>");
No escape of the forward slashes: the W3C HTML validator will complaint
and report these.
myWin.document.close;
myWin.document.close();

() missing.

}
return myWin;
}

I've made this JS function so that it'll open a correctly sized window
in which the image will snuggly fit or it'll open a maxed window when
given -1, -1 as X,Y dimensions. While it isn't perfect it works quite
nicely most of the time.

Regards
Xavier van Unen.

If the popup goes behind the opener, then the user clicking again the
link will NOT bring up back on top the popup and will be confused since
the window is not brought back. So, the user will keep on clicking the
link not understanding what is happening. This happens often, has been
well documented and is known to be the nr 1 usability problem with
popup: the js code you have here does not compensate for an inherent
flaw in the windowing system of known operating system.

Also, what if the user now clicks another thumbnail link? What if the
user expects your code to recycle and reuse that first window? How does
your code react to all this? Creating new windows on the user's system
requires a lot of system resources. Now, if you're willing to do that,
then the nice thing would be to make the best out of this usage, to make
such window reusable, recycle in and for a page where there are many
clickable thumbnails. Your code does not do that, does not take that
under consideration.

DU

[D. Alvarado]

Thanks, Xavier, this function does exactly the job.

"Dr.Tube" <as*@Dr.Tube.com> wrote in message news:<41***********************@news.xs4all.nl>...

Hi Dave,

I am trying to open a window containing an image and I would like
the image to be flush against the window -- i.e. have no padding or
border. Can I make this happen with a single call to a window.open
function? I would prefer not to create a separate HTML page. So

far

all I have is the basic
If there's any cross-browser JS I can add to eliminate padding in

the

new window, that would be awesome.

Here follows the JS code and HTML code which I use on my sites to open
custom windows containing a JPG or GIF.
As far as I have been able to test this, this works OK on IE5+,
Mozilla 1.0+ and Opera 3.5+.
By using the onClick event handler, the HTML part will still open the
image in a "standard" window when JS is turned off in the users UA.
Having noted all the comments of other posters on this topic I feel
that there are indeed circumstances in which it is legitimate to open
a (relatively small) image in a new window, especially if the refering
page is a large page which takes a while to load when hitting the back
function (even from the cache).

HTML Code
<A HRef="pic.gif" onClick="OpenImgXY('pic.gif',150,100,'Title');
return false"><IMG Src="icon-gif.gif" Alt=""></A>

150 and 100 are in this example the X and Y size of the image in
pixels. Title is the window title.

JS Code:
function OpenImgXY(FileName,W,H,Title)
{
var Str="", Max=false;
var X=0,Y=0,oW=0,oH=0;
var aW=0,aH=0;xc=0,yc=0;

if (window.screen) { // centre it on the screen...
aW=screen.availWidth;
aH=screen.availHeight;
xc=(aW-W)/2;
yc=(aH-H)/2;
}

if (W!=null) {
if (W>0) { X=W }
if (W>(aW-10) || W<0) {
Max=true;
oW=aW;
W=aW-10;
xc=0;
}
}

if (H!=null) {
if (H>0) { Y=H }
if (H>(aH-30) || H<0) {
Max=true;
oH=aH; H=aH-30;
yc=0;
}
}

if (Max)
{Str="scrollbars=yes,resizable=yes,width="+W+",hei ght="+H+",outerWidth
="+oW+",outerHeight="+oH}
else
{Str="scrollbars=no,status=no,menubar=no,width="+W +",height="+H+",inne
rWidth="+W+",innerHeight="+H}
Str +=",left="+xc+",top="+yc+",screenX="+xc+",screenY= "+yc;

myWin=window.open("",'_blank',Str);
if (myWin) {

myWin.document.writeln("<HTML><HEAD><TITLE>"+Title +"</TITLE></HEAD>");
myWin.document.writeln("<BODY BGColor=#FFFFFF LeftMargin=0
TopMargin=0 MarginWidth=0 MarginHeight=0>");
myWin.document.write("<IMG Src="+FileName);
if (X!=0) { myWin.document.write(" Width="+X) }
if (Y!=0) { myWin.document.write(" Height="+Y) }
myWin.document.writeln(">");
myWin.document.writeln("</BODY></HTML>");
myWin.document.close;
}
return myWin;
}

I've made this JS function so that it'll open a correctly sized window
in which the image will snuggly fit or it'll open a maxed window when
given -1, -1 as X,Y dimensions. While it isn't perfect it works quite
nicely most of the time.

Regards
Xavier van Unen.

[Dr.Tube]

Hi DU,

What Neal said about js support disabled applies perfectly to your code. With javascript support disabled, the image pic.gif won't be viewed when it *should* be and it could be. Actually, the image DOES open when JS is disabled! Really, try it.
I've just tested it myself (on Mozilla) just to be 100% sure!
Also, you do not follow none of the WAI Guidelines regarding requested popups (secondary windows) nor J. Nielsen's. No warning. No title
attribute. No cursor in the link. No indication whatsoever that clicking that icon-gif.gif will open a new separate window: I agree with you there. There should of course be a warning at the
start of the page indicating that (all) links will open in a new
window.

function OpenImgXY(FileName,W,H,Title)
{
var Str="", Max=false;
var X=0,Y=0,oW=0,oH=0;
var aW=0,aH=0;xc=0,yc=0;

You need 10 local variables and 1 global variable for your code
notwithstanding 4 parameters: I already doubt your code very much.

So? Still, it does work! If we're opening a new window anyway, why not
control it to the max?

if (window.screen) { // centre it on the screen...
aW=screen.availWidth;
aH=screen.availHeight;
xc=(aW-W)/2;
yc=(aH-H)/2;
}

if (W!=null) {
if (W>0) { X=W }
if (W>(aW-10) || W<0)

Your code assumes that there is 10 pixels granted to window resizing
handles/borders. Already here, your calculations are wrong.

I had to assume something... Like I said it isn't perfect, but it
works OK most of the time.
{

Max=true;
oW=aW;
W=aW-10;
xc=0;
}
}

if (H!=null) {
if (H>0) { Y=H }
if (H>(aH-30)
From where comes this 30 value? The height of the titlebar is not

30 pixels. In fact, the height of the titlebar of windows is entirely
configurable in Windows XP and will affect Opera 7 and MSIE 6 users.
Again, your calculations ignore all this. I know, but I don't how to get at these values without going into a
lot of OS specific details...

if (Max)
{Str="scrollbars=yes,resizable=yes,width="+W+",hei ght="+H+",outerWidth ="+oW+",outerHeight="+oH}
else
{Str="scrollbars=no,status=no,menubar=no,width="+W +",height="+H+",inne rWidth="+W+",innerHeight="+H}

1- innerWidth and width (innerHeight and height) refer to the same

value in NS 4, NS 6, NS 7 and Mozilla-based browsers. Yes but not in MSIE...
2- Since the windowFeatures string list will not be empty, then there is no need to define those with a no value. It shouldn't be necessary, but I've seen this gone wrong in at least
one browser (I can't remember which one though, maybe an old Opera...)
3- You are willing to take a chance on the window dimensions fitting the embedded picture up to a point of disabling scrollbars if needed, if
content overflows your requested window dimensions. From an
accessibility issue and usability issue, what you do is illogical and not recommendable. As a normal accessibility fallback, every single
requested popup window opened via window.open() should have
scrollbars=yes. If you're sure about your inner and outer values, then why would you want to remove scrollbars just in case and exactly when your calculations do not work as expected, are wrong. Yeah but a 200x200 pixel photograph of some product in a window
without scrollbars looks so much better than in a window with
scrollbars. Just in case I keep the window resizable.
4- You're willing to assume your code will work and that you'll remove status bar in both cases; this is one other area where your code fails. Right now, you have to assume that 90% of all users out there (because XP SP2 users will soon join Mozilla-based users and Opera 7.x users) can force the presence of a status bar on all secondary window... but your code assume you'll be able to remove that. So, your calculations get
wrong 90% of the time. Mmmmh, point taken and noted!
5- Notwithstanding the fact that Mozilla-based users and Opera 7.x users can force the presence of scrollbars if needed (if content overflows
requested dimensions), menubar, statusbar and personalbar that your code explicitly or implicitly tries to remove. Point taken and noted.

myWin=window.open("",'_blank',Str);

myWin was not properly declared before: that's another thing with js
function code being robust and working as efficiently as possible:

scope appropriately all variables. That's an oops...
You're creating a whole html document from a blank one.
1- Not what the original poster requested. OP wanted "Opening image in new window without padding". That's what
this JS does...
2- You're going to dynamically populate it with appending string
involving 7 document.write[ln] commands when at most 3 would have been sufficient. (document.write[ln] is not the most efficient too)
I hope you see the considerable amount of time, cpu, RAM all this will involve.... I agree that this isn't the most "efficient" way of doing this, but my
time is limited as well. CPU time is cheap. I wanted to keep the UA
specifics to minimum. But I agree this code can be "optimized".

if (myWin) {

myWin could exist (typeof object) and the window being referenced by

it could be closed: your code makes no difference, no distinction at all here, just doesn't care about it. So, if the window is behind the
opener, the window will be recreated and dynamically repopulated all
over again. What a waste of the user's system resources. So exactly how much user resources are "wasted" here? Opening a new
instance of IE has a minor impact on system resources...

myWin.document.writeln("<HTML><HEAD><TITLE>"+Title +"</TITLE></HEAD>"); myWin.document.writeln("<BODY BGColor=#FFFFFF LeftMargin=0
TopMargin=0 MarginWidth=0 MarginHeight=0>");

Invalid code here. These *Margin attributes are non-standard markup.

I know. But there is no DocType here either, so all browsers go into
quircks mode anyway. A CSS based solution would be better though.

myWin.document.write("<IMG Src="+FileName);
if (X!=0) { myWin.document.write(" Width="+X) }
if (Y!=0) { myWin.document.write(" Height="+Y) }
myWin.document.writeln(">");
myWin.document.writeln("</BODY></HTML>");

No escape of the forward slashes: the W3C HTML validator will

complaint and report these. I have this JS in a separate file. Should the slashes still be
"escaped" there?
If the popup goes behind the opener, then the user clicking again the link will NOT bring up back on top the popup and will be confused since the window is not brought back. So, the user will keep on clicking the link not understanding what is happening. This happens often, has been well documented and is known to be the nr 1 usability problem with
popup: the js code you have here does not compensate for an inherent
flaw in the windowing system of known operating system. So where is this documented? I'm obviously unaware of this problem.
Also, what if the user now clicks another thumbnail link? What if the user expects your code to recycle and reuse that first window? How does your code react to all this? Creating new windows on the user's system requires a lot of system resources. Now, if you're willing to do that, then the nice thing would be to make the best out of this usage, to make such window reusable, recycle in and for a page where there are many
clickable thumbnails. Your code does not do that, does not take that
under consideration.

I deliberately do not recycle a popup window as my users will probably
want to compare the images in the newly opened windows.
I appreciate your comments. I agree with some of your points, and
obviously my JS code here can be much improved.

Regards Xavier.

[Neal]

On Wed, 25 Aug 2004 08:55:37 +0200, Dr.Tube <as*@Dr.Tube.com> wrote:

Hi DU,

What Neal said about js support disabled applies perfectly to your

code.

With javascript support disabled, the image pic.gif won't be viewed

when

it *should* be and it could be.

Actually, the image DOES open when JS is disabled! Really, try it.
I've just tested it myself (on Mozilla) just to be 100% sure!

URL?

[Dr.Tube]

Hi Neal,

What Neal said about js support disabled applies perfectly to

your code.

With javascript support disabled, the image pic.gif won't be

viewed when

it *should* be and it could be.

Actually, the image DOES open when JS is disabled! Really, try it.
I've just tested it myself (on Mozilla) just to be 100% sure!

URL?

www.DrTube.com/audioamp.htm
All the schematics and pictures open in a new window.

Regards Xavier.

[DU]

Dr.Tube wrote:

Hi DU,

What Neal said about js support disabled applies perfectly to your
code.

With javascript support disabled, the image pic.gif won't be viewed

when

it *should* be and it could be.

Actually, the image DOES open when JS is disabled! Really, try it.

In the same window, yes, you're right. I was mostly thinking about a
secondary window, a requested popup; in which case,
target="SomeWindowName" is needed.
I've just tested it myself (on Mozilla) just to be 100% sure!

Also, you do not follow none of the WAI Guidelines regarding
requested

popups (secondary windows) nor J. Nielsen's. No warning. No title
attribute. No cursor in the link. No indication whatsoever that

clicking

that icon-gif.gif will open a new separate window:

I agree with you there. There should of course be a warning at the
start of the page indicating that (all) links will open in a new
window.

Well, just links that are going to open into a new window (assuming a
single left mouse click). The user can and should always be able to
right-click and open in a new window or in a new tab. Most of the time,
requested popup windows are (unintentionally maybe, but still) coded in
a way that prevents that. That's another problem with *coding* popups
and copy-N-paste javascript sites with poor code.

function OpenImgXY(FileName,W,H,Title)
{
var Str="", Max=false;
var X=0,Y=0,oW=0,oH=0;
var aW=0,aH=0;xc=0,yc=0;

You need 10 local variables and 1 global variable for your code
notwithstanding 4 parameters: I already doubt your code very much.

So? Still, it does work! If we're opening a new window anyway, why not
control it to the max?

If we're opening a new window, why not code it to the best possible way
respecting all that we can respect like:
- usability guidelines
- accessibility and sane fallback mechanisms
- user's system resources
- valid markup code
- best javascript coding practices

Half of your js variables are pretty much obsolete due to the coming of
SP2 btw which sanitizes positioning of requested popups.

"
if the feature is turned on for Windows Restrictions, this feature:
(...)
Constrains the size and positioning of script-initiated Internet
Explorer windows that have title and status bars to ensure that the
title bar and the status bar in these windows is always visible to the user.
Constrains script-initiated popup windows with no title or status bar or
other frame, so that they:
Do not extend above the top or below the bottom of the parent Web Object
Control (WebOC) window.
"
http://www.microsoft.com/technet/pro...on130121120120

I personally filed myself bugs on sanitizing positioning of requested
popups at bugzilla and they were fixed a few months ago.

Bug 176342: windows opened using innerHeight/Width can open partially
offscreen
http://bugzilla.mozilla.org/show_bug.cgi?id=176342

Bug 118717: Never let sites position windows outside the screen
http://bugzilla.mozilla.org/show_bug.cgi?id=118717

Bug 183633: screenX/left and screenY/top of popups are not corrected
accordingly when sizes are not specified
http://bugzilla.mozilla.org/show_bug.cgi?id=183633

Bug 174519: The window feature "titlebar=yes" will open a popup
maximized covering the window taskbar
http://bugzilla.mozilla.org/show_bug.cgi?id=174519

if (window.screen) { // centre it on the screen...
aW=screen.availWidth;
aH=screen.availHeight;
xc=(aW-W)/2;
yc=(aH-H)/2;
}

if (W!=null) {
if (W>0) { X=W }
if (W>(aW-10) || W<0)
Your code assumes that there is 10 pixels granted to window resizing
handles/borders. Already here, your calculations are wrong.

I had to assume something... Like I said it isn't perfect, but it
works OK most of the time.

You could have assume the standard default width value in Windows for
window borders and 10 was not the default width value.

{

Max=true;
oW=aW;
W=aW-10;
xc=0;
}
}

if (H!=null) {
if (H>0) { Y=H }
if (H>(aH-30)
From where comes this 30 value? The height of the titlebar is not

30

pixels. In fact, the height of the titlebar of windows is entirely
configurable in Windows XP and will affect Opera 7 and MSIE 6 users.
Again, your calculations ignore all this.

I know, but I don't how to get at these values without going into a
lot of OS specific details...

The default height value for Windows Standard theme is available here:

Start/Settings/Control Panel/Display/Appearance tab/Advanced
button/Item: Active Title Bar/Size

if (Max)

{Str="scrollbars=yes,resizable=yes,width="+W+",hei ght="+H+",outerWidth
="+oW+",outerHeight="+oH}
else

{Str="scrollbars=no,status=no,menubar=no,width="+W +",height="+H+",inne
rWidth="+W+",innerHeight="+H}
1- innerWidth and width (innerHeight and height) refer to the same

value

in NS 4, NS 6, NS 7 and Mozilla-based browsers.

Yes but not in MSIE...

MSIE does not support innerWidth and innerHeight but support width and
height: so there is no need at all to refer to innerWidth and
innerHeight in your windowFeatures string list here. Just width and
height will cover NS 4, NS 6, NS 7, Mozilla-based browsers, MSIE 5+,
Opera 7.x, etc...

"Backwards compatibility:
* open(height,width) equates to the new open(innerHeight,innerWidth)
(...)
Note: innerHeight and innerWidth options replace the height and width
options,
but they remain for backwards compatibility."
JAVASCRIPT 1.2 NEW WINDOW METHODS AND PROPERTIES
http://developer.netscape.com/docs/t...dow/index.html

2- Since the windowFeatures string list will not be empty, then
there is

no need to define those with a no value.

It shouldn't be necessary, but I've seen this gone wrong in at least
one browser (I can't remember which one though, maybe an old Opera...)

I'm convinced there is no need for the windowFeatures with a "no" value.

3- You are willing to take a chance on the window dimensions fitting
the

embedded picture up to a point of disabling scrollbars if needed, if
content overflows your requested window dimensions. From an
accessibility issue and usability issue, what you do is illogical

and

not recommendable. As a normal accessibility fallback, every single
requested popup window opened via window.open() should have
scrollbars=yes. If you're sure about your inner and outer values,

then

why would you want to remove scrollbars just in case and exactly

when

your calculations do not work as expected, are wrong.

Yeah but a 200x200 pixel photograph of some product in a window
without scrollbars looks so much better than in a window with
scrollbars.

You don't understand. If scrollbars are needed, your code and your logic
demands to remove them.
In your else block, you remove both the scrollbars if they are needed
and you remove implicitly the window resizability! So you don't help the
user accessing your content; I'm not referring to cosmetics. If your
sizes are correct, scrollbars won't appear and resizing of the window
won't be needed...but you should always code and consider fallback
mechanisms. You don't know what the user might have: special assistive
technology, user defined stylesheet with !important css declarations,
rules, MS-magnify ON which reduces the height of windows' application
workarea, etc..

Just in case I keep the window resizable.

No you don't in your else block. You implicitly remove window resizability.

Your code:
else
{Str="scrollbars=no,status=no,menubar=no,width="+W +",height="+H+",inne
rWidth="+W+",innerHeight="+H}

4- You're willing to assume your code will work and that you'll
remove

status bar in both cases; this is one other area where your code

fails.

Right now, you have to assume that 90% of all users out there

(because

XP SP2 users will soon join Mozilla-based users and Opera 7.x users)

can

force the presence of a status bar on all secondary window... but

your

code assume you'll be able to remove that. So, your calculations get
wrong 90% of the time.

Mmmmh, point taken and noted!

5- Notwithstanding the fact that Mozilla-based users and Opera 7.x

users

can force the presence of scrollbars if needed (if content overflows
requested dimensions), menubar, statusbar and personalbar that your

code

explicitly or implicitly tries to remove.

Point taken and noted.

myWin=window.open("",'_blank',Str);

myWin was not properly declared before: that's another thing with js
function code being robust and working as efficiently as possible:

scope

appropriately all variables.

That's an oops...

You're creating a whole html document from a blank one.
1- Not what the original poster requested.

OP wanted "Opening image in new window without padding". That's what
this JS does...

2- You're going to dynamically populate it with appending string
involving 7 document.write[ln] commands when at most 3 would have

been

sufficient. (document.write[ln] is not the most efficient too)
I hope you see the considerable amount of time, cpu, RAM all this

will

involve....

I agree that this isn't the most "efficient" way of doing this, but my
time is limited as well. CPU time is cheap. I wanted to keep the UA
specifics to minimum. But I agree this code can be "optimized".

window.open() calls involves more and more lines of long branching code
these days as popup coding has become the strategical target of browser
manufacturers in the last 2 years: SP2 is another demonstration and
certainty that the browser code regarding window.open() and secondary
windows has now grown bigger. More complex, more user settings involves.
For instance, Mozilla code regarding window.open() exceeds 5,000 lines,
notwithstanding all the code related to tabs, as one can open a link
(with an onclick handler) in a new tab.

if (myWin) {
myWin could exist (typeof object) and the window being referenced by

it

could be closed: your code makes no difference, no distinction at

all

here, just doesn't care about it. So, if the window is behind the
opener, the window will be recreated and dynamically repopulated all
over again. What a waste of the user's system resources.

So exactly how much user resources are "wasted" here? Opening a new
instance of IE has a minor impact on system resources...

I don't agree. It takes time, cpu, RAM, memory management code, etc.
Some sites with many thumbnails are slow because it takes time/cpu/RAM
to close and delete secondary windows and do necessary memory management
stuff and then create new ones from scratch for enlarged images.

myWin.document.writeln("<HTML><HEAD><TITLE>"+Title +"</TITLE></HEAD>");

myWin.document.writeln("<BODY BGColor=#FFFFFF LeftMargin=0
TopMargin=0 MarginWidth=0 MarginHeight=0>");
Invalid code here. These *Margin attributes are non-standard markup.

I know. But there is no DocType here either, so all browsers go into
quircks mode anyway. A CSS based solution would be better though.

myWin.document.write("<IMG Src="+FileName);
if (X!=0) { myWin.document.write(" Width="+X) }
if (Y!=0) { myWin.document.write(" Height="+Y) }
myWin.document.writeln(">");
myWin.document.writeln("</BODY></HTML>");

No escape of the forward slashes: the W3C HTML validator will

complaint

and report these.

I have this JS in a separate file. Should the slashes still be
"escaped" there?

If it is in a separate file, then you're ok. But in an usenet newsgroup,
you can assume people won't know that and will paste your code into
their webpage.
No need to escape the forward slashes for an external file. But this is
minor issue compare to the recourse to document.write[ln] and the number
of times being called. Appending strings is cpu demanding.
I personally always stay from document.write() calls and use exclusively
DOM methods.

If the popup goes behind the opener, then the user clicking again
the

link will NOT bring up back on top the popup and will be confused

since

the window is not brought back. So, the user will keep on clicking

the

link not understanding what is happening. This happens often, has

been

well documented and is known to be the nr 1 usability problem with
popup: the js code you have here does not compensate for an inherent
flaw in the windowing system of known operating system.

So where is this documented? I'm obviously unaware of this problem.

You may start here: many quotes, urls are there:

Popup windows and Netscape 7
http://www10.brinkster.com/doctorunc...nLinkNewWindow

Also, what if the user now clicks another thumbnail link? What if
the

user expects your code to recycle and reuse that first window? How

does

your code react to all this? Creating new windows on the user's

system

requires a lot of system resources. Now, if you're willing to do

that,

then the nice thing would be to make the best out of this usage, to

make

such window reusable, recycle in and for a page where there are many
clickable thumbnails. Your code does not do that, does not take that
under consideration.

I deliberately do not recycle a popup window as my users will probably
want to compare the images in the newly opened windows.

You can still code in a way that will give such flexibility and freedom
to the users.
You deliberately do not recycle a popup window; I deliberately code
links like that so that I can propose to my users such recycling
scenario without constraining them, without limiting their choice,
without limiting their freedom as to how (new window, new tab,
background or not, new unnamed window) they want to see the referenced
resource of such link. That's coding for flexibility and accessibility.

As long as your link does not interfere with right-click context-menu
commands (open in a tab, open in a new window, open in background tab or
window), then you can still do this: it's even a site, webpage feature
in fact. In K-meleon 0.8.2, I can open links of my page in 5 different
ways if I want to while still being able to recycle the only target window.

DU
I appreciate your comments. I agree with some of your points, and
obviously my JS code here can be much improved.

Regards Xavier.

[DU]

DU wrote:

Dr.Tube wrote:

Hi DU,


So where is this documented? I'm obviously unaware of this problem.

You may start here: many quotes, urls are there:

Popup windows and Netscape 7
http://www10.brinkster.com/doctorunc...nLinkNewWindow

[snipped]

I deliberately do not recycle a popup window as my users will probably
want to compare the images in the newly opened windows.

You can still code in a way that will give such flexibility and freedom
to the users.
You deliberately do not recycle a popup window; I deliberately code
links like that so that I can propose to my users such recycling
scenario without constraining them, without limiting their choice,
without limiting their freedom as to how (new window, new tab,
background or not, new unnamed window) they want to see the referenced
resource of such link. That's coding for flexibility and accessibility.

As long as your link does not interfere with right-click context-menu
commands (open in a tab, open in a new window, open in background tab or
window), then you can still do this: it's even a site, webpage feature
in fact. In K-meleon 0.8.2, I can open links of my page in 5 different
ways if I want to while still being able to recycle the only target window.

Here's one final quote not in that article:

"Links that don't behave as expected undermine users' understanding of
their own system. A link should be a simple hypertext reference that
replaces the current page with new content. Users hate unwarranted
pop-up windows. When they want the destination to appear in a new page,
they can use their browser's 'open in new window' command -- assuming,
of course, that **the link is not a piece of [javascript] code that
interferes with the browser's standard behavior**.
Users deserve to control their own destiny. Computers that behave
consistently empower people by letting them use their own tools and
wield them accurately."

Jakob Nielsen, Top Ten Web-Design Mistakes of 2002,
6. JavaScript in Links,
http://www.useit.com/alertbox/20021223.html

And I have coded last year a demo file that does exactly what the OP was
looking for. It's still on my site but the banner ads interfere with the
code: so you see, even here, I was myself right in thinking that you
should always code assuming Murphy's law and accessibility.

Open a sub-window and dynamically DOM-insert an image
http://www10.brinkster.com/doctorunc...geInPopup.html
(locally, this interactive demo page works flawlessly, impeccably; the
banner ads interfere on brinkster)

Also:
Opening enlarged images of different sizes into a single window
http://www10.brinkster.com/doctorunc...Thumbnail.html

Full interactive demo of how to recycle secondary windows
http://www10.brinkster.com/doctorunc...pera7Bugs.html

DU

[Dr.Tube]

Hi DU,

What Neal said about js support disabled applies perfectly to your
code.
With javascript support disabled, the image pic.gif won't be viewed when it *should* be and it could be. Actually, the image DOES open when JS is disabled! Really, try it.

In the same window, yes, you're right. I was mostly thinking about a
secondary window, a requested popup; in which case,
target="SomeWindowName" is needed.

Oh yes, you're absolutely right, I forgot the target here...

You need 10 local variables and 1 global variable for your code
notwithstanding 4 parameters: I already doubt your code very much.

So? Still, it does work! If we're opening a new window anyway, why not

control it to the max?

If we're opening a new window, why not code it to the best possible

way respecting all that we can respect like:
- usability guidelines
- accessibility and sane fallback mechanisms
- user's system resources
- valid markup code
- best javascript coding practices I agree, but my time, JS skills and knowledge are limited. At least my
knowledge is back on the learning curve now... ;-)
Half of your js variables are pretty much obsolete due to the coming of SP2 btw which sanitizes positioning of requested popups. Not everyone uses (or wants to use) XP and MSIE6... This code was
created a couple of years back.
http://www.microsoft.com/technet/pro...intain/sp2brow
s.mspx#XSLTsection130121120120 http://bugzilla.mozilla.org/show_bug.cgi?id=176342
http://bugzilla.mozilla.org/show_bug.cgi?id=118717
http://bugzilla.mozilla.org/show_bug.cgi?id=183633
http://bugzilla.mozilla.org/show_bug.cgi?id=174519 OK. Good reading...

Your code assumes that there is 10 pixels granted to window resizinghandles/borders. Already here, your calculations are wrong.

I had to assume something... Like I said it isn't perfect, but it
works OK most of the time.

You could have assume the standard default width value in Windows

for window borders and 10 was not the default width value. Is there a default or standard value? I doubt it.

From where comes this 30 value? The height of the titlebar is not
> 30 pixels. In fact, the height of the titlebar of windows is entirelyconfigurable in Windows XP and will affect Opera 7 and MSIE 6 users.Again, your calculations ignore all this.

I know, but I don't how to get at these values without going into a

lot of OS specific details...

The default height value for Windows Standard theme is available

here: Start/Settings/Control Panel/Display/Appearance tab/Advanced
button/Item: Active Title Bar/Size Yes I know. But I don't want to (and I'm not able to) program all
sorts of OS specific stuff in my JS.

1- innerWidth and width (innerHeight and height) refer to the same
value in NS 4, NS 6, NS 7 and Mozilla-based browsers.

Yes but not in MSIE...

MSIE does not support innerWidth and innerHeight but support width

and height: so there is no need at all to refer to innerWidth and
innerHeight in your windowFeatures string list here. Just width and
height will cover NS 4, NS 6, NS 7, Mozilla-based browsers, MSIE 5+,
Opera 7.x, etc... All I wanted to do is make the image fit snugly in a window. If for
some reason the window isn't going to fit on the available screen
area, the window dimensions should be reduced to fit. I found that
NS4, Mz and MSIE all had different ways of doing this. Apparantly my
"methodology" is outdated and can be improved.

3- You are willing to take a chance on the window dimensions fittingthe embedded picture up to a point of disabling scrollbars if needed,if content overflows your requested window dimensions. From an
accessibility issue and usability issue, what you do is illogical andnot recommendable. As a normal accessibility fallback, every singlerequested popup window opened via window.open() should have
scrollbars=yes. If you're sure about your inner and outer values,
then why would you want to remove scrollbars just in case and exactlywhen your calculations do not work as expected, are wrong.

Yeah but a 200x200 pixel photograph of some product in a window
without scrollbars looks so much better than in a window with
scrollbars.

You don't understand. If scrollbars are needed, your code and your

logic demands to remove them.
In your else block, you remove both the scrollbars if they are needed and you remove implicitly the window resizability! So you don't help the user accessing your content; I'm not referring to cosmetics. If your
sizes are correct, scrollbars won't appear and resizing of the window won't be needed...but you should always code and consider fallback
mechanisms. You don't know what the user might have: special assistive technology, user defined stylesheet with !important css declarations, rules, MS-magnify ON which reduces the height of windows' application workarea, etc.. Mmmmh, food for thought.
Just in case I keep the window resizable.
No you don't in your else block. You implicitly remove window resizability. Your code:
else
{Str="scrollbars=no,status=no,menubar=no,width="+W +",height="+H+",inne rWidth="+W+",innerHeight="+H} You're right. I was wrong in posting this JS snippet, as my "newer"
OpenWin function actually does make the window resizable...

You're creating a whole html document from a blank one.
1- Not what the original poster requested.

OP wanted "Opening image in new window without padding". That's what

this JS does... And no one else here has given a better suggestion...
I would really love to see a better solution for this!

2- You're going to dynamically populate it with appending string
involving 7 document.write[ln] commands when at most 3 would have
been sufficient. (document.write[ln] is not the most efficient too)I hope you see the considerable amount of time, cpu, RAM all this
will involve....

I agree that this isn't the most "efficient" way of doing this,

but my time is limited as well. CPU time is cheap. I wanted to keep the UA specifics to minimum. But I agree this code can be "optimized".

window.open() calls involves more and more lines of long branching

code these days as popup coding has become the strategical target of browser manufacturers in the last 2 years: SP2 is another demonstration and
certainty that the browser code regarding window.open() and secondary windows has now grown bigger. More complex, more user settings involves. For instance, Mozilla code regarding window.open() exceeds 5,000 lines, notwithstanding all the code related to tabs, as one can open a link
(with an onclick handler) in a new tab. Fair enough, reducing the code to 1 window.write would be better.

I have this JS in a separate file. Should the slashes still be
"escaped" there?

If it is in a separate file, then you're ok. But in an usenet

newsgroup, you can assume people won't know that and will paste your code into
their webpage. You're right, I didn't realize that...

I deliberately do not recycle a popup window as my users will probably want to compare the images in the newly opened windows.

You can still code in a way that will give such flexibility and

freedom to the users.
You deliberately do not recycle a popup window; I deliberately code
links like that so that I can propose to my users such recycling
scenario without constraining them, without limiting their choice,
without limiting their freedom as to how (new window, new tab,
background or not, new unnamed window) they want to see the referenced resource of such link. That's coding for flexibility and accessibility. As long as your link does not interfere with right-click context-menu commands (open in a tab, open in a new window, open in background tab or window), then you can still do this: it's even a site, webpage feature in fact. In K-meleon 0.8.2, I can open links of my page in 5 different ways if I want to while still being able to recycle the only target

window.
Would you be able and willing to show me a better way of doing this
with an actual working JS using "modern" DOM techniques and
cross-browser compatibility?

Regards Xavier.