Window object properties, IE/NS

[Christopher Benson-Manica]

In some old Javascript we have, we try to determine whether the client
is IE or Netscape (assume for the purposes of this question that the
question can be resolved satisfactorily) and tailor the script to it:

var myOpen=open(url, 'subWin', 'width=600, height=400,*A*resizable=1,scrollbars=1' );
if ( myOpen && !myOpen.closed )
{
myOpen.focus();
}
*B*

If it's IE, *A* is left=300,top=300
If it isn't,*B* is myOpen.screenX=300; myOpen.screenY=300;

As of a few weeks ago, we no longer support Netscape 4. Assume that
this code must work only on recent IE and Netscape versions. The
question: Is this distinction still necessary to achieve the same
effect in both browsers? Is there a better way of doing it if it is?

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.

[Randy Webb]

Christopher Benson-Manica wrote:

In some old Javascript we have, we try to determine whether the client
is IE or Netscape (assume for the purposes of this question that the
question can be resolved satisfactorily) and tailor the script to it:

http://www.jibbering.com/faq/#FAQ4_26

What "tailoring" do you need for the different browsers? I bet if its a
legitimate concern, it can be addressed with object detection instead of
browser detection.

--
Randy
Chance Favors The Prepared Mind
comp.lang.javascript FAQ - http://jibbering.com/faq/

[Christopher Benson-Manica]

Randy Webb <hi************@aol.com> spoke thus:

http://www.jibbering.com/faq/#FAQ4_26
As I said, "assume that it works." The amount of code that does this
here is quite extensive, and works to the satisfaction of the people
who wrote it (not me).
What "tailoring" do you need for the different browsers? I bet if its a
legitimate concern, it can be addressed with object detection instead of
browser detection.

Well, I don't KNOW whether it's a legitemate concern in this case -
that's why (and what) I asked. The script uses top=q,left=r to set
the window position if it thinks it's dealing with IE, and
window.screenY=q,window.screenX=r if it thinks it's dealing with
Netscape - I want to know if this is the best way to go about setting
the position of the browser window.

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.

[DU]

Christopher Benson-Manica wrote:

In some old Javascript we have, we try to determine whether the client
is IE or Netscape (assume for the purposes of this question that the
question can be resolved satisfactorily) and tailor the script to it:

var myOpen=open(url, 'subWin', 'width=600, height=400,*A*resizable=1,scrollbars=1' ); ^
Error right here. The windowFeatures string list must be without any
blank spaces; so everything after width=600 should be ignored by
Mozilla-based browsers.
if ( myOpen && !myOpen.closed )
{
myOpen.focus();
}
*B*

If it's IE, *A* is left=300,top=300
If it isn't,*B* is myOpen.screenX=300; myOpen.screenY=300;
You can set (and then can NOT set) the position of the popup that way. I
personally filed a bugfile at bugzilla to make screenX and screenY
readonly properties of window. Either you should use left and top in the
windowFeatures string list (best because left and top are cross-browser
supported) or use a moveTo() call (not best since many user prevent
moving of already created+opened windows via UI pref settings in
Mozilla-based browsers and Opera 7.x). Unless you have some convincing
reasons, I would *not* use top and left anyway because this could well
irritate users. Personally, I have user_pref settings in my user.js file
which would make a window badly offset since I restore automatically
most toolbars of any/all windows opened as they are created. Best IMO is
to avoid top and left.

As of a few weeks ago, we no longer support Netscape 4. Assume that
this code must work only on recent IE and Netscape versions. The
question: Is this distinction still necessary to achieve the same
effect in both browsers?
No if you use top and left.

Is there a better way of doing it if it is?

Avoid using top and left. Persistent data on last non-maximized window
will be the user's natural top and left coordinates and is IMO the best
web designer's policy.

DU

[Christopher Benson-Manica]

DU <dr*******@hotwipethismail.com> spoke thus:

Avoid using top and left. Persistent data on last non-maximized window
will be the user's natural top and left coordinates and is IMO the best
web designer's policy.

That would indeed be a possible course of action, except for the fact
that this window is already a non-maximized popped-up window.
Therefore, we have to set the position of the window *somehow* - so
top and left are the way to go, then?

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.

[DU]

Christopher Benson-Manica wrote:

DU <dr*******@hotwipethismail.com> spoke thus:

Avoid using top and left. Persistent data on last non-maximized window
will be the user's natural top and left coordinates and is IMO the best
web designer's policy.

That would indeed be a possible course of action, except for the fact
that this window is already a non-maximized popped-up window.

