Positioning a child window relative to the parent

  • Thread starter Geoffrey H. Goldberg
  • Start date
G

Geoffrey H. Goldberg

I have made a remote control window which opens from its parent. On
loading, the remote is positioned relative to the screen using
window.moveTo(x,y).

What I would like to happen is the remote control to open docked in a
specific location relative to the parent (opener).

Fortunately, I need this to work ONLY in IE, so at least I don't have to
worry about cross-browser issues.

Does anyone know how to open a window realtive to an anchor in the parent
wiondow?
 
G

Geoffrey H. Goldberg

Thank you for the response.

What you have shown allows positioning relative to the parent window, but
what I am looking for is a means of positioning relative to an *element* in
that window. For instance, I would like to open the window on top of a
table cell in the parent. Obviously that value will be variable depending
upon what toolbars, etc. the user has opened in the parent. Somehow I must
pass the anchor's postion in the parent window.
 
G

Gérard Talbot

Geoffrey H. Goldberg wrote :
Thank you for the response.

What you have shown allows positioning relative to the parent window,

?
No. The requested popup window is positioned relative to the user
screen, not the parent window.

but
what I am looking for is a means of positioning relative to an *element* in
that window. For instance, I would like to open the window on top of a
table cell in the parent.


Why do you need a requested popup window to display whatever is in that
popup window? I'm sure there is a more suitable and user-friendly way to
do what your webpage requirements are without resorting to a secondary
window.

Obviously that value will be variable depending
upon what toolbars, etc. the user has opened in the parent.

There is no direct and reliable way to figure out the user's browser
window toolbars and their height or total height. Even in Mozilla-based
browsers, the user can customize an hidden pref to avoid revealing the
outerHeight of the browser window.

Gérard
 
G

Geoffrey H. Goldberg

Why do you need a requested popup window to display whatever is in that
popup window? <

My website is a project management portal encompassing 13 projects and a
total of something like 650 menu items. (And yes, they are all important).
I can not use frames because I do not want to sacrifice the real estate
(some of the data tables are very large). So I made a remote control window
for the menu system(s). It serves the purpose well. At present it opens
in the top left corner of the screen. The only reason why I want it to open
"docked" in the homepage (the parent window) is for aesthetics.
I'm sure there is a more suitable and user-friendly way to do what your
webpage requirements are without resorting to a secondary window.<

Not that I can think of, and I have studied this issue rather intensely.
Actually the site is extremely user friendly. I am curious as to why you
would assume that since the system uses two windows that it must be
otherwise. This system is used exclusively for engineering project
management, and not for casual website browsing.
 
V

VK

<your table>
<td
onclick="window.open('foo.html','foo','width=200,height=100,left='+this.offsetLeft+',top='+this.offsetTop+'\'')">
<your table>

Needs to be tune up slightly (+/-) for FF who has a separate opinion of
the coords calculation.
 
G

Geoffrey H. Goldberg

What this does is position the remote window relative to the screen at the
same offset as the anchor has in its cell.

I need a means of resolving the position of the inner browser window
relative to the screen. Once I have that it would be a relatively simple
matter to perform the math (by adding the offsets to the anchor, which are
constants).

The question comes down to: does IE report the position of the inner
browser window?

(I am not concerned with FF (or NN) because all of my users employ IE.)
 
R

Richard Cornford

Geoffrey H. Goldberg wrote:
The question comes down to: does IE report the position of
the inner browser window?
<snip>

If the event that triggers the opening of the window is a mouse event
then it will have screenX/Y values that represent the screen offset of
the mouse and clientX/Y values that represent the offset of the mouse
into the client-area/viewport. The difference between these two values
is the screen offset of the client-area/viewport.

Then the sum of the page element's offset in the client-area (which is
also the element's page offset adjusted by the degree to which the page
is scrolled) and the screen offset of the viewport is the screen
co-ordinates of the page element.

