Hi, stupid popup question

[Shaun McKinnon]

HI...Here's my problem...I have a popup window that loads when i want it to,
but it's not sized properly. I've set the size, but it doesn't seem to
work. I've been on 8 different websites to find out what i'm doing wrong,
and so far it seems i'm doing it the right way. Here's my code...any
suggestions would be appreciated.

<script language="javascript">
<!--
window.open("256fx/index.htm", "", "height=400, width=600");
//-->
</script>

 

[Michael Winter]

on 12/11/2003:

HI...Here's my problem...I have a popup window that loads when i want it to,
but it's not sized properly. I've set the size, but it doesn't seem to
work. I've been on 8 different websites to find out what i'm doing wrong,
and so far it seems i'm doing it the right way. Here's my code...any
suggestions would be appreciated.

<script language="javascript">

Use type="text/javascript" instead of the 'language' attribute.

<!--
window.open("256fx/index.htm", "", "height=400, width=600");
//-->
</script>

This works fine on IE 6, however you shouldn't include spaces in the
features list. Change it to 'height=400,width=600'. That might be
the problem if you're testing this with a stricter browser.

Mike

 

[Shaun McKinnon]

Didn't work for me for some reason, but thanks Mike.

The funny thing is, is that it opens as 400x600, but then it explodes to the
size of the desktop...

here's what i want to do:

Customer goes to www.whatever.com/
this takes them to index.html which then opens popup index.htm
the main page is just a simple graphic thats 400x600, with a few flash
buttons (more of an ad)
it's obviously in the center (still have to learn how to script that).

Any suggestions???

Shaun McKinnon

 

[Michael Winter]

on 12/11/2003:

Didn't work for me for some reason, but thanks Mike.

The funny thing is, is that it opens as 400x600, but then it explodes to the
size of the desktop...

here's what i want to do:

Customer goes to www.whatever.com/
this takes them to index.html which then opens popup index.htm
the main page is just a simple graphic thats 400x600, with a few flash
buttons (more of an ad)
it's obviously in the center (still have to learn how to script

that).

You still haven't mentioned what browser you're using. I don't think
I could help you even if you did say what it was, but someone else
might be able to. I'm frankly at a loss for what would cause your
window to maximize like that. Out of pure curiosity, could you try
this exact string (don't change a thing, please)? I have a theory,
but I might be way off the mark...

<A href="#" onclick="window.open('about:blank', 'about_blank',
'height=400,width=600'); return false">Test</A>

As for centring, that's fairly simple. Check the 'screen' object.
It's properties include the user's monitor dimensions, amongst other
things. Of course, until your maximizing problem is fixed, centring
is useless.

Mike

 

[Richard Cornford]

... . I'm frankly at a loss for what would cause your
window to maximize like that. ...

<snip>

My suspicion is that Shaun is using cut-and-paste scripts without
understanding what they do or how they work and has included a script
with a call to window.resizeTo (or resizeBy) that is expanding the
window. It certainly isn't something that I would expect to happen
without some sort of instruction to do so. (Then again it might be some
sort of ill-conceived free web host inserted script.)

As for centring, that's fairly simple. Check the 'screen'
object. It's properties include the user's monitor dimensions,
amongst other things. Of course, until your maximizing problem
is fixed, centring is useless.

Centring windows is not as simple as just reading the screen dimensions
and positioning the window accordingly. Apart from being a meaningless
action in a tabbed browser, problems occur with, say, the MDI interface
on Opera, where screen dimensions reflect the desktop but window
positing instructions are relative to the outer window of the interface,
meaning that an attempt to position a window based on the screen
dimensions stands a very realistic chance of resulting in a window that
is entirely out of site. Multi-monitor displays are another stumbling
block as positioning based on screen dimension may result in the window
being opened across the screen boundaries, partly out of the displayable
desktop area and/or on a different monitor to the browser window, where
it may go unnoticed.

Unfortunately, without any mechanism for determining the type of
multi-monitor display (if any) being used, whether the browser is MDI or
tabbed, or any combination of these, the only reliable approach to
positioning windows is to make no specification at all. In response most
browsers will open a new window over the existing window, the one place
that you can be fairly certain that it will be apparent and fully
visible to the user (subject to scriptable window opening being allowed
at all).