And there was another non-maximized window to such non-maximized
popped-up window which was closed before.
Therefore, we have to set the position of the window *somehow* - so
top and left are the way to go, then?

No you don't really or absolutely need to. The operating system, at
least Windows, will store the coordinates of the last non-maximized
window (before the one you are opening) when it was closed and then will
"serve" these again for MSIE 6, NS 7.x and Mozilla. I've tested this
before very carefully. E.g.:

<a href="path/MyGarden.html" target="RequestedPopup1" title="Clicking
this link will open a new, separate window">My garden</a>
(...)
<a href="path/MyFamily.html" target="RequestedPopup2" title="Clicking
this link will open a new, separate window">My family</a>

Now, open MyGarden.html and when you close it, the top and left corner
coordinates of that browser window will be stored by the os (at least
Windows does). Let's say as you close the MyGarden.html window, the
browser (top,left) corner coordinates are (123,456). Now click the
MyFamily link and it will open the new window at screen coordinates
(123,456).

It would be easy to create a demo page for this, to verify this in
various browsers and in different operating systems.

DU

[DU]

DU wrote:

Christopher Benson-Manica wrote:

DU <dr*******@hotwipethismail.com> spoke thus:

Avoid using top and left. Persistent data on last non-maximized
window will be the user's natural top and left coordinates and is IMO
the best web designer's policy.

That would indeed be a possible course of action, except for the fact
that this window is already a non-maximized popped-up window.

And there was another non-maximized window to such non-maximized
popped-up window which was closed before.

Therefore, we have to set the position of the window *somehow* - so
top and left are the way to go, then?

No you don't really or absolutely need to. The operating system, at
least Windows, will store the coordinates of the last non-maximized
window (before the one you are opening) when it was closed and then will
"serve" these again for MSIE 6, NS 7.x and Mozilla. I've tested this
before very carefully. E.g.:

<a href="path/MyGarden.html" target="RequestedPopup1" title="Clicking
this link will open a new, separate window">My garden</a>
(...)
<a href="path/MyFamily.html" target="RequestedPopup2" title="Clicking
this link will open a new, separate window">My family</a>

Now, open MyGarden.html and when you close it, the top and left corner
coordinates of that browser window will be stored by the os (at least
Windows does). Let's say as you close the MyGarden.html window, the
browser (top,left) corner coordinates are (123,456). Now click the
MyFamily link and it will open the new window at screen coordinates
(123,456).

It would be easy to create a demo page for this, to verify this in
various browsers and in different operating systems.

DU

This behavior (storing and then re-using persistent data for positioning
a new window and/or for defining the new window dimensions) is very
reliable, consistent on Windows. I was able to file
"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
at bugzilla because of this behavior, because the bug involved closely
that behavior.

DU

[Christopher Benson-Manica]

DU <dr*******@hotwipethismail.com> spoke thus:

And there was another non-maximized window to such non-maximized
popped-up window which was closed before.
What?
No you don't really or absolutely need to. The operating system, at
least Windows, will store the coordinates of the last non-maximized
window (before the one you are opening) when it was closed and then will
"serve" these again for MSIE 6, NS 7.x and Mozilla. I've tested this
before very carefully. E.g.:

I doubt I made myself sufficiently clear (my fault); I'll be
detailed this time. Start with the main browser window - maybe
maximized, maybe not. From here we pop up an unmaximized window,
specifying its position (currently) using the methods I described in
my original post. From this new window, we must pop up *another*
unmaximized window and offset its position from that of its parent.
Left to its own devices, it would end up at the same screen
coordinates as its parent, correct? That isn't the behavior we're
looking for in this case. So we have to take specific action to
ensure that this new window isn't on top of the old one, right? My
question is, what is the most appropriate such action to take that
will work for both Netscape and IE? Or are we forced to cater to each
browser separately, as we currently do?

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.

[DU]

Christopher Benson-Manica wrote:

DU <dr*******@hotwipethismail.com> spoke thus:

And there was another non-maximized window to such non-maximized
popped-up window which was closed before.

What?

No you don't really or absolutely need to. The operating system, at
least Windows, will store the coordinates of the last non-maximized
window (before the one you are opening) when it was closed and then will
"serve" these again for MSIE 6, NS 7.x and Mozilla. I've tested this
before very carefully. E.g.:

I doubt I made myself sufficiently clear (my fault); I'll be
detailed this time. Start with the main browser window - maybe
maximized, maybe not. From here we pop up an unmaximized window,
specifying its position (currently) using the methods I described in
my original post. From this new window, we must pop up *another*
unmaximized window