Watch out for the borders on the root element of the page, which IE
defaults to 2px, and represents as the clientTop/Left properties of the
root element. It is likely that at lest one set of offsets will need
adjusting by that value (the symptoms of needing to make the adjustments
are finding a positioned result that is 2px off from where you were
expecting it).

Which element (HTML or BODY) is the root element depends upon the
setting of - document.compatMode -. If that property is not implemented
in IE (<= 5.5) then the BODY is the root element, if it is implemented
(IE 6) then a value of "CSS1Compat" indicates that the HTML element is
the root, and BODY otherwise.
"VK" <[email protected]> wrote in message
<snip>

Please do not top-post to comp.lang.javascript. It will often be taken
as an indication that you are not interested in having your questions
answered. Certainly do not make the mistake of taking VK's behaviour
(or advice, without third party confirmation) as indication a wise cause
of action. See the group's FAQ:-

<URL: http://www.jibbering.com/faq/ >

Richard.
 
G

Gérard Talbot

Geoffrey H. Goldberg wrote :
My website is a project management portal encompassing 13 projects and a
total of something like 650 menu items. (And yes, they are all important).
I can not use frames because I do not want to sacrifice the real estate
(some of the data tables are very large). So I made a remote control window
for the menu system(s).

I am not sure I understand. You don't want to use frames because, you
say, a frame will use screen real estate on the user screen and, at the
same time, you kinda suggest - implicitly or not - that a secondary
window will not use screen real estate.

It serves the purpose well. At present it opens
in the top left corner of the screen. The only reason why I want it toopen
"docked" in the homepage (the parent window) is for aesthetics.

It's kinda difficult to actually see/verify what you do, want to do,
etc... An url would certainly answer a lot of questions.

When you say "docked", you want the secondary window to be permanently
fixed in the main browser window viewport, right? to be maintained at
the same coordinates?
Not that I can think of, and I have studied this issue rather intensely.
Actually the site is extremely user friendly.

Does it pass WCAG 1.0 level A? Just asking.

I am curious as to why you
would assume that since the system uses two windows that it must be
otherwise.

Yes, I maintain that there is always an equally or better system than
resorting to a secondary window. I claim this after studying the issue
for many years.

This system is used exclusively for engineering project
management, and not for casual website browsing.

Gérard
 
G

Gérard Talbot

VK wrote :
Yes, sure. Why do you prefer to trust this group instead of Microsoft
itself? You thing they will try to cheat you? (a right thinking
though).
<http://msdn.microsoft.com/library/d...author/dhtml/reference/objects/obj_window.asp>
look for screenX and screenY properties there.

screenX and screenY are window properties supported by Netscape and
Mozilla-based browwsers and are not supported by MSIE. screenLeft and
screenTop are NOT equivalent MSIE properties.

Gérard
 
G

Gérard Talbot

Richard Cornford wrote :
Geoffrey H. Goldberg wrote:


<snip>

If the event that triggers the opening of the window is a mouse event
then it will have screenX/Y values that represent the screen offset of
the mouse and clientX/Y values that represent the offset of the mouse
into the client-area/viewport. The difference between these two values
is the screen offset of the client-area/viewport.

I think I understand what Geoffrey wants or is looking for. I think he
would need clientX/Y values on a onclick event firing on a pseudo-link.
Then such coordinates would set the top and left positions of the
secondary window. This is definately doable for MSIE 6; I have done a
demo on this before.
Then the sum of the page element's offset in the client-area (which is
also the element's page offset adjusted by the degree to which the page
is scrolled) and the screen offset of the viewport is the screen
co-ordinates of the page element.

Watch out for the borders on the root element of the page, which IE
defaults to 2px,


Actually it's 1px; 1px for the 4 sides of the root element's border.
Anyway, this would not interfere with the objEvent.clientX and
objEvent.clientY coordinates.

and represents as the clientTop/Left properties of the
root element. It is likely that at lest one set of offsets will need
adjusting by that value (the symptoms of needing to make the adjustments
are finding a positioned result that is 2px off from where you were
expecting it).