Richard.

 

[Shaun McKinnon]

Hi, no it's not a cut and paste script (forbid)...It's one of Dreamweavers
wonderful drop in scripts that doesn't work worth a damn.
the script does not have an included call either. I posted the script that
i used.

Shaun McKinnon

 

[Shaun McKinnon]

I'll try that string Mike...Thanks again for you help.

Shaun McKinnon
ps: it's IE 6

 

[Shaun McKinnon]

Hey MIKE!!!

That worked..Thanks alot. I'll customize it for my usage.

Shaun McKinnon

 

[Michael Winter]

on 13/11/2003:

<snip>

My suspicion is that Shaun is using cut-and-paste scripts without
understanding what they do or how they work and has included a script
with a call to window.resizeTo (or resizeBy) that is expanding the
window. It certainly isn't something that I would expect to happen
without some sort of instruction to do so. (Then again it might be some
sort of ill-conceived free web host inserted script.)


Centring windows is not as simple as just reading the screen dimensions
and positioning the window accordingly. Apart from being a meaningless
action in a tabbed browser, problems occur with, say, the MDI interface
on Opera, where screen dimensions reflect the desktop but window
positing instructions are relative to the outer window of the interface,
meaning that an attempt to position a window based on the screen
dimensions stands a very realistic chance of resulting in a window that
is entirely out of site. Multi-monitor displays are another stumbling
block as positioning based on screen dimension may result in the window
being opened across the screen boundaries, partly out of the displayable
desktop area and/or on a different monitor to the browser window, where
it may go unnoticed.

Unfortunately, without any mechanism for determining the type of
multi-monitor display (if any) being used, whether the browser is MDI or
tabbed, or any combination of these, the only reliable approach to
positioning windows is to make no specification at all. In response most
browsers will open a new window over the existing window, the one place
that you can be fairly certain that it will be apparent and fully
visible to the user (subject to scriptable window opening being allowed
at all).

Your point is well taken. I'm sheltered from the features of most
browsers out there. They've proved far too unstable on my system in
the past. I loved Opera, but it crashed - sometimes taking the kernel
with it - regularly. I've got enough problems with stability as it is
at the moment, I don't need more possible causes.

A few counter points:

1) You can't place windows off-screen. Scripts have to be signed to
do that (unless that restriction was removed after 1.3 - I haven't
finished reading up on DOM and the later JS versions yet), and the OPs
won't be.
2) As you say, positioning is meaningless for tabbed browsers. They
will ignore such positioning statements, so it won't matter. The user
just won't see quite what the author intended.
3) The browsers create the screen object. It would be logical to
assume that an MDI browser would report the dimensions of the MDI
window, and not that of the entire monitor. In my opinion, I see no
point in reporting the existence of pixels you can't use. Whether the
browser developers see it that way is of course, another matter and
one that is a waste of time debating (good to note, though).

Mike

 

[Michael Winter]

on 13/11/2003:

Hey MIKE!!!

That worked..Thanks alot. I'll customize it for my usage.

No problem. It appears that because you didn't name the window
(second parameter), IE ignored the features list. 'name' is required.
Thomas Lahn also suggested this in your other thread.

Mike

 

[Richard Cornford]

Your point is well taken. I'm sheltered from the features
of most browsers out there. They've proved far too unstable
on my system in the past. I loved Opera, but it crashed -
sometimes taking the kernel with it - regularly. I've got
enough problems with stability as it is at the moment, I
don't need more possible causes.

Opera 6 (and 5 more so) was a bit flaky (especially when incautiously
scripted) but Opera 7 is proving quite robust. And it is surprising how
many ways there are of crashing IE 6 with JavaScript, and taking the OS
with it.

A few counter points:

1) You can't place windows off-screen. Scripts have to be
signed to do that (unless that restriction was removed after
1.3 - I haven't finished reading up on DOM and the later JS
versions yet), and the OPs won't be.

Theoretically true, though there have been browsers that have allowed
windows to be opened off screen. That is usually considered a security
flaw and fixed in later versions.