[1] see addendum on this

and offset its position from that of its parent. Left to its own devices, it would end up at the same screen
coordinates as its parent, correct?
No. Left to its own devices (that is without any left and/or top and/or
screenX and/or screenY windowFeatures in the window.open() call), it
will end up 15 pixels to the right and 15 pixels to the bottom of its
parent, of its opener. And this behavior is consistent in MSIE 6, NS 7.x
and Mozilla-based browsers (possibly again an Windows os dependency).
The reasoning behind this behavior is to ensure that the user has the
best chance to notice that a new separate window was just created,
opened and that it is on top of the opener, parent. There is an
usability reason behind these 15 pixels offsets.
That is one reason why it's impossible to force maximization of new,
separate window (requested popups): if the parent, opener is not
maximized itself, then its child popup window will NOT be maximized:
this is a 100% certainty ...unless the browser offers a setting to make
all new pages maximized (like Opera 7.x).
I explained all this before in alt.html or in this newsgroup (can't
remember) about a year ago.

That isn't the behavior we're looking for in this case. So we have to take specific action to
ensure that this new window isn't on top of the old one, right? My
question is, what is the most appropriate such action to take that
will work for both Netscape and IE?
Take no action of this nature. :)
But do follow some advices given by J. Nielsen, WAI guidelines. Some
major corporations (e.g.: Sun Microsystems) have applied these guidelines:

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

World Wide Web Consortium Accessibility Initiative regarding popups,
2000
"(...) 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."
http://www.w3.org/WAI/wcag-curric/sam77-0.htm

I myself use an icon image in the link and I code the title attribute too.

Or are we forced to cater to each browser separately, as we currently do?

I could give you better feedback on all this if I could see, examine
your page. As a general rule, I now recommend against positioning popup:
there are factors the web designer does not control (like window
viewport size of the opener, user prefs forcing toolbars to appear like
in my case... and I'm not alone, proxomitron for MSIE can do the same,
etc..).

DU
--
[1] I would absolutely avoid a chain/tree of popup windows. I use
requested popup windows on my site in about 6 files and I always make
sure (or try) to not open more than 1 requested popup at a time: I reuse
the already opened popup otherwise I open a new one.
"Research shows that most users don't like to run more than one
application at a time. In fact, many users are confused by multiple
applications."
Windows User Experience team,
Microsoft Windows User Experience Frequently Asked Questions: Why is the
taskbar at the bottom of the screen?,
March 2001
http://msdn.microsoft.com/library/de...l/winuifaq.asp

[Christopher Benson-Manica]

DU <dr*******@hotwipethismail.com> spoke thus:

[1] see addendum on this
I appreciate your position (I loathe popups myself), but this is one
of a number of situations where we use pop-up-agains (to coin a term).
We try to cater to the desires of our customers, and they seem to be
happy with our multi-up (another term coined...) scheme.
No. Left to its own devices (that is without any left and/or top and/or
screenX and/or screenY windowFeatures in the window.open() call), it
will end up 15 pixels to the right and 15 pixels to the bottom of its
parent, of its opener. And this behavior is consistent in MSIE 6, NS 7.x
and Mozilla-based browsers (possibly again an Windows os dependency).
Hm. Now that I look at our code some more, the overarching point to
all this jockeying for (window) position seems to be to consistently
open windows (at least some of them) in the center of the screen.
Setting aside the question of whether that's desireable (the
spec-meisters are apparently happy with it), do we not have to fiddle
with top and left to obtain this behavior?
I could give you better feedback on all this if I could see, examine
your page. As a general rule, I now recommend against positioning popup:
there are factors the web designer does not control (like window
viewport size of the opener, user prefs forcing toolbars to appear like
in my case... and I'm not alone, proxomitron for MSIE can do the same,
etc..).

Unfortunately, these pages are not accessible to the general public
(or I'd be happy to link you to them). The short version of what is
probably a long story is that to maintain consistency with our
existing pages (and code) I basically *have* to maintain this
behavior. I could, of course, merely duplicate the code that's used
elsewhere, but much of it is ancient - we only just moved away from
supporting NS4 a few weeks ago, and so one joyless task is to wipe out
all the excess code we used to support layers and tiptoe around NS4's
stylesheet issues, among its other foibles.

Anyway, I've rambled. I do appreciate your help and explanations, but
it looks like top and left are my only option :)

--
Christopher Benson-Manica | I *should* know what I'm talking about - if I
ataru(at)cyberspace.org | don't, I need to know. Flames welcome.