Which element (HTML or BODY) is the root element depends upon the
setting of - document.compatMode -. If that property is not implemented
in IE (<= 5.5) then the BODY is the root element, if it is implemented
(IE 6) then a value of "CSS1Compat" indicates that the HTML element is
the root, and BODY otherwise.

[snipped]

Richard, Is this explained and/or illustrated somewhere in the FAQ? Just
asking. I couldn't find this explained in the FAQ...

Gérard
 
G

Gérard Talbot

Danny wrote :
Yes it does, in mozilla you use .innerWidth and .innerHeight, in IE
is document.body.clientWidth and document.body.clientHeight.

Danny

innerWidth and innerHeight include respectively vertical scrollbar and
horizontal scrollbar if rendered in Netscape and Mozilla-based browsers;
document.body.clientWidth and document.body.clientHeight do NOT include
respectively vertical scrollbar and horizontal scrollbar if rendered.
You would need to use
document.documentElement.offsetWidth and
document.documentElement.offsetHeight
in MSIE 6 in standards compliant rendering mode as window.innerWidth and
window.innerHeight equivalents.

Gérard
 
G

Geoffrey H. Goldberg

I am not sure I understand. You don't want to use frames because, you
say, a frame will use screen real estate on the user screen and, at the
same time, you kinda suggest - implicitly or not - that a secondary
window will not use screen real estate.<

A frame uses a fixed amount of real estate. The remote control (the child
window) can be repositioned, minimised or closed.

It's kinda difficult to actually see/verify what you do, want to do, etc...
An url would certainly answer a lot of questions. <
Agreed. However the website is not public.
When you say "docked", you want the secondary window to be permanently
fixed in the main browser window viewport, right? to be maintained at the
same coordinates?<
No! If I did, I would just use frames. Docked means to bring to its
default location. Just like your TV's remote control is "docked" on your
table. You pick it up when you use it. I just want the remote to open at
the specified postion (for looks only). I have the system working
beautifully now, except I have both windows moved to 0,0 onload.
Does it pass WCAG 1.0 level A?<
I couldn't care less if it does or not.
I maintain that there is always an equally or better system than resorting
to a secondary window. I claim this after studying the issue for many
years.<
You should learn about remote controls.
 
G

Geoffrey H. Goldberg

Thanks for your reply Richard -
If the event that triggers the opening of the window is a mouse event
then it will have screenX/Y values that represent the screen offset of
the mouse and clientX/Y values that represent the offset of the mouse
into the client-area/viewport. The difference between these two values
is the screen offset of the client-area/viewport.

I would like to trigger the openeing of the child onload of the parent. :-(

(IE 6) then a value of "CSS1Compat" indicates that the HTML element is
the root, and BODY otherwise.

The one thing that I have going for me is that all users are using the same
browser: IE 6.
(Yet, still I can't figure this out! Woa is me!)

- Geoffrey
:)
 
R

Richard Cornford

Gérard Talbot said:
Richard Cornford wrote :
I think I understand what Geoffrey wants or is looking for.

And I am answering what appears to be the question quoted above. ;)

Actually it's 1px; 1px for the 4 sides of the root element's
border.