However, some of the multi-monitor systems have the OS report the screen
dimensions to the browser as the smallest rectangle that will encompass
all of the monitor screens used. So if the monitors are not identical
sizes configured as either a block or a strip then there are void areas
that will not be displayed on (or practically accessible from) and of
the monitors. A fairly common configuration of a 24 inch monitor with a
17 inch monitor to the right would have an inaccessible area above the
17 inch monitor making the desktop height up to that of the 24 inch
monitor. From the point of view of the browsers that region is part of
the desktop and an attempt to centre a new browser window is likely to
place the upper right of the new window in that area, making the close,
minimise and maximise buttons and par to the content inaccessible (until
the window is moved). Move on to five or six monitors configured in an L
shape and it is entirely possible for the new window to be completely
out of site.

2) As you say, positioning is meaningless for tabbed
browsers. They will ignore such positioning statements,
so it won't matter. The user just won't see quite what
the author intended.

The existence of tabbed browsers does bring into question the validity
of designing sites to use multiple windows. Most of the justifications
for such a design vanish completely on such a browser (and they do
include browsers based entirely on IE).

3) The browsers create the screen object. It would be
logical to assume that an MDI browser would report the
dimensions of the MDI window, and not that of the entire
monitor.

That depends, if it is called the "screen" object it might be reasonably
be argued that what it should report should be related to the screen and
not something else. Making the screen object report the MDI interface
viewport dimensions might help authors who insisted on trying to centre
windows, but not that much as they never seem to bother to check if the
results of ((screen.availWidth - browser.width)/2) is negative, and the
MDI interface viewpoint does not constrain the windows it contains so
that information is not necessarily an appropriate basis for the
positing decisions either.

In my opinion, I see no point in reporting the
existence of pixels you can't use. Whether the browser
developers see it that way is of course, another matter and
one that is a waste of time debating (good to note, though).

The bottom line is that the screen objects of various browsers report
information that is inaccurate, irrelevant and inapplicable. As a
result, the general advice is to never do anything that necessitates an
interest in the screen dimensions. Avoiding the inaccuracy and
inapplicability of the information by never asking the question.

As with all things related to browser scripting, there are plenty of
people who would rather ignore the issues than learn how to cope with
the consequences, but that just means that they are willing to make
themselves look incompetent whenever their scripts encounter any of the
'slightly diverging from the norm' conditions.

Richard.

 

[DU]

on 13/11/2003:



MDI or



Your point is well taken. I'm sheltered from the features of most
browsers out there. They've proved far too unstable on my system in
the past. I loved Opera, but it crashed - sometimes taking the kernel
with it - regularly. I've got enough problems with stability as it is
at the moment, I don't need more possible causes.

A few counter points:

1) You can't place windows off-screen.

Yes you can with MSIE 5+. No you can not in Mozilla-based browsers and
NS 4 as you rightly point out that scripts must be signed to do that...
although there are a few bugs which still needs to be fixed regarding
this issue:

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
http://bugzilla.mozilla.org/attachment.cgi?id=110263&action=view

Scripts have to be signed to

do that (unless that restriction was removed after 1.3 - I haven't
finished reading up on DOM and the later JS versions yet), and the OPs
won't be.
2) As you say, positioning is meaningless for tabbed browsers. They
will ignore such positioning statements, so it won't matter. The user
just won't see quite what the author intended.

But we are talking about new windows here, no?

3) The browsers create the screen object. It would be logical to
assume that an MDI browser would report the dimensions of the MDI
window, and not that of the entire monitor. In my opinion, I see no
point in reporting the existence of pixels you can't use.

Correct. I agree. That's why Opera needs to implement a property of the
window object for this. Something like
window.MDIviewportWidth
window.MDIviewportHeight

DU

Whether the

 

[Lasse Reichstein Nielsen]

Correct. I agree. That's why Opera needs to implement a property of
the window object for this. Something like

window.MDIviewportWidth
window.MDIviewportHeight

Why not use screen.availHeight and screen.availWidth for that. The
MDI viewport *is* the available size for windows. (I have suggested
it to them, but maybe it is too big a change).

/L

 

[DU]

<snip>

My suspicion is that Shaun is using cut-and-paste scripts without
understanding what they do or how they work and has included a script
with a call to window.resizeTo (or resizeBy) that is expanding the
window. It certainly isn't something that I would expect to happen
without some sort of instruction to do so. (Then again it might be some
sort of ill-conceived free web host inserted script.)