Ah, that will probably be the XP style borders, it is defiantly 2px in
Windows Classic style (and I don't like the XP look so I turn it off).
The important thing is to reed the value from the clientTop/Left vales
of the root element as that will be the value that applies in either
case (an if the page decides to set a different value with CSS).
Anyway, this would not interfere with the objEvent.clientX and
objEvent.clientY coordinates.

It may need to be taken into account if you want to relate an element's
page offsets to mouse co-ordinates. It certainly does need to be taken
into account for cross-browser work as everything is simplified by
adjusting to the same top left point as other browsers use; client
co-ordinates relative to the inside of the viewport border.

Richard, Is this explained and/or illustrated somewhere in the
FAQ? Just asking. I couldn't find this explained in the FAQ...

There is an explanation (to some degree) and an example at:-

<URL:
http://www.jibbering.com/faq/faq_notes/not_browser_detect.html#bdScroll
If you think you can do better, or create something more specific then
feel free.

Richard.
 
R

RobG

Geoffrey said:
Thanks for your reply Richard -




I would like to trigger the openeing of the child onload of the parent. :-(

That will likely make it an unrequested pop-up and may be blocked, even
in IE, so you may need to account for this.
The one thing that I have going for me is that all users are using the same
browser: IE 6.
(Yet, still I can't figure this out! Woa is me!)

It seems incredible that with all Microsoft's hacks and extensions to
browser behaviour they never thought to provide a simple method to
accurately determine or set the position of a browser window within a
screen. It appears that IE only provides the position of the document
or viewport, not the browser window. Other browsers provide
self.screenX/Y.

Have a poke around this part of quirksmode:

<URL:http://www.quirksmode.org/viewport/compatibility.html>
 
G

Geoffrey H. Goldberg

That will likely make it an unrequested pop-up and may be blocked, even
in IE, so you may need to account for this.

Good point Rob. However, that is the way that I have it behaving now. The
only issue is *where* the window opens. (At present I have the popup load
at 0,0 and the main window scoots itself over to 0,0 onload of the child..)

I have the luxury of specifying my users' IE configurations. I have them
set my website as a trusted site, and I have it allow pop ups from it. (I
use pop ups for a variety of functions in theis site.)

It seems incredible that with all Microsoft's hacks and extensions to
browser behaviour they never thought to provide a simple method to
accurately determine or set the position of a browser window within a
screen. It appears that IE only provides the position of the document
or viewport, not the browser window. Other browsers provide
self.screenX/Y.

I agree! WTF?

Have a poke around this part of quirksmode:

<URL:http://www.quirksmode.org/viewport/compatibility.html>
Thanks for the reference. That page looks like its got some very useful
stuff.
 
V

VK

screenX and screenY are window properties supported by Netscape and
Mozilla-based browwsers and are not supported by MSIE. screenLeft and
screenTop are NOT equivalent MSIE properties.

Guys, guys (it's good I decided to check this thread, look what did ya
do' :)
When I say "do not trust completely to Microsoft" I did not mean
disregard whatever they say and paint your own picture of everything
from the scratch.

Of course event object has screenX and screenY properties and this is
exactly what you need. By some bug on MSDN site articles about "event"
and "window" are pointed by the same URL in IE (not my fault but sorry
anyway).
Here the manually edited URL to look for:
<http://msdn.microsoft.com/library/d.../author/dhtml/reference/objects/obj_event.asp>

Here the script OP needs (IE only as requested, may play with delta (d)
to adjust it to your particular environment):

<script type="text/javascript">
function doPopup(evt,obj,url) {
var d = 10;
var w = 200;
var h = 110;
var x = event.screenX;
var y = event.screenY;
var x = ((x+w+d)>screen.availWidth)? (x-w-d) : x+d;
var y = ((y+h+d)>screen.availHeight)?(y-h-d) : y+d;
var winArgs = 'width='+w+',height='+h;
winArgs+= ',left='+x+',top='+y;
var win = window.open(url,'_blank',winArgs);
}
</script>

and somewhere in say 1001st cell of your table you have a link like:
<a href="javascript:void(0)"
onclick="doPopup(event,this,'foo.html')">Extra info</a>

P.S. And please note Microsoft changed the security limitations for
popups (I just discovered it). Despite it's still stated everywhere in
MSDN that width/height must be *equal or more than 100px*, in IE 6 it
must be *at least one pixel more than 100px*. So if you set say width
to 100px, IE will disregard it and it will use default width instead.
This is what meant by saying "do not trust completely to official
docs". But overall if Microsoft says that this is done for that and
have such and such properties, you have reasons to believe it.
 
T

Thomas 'PointedEars' Lahn

VK said:
Yes, sure. Why do you prefer to trust this group instead of Microsoft
itself?

Because it is known that MSDN Library is -- politely speaking -- incomplete?


PointedEars
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,764
Messages
2,569,566
Members
45,041
Latest member
RomeoFarnh

Latest Threads

Top