Centring windows is not as simple as just reading the screen dimensions
and positioning the window accordingly. Apart from being a meaningless
action in a tabbed browser,

Browsers with tab capability still can open a new instance of the
browser window; a new window (child window, secondary window) is still a
new window in such browsers (e.g.: Mozilla, Opera 7).

problems occur with, say, the MDI interface

on Opera, where screen dimensions reflect the desktop but window
positing instructions are relative to the outer window of the interface,
meaning that an attempt to position a window based on the screen
dimensions stands a very realistic chance of resulting in a window that
is entirely out of site.

Yep! Opera 7 is a good example of this.

Multi-monitor displays are another stumbling

block as positioning based on screen dimension may result in the window
being opened across the screen boundaries, partly out of the displayable
desktop area and/or on a different monitor to the browser window, where
it may go unnoticed.

Unfortunately, without any mechanism for determining the type of
multi-monitor display (if any) being used, whether the browser is MDI or
tabbed, or any combination of these, the only reliable approach to
positioning windows is to make no specification at all. In response most
browsers will open a new window over the existing window,

In case of a
<a href="path/filename.html" target="ANewSecondaryWindow"
title="Clicking this link will open in a new window or will reuse an
already opened one">See my garden</a>
the new window left and top coordinates will be offset 15px to the right
and to the bottom from the opener (if non-maximized) in both
Mozilla-based browsers and MSIE 5+. The idea is that this helps users
notice taht a new window has "emerged" on top of the opener. Such 15px
offset is an usability aid.

the one place

that you can be fairly certain that it will be apparent and fully
visible to the user (subject to scriptable window opening being allowed
at all).

Richard.

When a window.open call is done without any specifics to position (left,
top, screenX, screenY are not defined), then new window coordinates will
be those of the last non-maximized window which were stored by the os
(persistent data). So new windows do not have random positions or sizes.

DU

 

[DU]

Why not use screen.availHeight and screen.availWidth for that. The
MDI viewport *is* the available size for windows. (I have suggested
it to them, but maybe it is too big a change).

/L

screen.availHeight and screen.availWidth refer to different areas: they
refer to the available workarea for applications on the screen. I.e. the
whole user screen minus semi-permanent os-dependent applications like
windows taskbar, MS-Office quick launch bar, MS-magnifier and any
os-dependent 3rd party applications (winbar, membar,etc.).

Just see for yourself, make sure you're in MDI with O7:
File/Preferences...Alt+P/Windows/Windows handling/Prefer pages inside window

http://www10.brinkster.com/doctorunclear/HTMLJavascriptCSS/DUWindowsO7.html

DU

 

[Warren Sarle]

(Re: Hi, stupid popup question),

...
The bottom line is that the screen objects of various browsers report
information that is inaccurate, irrelevant and inapplicable. As a
result, the general advice is to never do anything that necessitates an
interest in the screen dimensions. Avoiding the inaccuracy and
inapplicability of the information by never asking the question.

I have a web photo gallery that lets users choose any of three
image sizes to view. By default, you get small images (suitable
for an 800x600 external browser window size). I've been looking
through a Javascript book to see if there might be a way to make
an educated guess about what image size would be best to display.
But this may be a hopeless endeavor, judging from what Richard
says. Would anyone care to offer an opinion as to whether I should
stick with the small images by default or try to do something
more clever?

 

[DU]

Opera 6 (and 5 more so) was a bit flaky (especially when incautiously
scripted) but Opera 7 is proving quite robust. And it is surprising how
many ways there are of crashing IE 6 with JavaScript, and taking the OS
with it.




Theoretically true, though there have been browsers that have allowed
windows to be opened off screen. That is usually considered a security
flaw

not in MSIE 5+

and fixed in later versions.
I wonder which browsers you're talking about. Mozilla still has not
fixed 3 bugs regarding this.

However, some of the multi-monitor systems have the OS report the screen
dimensions to the browser as the smallest rectangle that will encompass
all of the monitor screens used. So if the monitors are not identical
sizes configured as either a block or a strip then there are void areas
that will not be displayed on (or practically accessible from) and of
the monitors. A fairly common configuration of a 24 inch monitor with a
17 inch monitor to the right would have an inaccessible area above the
17 inch monitor making the desktop height up to that of the 24 inch
monitor. From the point of view of the browsers that region is part of
the desktop and an attempt to centre a new browser window is likely to
place the upper right of the new window in that area, making the close,
minimise and maximise buttons and par to the content inaccessible (until
the window is moved). Move on to five or six monitors configured in an L
shape and it is entirely possible for the new window to be completely
out of site.




The existence of tabbed browsers does bring into question the validity
of designing sites to use multiple windows. Most of the justifications
for such a design vanish completely on such a browser (and they do
include browsers based entirely on IE).

I don't agree. There are cases where having 2 browser window is more
suitable than having 2 browser tabs. I can have 2 browser instances, 2
browser windows side by side. How can you view 2 browser tab side by side?

That depends, if it is called the "screen" object it might be reasonably
be argued that what it should report should be related to the screen and
not something else. Making the screen object report the MDI interface
viewport dimensions might help authors who insisted on trying to centre
windows, but not that much as they never seem to bother to check if the
results of ((screen.availWidth - browser.width)/2) is negative, and the
MDI interface viewpoint does not constrain the windows it contains so
that information is not necessarily an appropriate basis for the
positing decisions either.




The bottom line is that the screen objects of various browsers report
information that is inaccurate, irrelevant and inapplicable.

I don't agree on the inaccurate point. I think overall they report
accurate info but there are compatibility difficulties: window.screenX,
window.screenY have no equivalent in MSIE. I.e.:
window.screenY in Mozilla != window.screenTop in MSIE
window.screenY in Opera 7 != window.screenY in Mozilla

I agree that the relevance of such info is quite debatable or at least
largely over-evaluated.

As a

result, the general advice is to never do anything that necessitates an
interest in the screen dimensions. Avoiding the inaccuracy and
inapplicability of the information by never asking the question.

As with all things related to browser scripting, there are plenty of
people who would rather ignore the issues than learn how to cope with
the consequences, but that just means that they are willing to make
themselves look incompetent whenever their scripts encounter any of the
'slightly diverging from the norm' conditions.

Richard.

I deeply believe that amateur website developers over-excessively focus
on issues that they can control and that they believe can bring some
value to their site. Positioning a popup fits perfectly into their
controlling mind. At the same time, they will gladly remove window
resizability, scrollbars (thinking they are not needed but not
considering many usability issues like increasing font size),
statusbar,etc.. and they will feel powerful at controlling the website.
It's sort of a macho-power-trip attitude.

They totally miss the point that these windows are (should be) at the
disposal of users. They over-concentrate on issues and matters which
should matter a lot less than content and suitable design.

DU

 

[Lasse Reichstein Nielsen]

screen.availHeight and screen.availWidth refer to different areas:
they refer to the available workarea for applications on the
screen.

I know that is what it *does*. However, in an MDI client, I don't
think that is what it *should* do.

The "available" area should be the area that is available to the page,
e.g., for creating and placing new windows. That area is exactly the
viewport of an MDI application.

/L

 

[Richard Cornford]

not in MSIE 5+


I wonder which browsers you're talking about. Mozilla
still has not fixed 3 bugs regarding this.

I wasn't thinking of any particular browsers, I know that there are
still plenty about that don't mind if a script attempts to position a
window off screen but I didn't want to disagree with Michael on the
point that they really shouldn't. As we were discussing centring windows
on the screen (presumably with the intention that they be visible) I was
more interested in demonstrating that a script with that intention might
still place a new window out of site and not be in a position to know
that it had done so, rather than getting into whether a script could
deliberately put a new window where it couldn't be seen.

I don't agree. There are cases where having 2 browser window is
more suitable than having 2 browser tabs. I can have 2 browser
instances, 2 browser windows side by side. How can you view 2
browser tab side by side?

You cannot view two browser tabs side by side. But that is what I was
getting at. If a design suggests that it would be suitable to have two
windows side by side but it is not possible to know with certainty that
two windows will be the outcome on the client then rather than worrying
about the best way of attempting to open windows (and inevitably
accepting that it is just not going to happen reliably) it might be
better to re-consider that design and attempt to come up with something
that would be meaningful in any browser.

As I see it, a design that want's to open a second window has to take
into account the possibility that the second window does not open (or is
immediately closed by an external pop-up blocker, detect those condition
and falling back), navigates within the current window and opens in a
tab instead of a distinct window, in addition to the desired outcome of
opening in a new window. So a design that suggests the opening of a new
window implies the need to cope with at least three distinct UI styles
and to come up with a script that can detect, and sensibly respond to,
the failure of the window.open call due to pop-up blockers, etc.
(something that, so far, has never been demonstrated to be possible).

If opening a new window implies an exponential increase in UI complexity
and necessitates a script that has never been written (and I, for one,
believe to be impossible) then maybe it would be more effective to
abandon multi-window designs and instead see how much can be achieved
within a single browser window.

I don't agree on the inaccurate point. I think overall they report
accurate info but there are compatibility difficulties: window.screenX,
window.screenY have no equivalent in MSIE. I.e.:
window.screenY in Mozilla != window.screenTop in MSIE
window.screenY in Opera 7 != window.screenY in Mozilla

On the accuracy point I was thinking of screen objects that report the
same values for avail/Width/Height as the values they report for
width/height (on, say, IceBrowser 5 and Opera versions < 7.02).

I agree that the relevance of such info is quite debatable
or at least largely over-evaluated.

I deeply believe that amateur website developers over-excessively
focus on issues that they can control and that they believe can
bring some value to their site. Positioning a popup fits perfectly
into their controlling mind. At the same time, they will gladly
remove window resizability, scrollbars (thinking they are not
needed but not considering many usability issues like increasing
font size), statusbar,etc.. and they will feel powerful at
controlling the website. It's sort of a macho-power-trip attitude.

(A definition of amateur that seems to include quite a number of people
who are trying to make a living from web site development) I would tend
to leave the "macho-power-trip" judgement until after the individual has
had a chance to react to having the issues pointed out. At least some of
these attitudes seem to be down to attitudes gained in unrelated areas.
Graphic designers trained for (and experienced with) designing for paper
and print. Programmers used to coding for consistent and predictable
environments where they expect to actively control the UI. Coming to
terms with working in a medium as fluid as a web page and programming
for an environment as inconsistent as web browser DOMs is not going to
happen over night.

They totally miss the point that these windows are (should be)
at the disposal of users. They over-concentrate on issues and
matters which should matter a lot less than content and suitable
design.

Yes, there is a lot of concentration on the wrong issues. To my mind
worrying about the positioning, sizing, re-sizing, etc. of new windows
or communicating between them once they exist are all issues that come
after the issues around opening windows with scripts, and especially
detecting and coping with the failure of the attempt. Until a reliable
strategy exists to address that issue everything that follows is of no
more than academic interest.

Richard.

 

[Richard Cornford]

I know that is what it *does*.

At least since they fixed it late last year (about 7.02).

However, in an MDI client,
I don't think that is what it *should* do.

The "available" area should be the area that is available to
the page, e.g., for creating and placing new windows. That
area is exactly the viewport of an MDI application.

But the MDI interface does not constrain its inner window size (when not
maximised) and the MDI window is freely re-sizeable. Neither of which
are a problem as such but centring windows based on the MDI window size
would still be problematic because people never check to see if
((screen.availWidth - newWindowWidth)/2) is negative, which it often
would be when the MDI window is small, and negative values are treated
as if they are positive so the centred window would still be offset down
and right, maybe to the pint of being out of site in a small MDI window.
Which is exactly the same situation is exists now.

Another problem is the people who use screen size to redirect to a page
"tailored" to the screen size, a small MDI window might be redirected to
PDA or smaller desktop content when the user would prefer to re-size the
MDI window to suite larger content, or with less considerate scripts the
site might attempt to reject the browser because it thought the screen
was too small.

Of course fluid page design removes the necessity for the scripts that
impose the second problem, but abandoning efforts to position new
windows renders the values reported by the screen object irrelevant
anyway.

There has got to be a reasonable argument for an object called "screen"
to provide information related to the screen. It just might be necessary
for script authors to recognise that the screen is not really relevant
to them.

Richard.