open.window() and passing URL string

[wayne]

Hey there... I'm having some problems passing url parameters with an
open.window command. I'm not terribly familiar with java script but
here is the code below.

When executed it opens the window properly but does not pass the
parameter.

(this is part of a coldfusion template)

<a href="##"
onClick="window.open('photopage#.htm?region=#slave .region#','prop1','location,menubar,height=600,wid th=800,scrollbars,resizable,toolbar=yes');
return false;"><img src="#trim(photodir)#/#photoname4#" width="90"
height="60" hspace="2" vspace="2" border="2"></a>
Thanks,
Wayne

[RobG]

wayne wrote:

Hey there... I'm having some problems passing url parameters with an
open.window command. I'm not terribly familiar with java script but
here is the code below.

When executed it opens the window properly but does not pass the
parameter.

(this is part of a coldfusion template)

<a href="##"
onClick="window.open('photopage#.htm?region=#slave .region#','prop1','location,menubar,height=600,wid th=800,scrollbars,resizable,toolbar=yes');
return false;"><img src="#trim(photodir)#/#photoname4#" width="90"
height="60" hspace="2" vspace="2" border="2"></a>

Are all those hashes '#' from coldfusion? Your link above will do
nothing in a browser with JavaScript disabled or not available. Put
your URL into the href attribute and open the popup using something like:
<script type="text/javascript">
function popWin( u, n, atts ){
aWin = window.open( u, n, atts);
}
</script>

<a href="photopage#.htm?region=#slave.region#" target="_blank"
onclick="
popWin(this.href,'prop1','height=600,width=800');
return false;
"><img ... ></a>
Now the link will open in a pop-up whether the user has scripting or
not. If scripting is available, the window may have your suggested
attributes. If scripting is not available, the URL will open in a
standard pop-up.

--
Rob

[ASM]

wayne wrote:

Hey there... I'm having some problems passing url parameters with an
open.window command. I'm not terribly familiar with java script but
here is the code below.

When executed it opens the window properly but does not pass the
parameter.
if browser reads : <img src="#trim(photodir)#/#photoname4#"
and #trim(photodir)# or #photoname4#
are coldFusion entries, there is a problem with your coldFusion code ...
or your ColdFusion Server

Which parameter(s) do you want to send ?
region=#slave.region# ->
region's value is #slave.region# or slave.region ?
because # has signification in an url (anchor)

I would have done, and you would have to get in browser :
photopage.htm?region=slave.region#somewhere
where :
- photopage.htm is the page to load
- region is a parameter
- slave.region is the parameter value
- somewhere is an anchor on the page to scroll to

photopage.htm?region=slave.region&city=Small-Town#somewhere
- region = 'slave.region'
- city = 'Small-Town'

in my test, in popup window, location bar displays exactly :
photopage.htm?region=slave.region&city=Small-Town#somewhere

parameters well are send (no coldFusion used)
(this is part of a coldfusion template)

<a href="##"
onClick="window.open('photopage#.htm?region=#slave .region#','prop1','location,menubar,height=600,wid th=800,scrollbars,resizable,toolbar=yes');
return false;"><img src="#trim(photodir)#/#photoname4#" width="90"
height="60" hspace="2" vspace="2" border="2"></a>

wouldn't something be missing :
window.open('photopage#.htm?region=#slave.region#
insteed of :
window.open('#photopage#.htm?region=#slave.region#
--
Stephane Moriaux et son [moins] vieux Mac

[wayne]

Thanks Rob... worked great!

Hey? is there a way to bring a window (opened with an open.window
script) back in to focus should it get buried under another window. It
seems to be a common problem. A user opens a window with the
open.window script then the user clicks somewhere on their desktop and
the window disappears under another application. From that point on
any subsquent clicks on the original link with the open.window command
delivers the content to the window but since it's buried the user
doesn't know.

Thanks,
Wayne

[RobG]

wayne wrote:

Thanks Rob... worked great!
It's usual practice to quote what you are replying to so we know what
worked great ... but thanks for the glory! ;-)

Hey? is there a way to bring a window (opened with an open.window
script) back in to focus should it get buried under another window.
Yes. Test the window.closed property, if it's false, the window has
been closed. An example below:
<script type="text/javascript">

var aWin;

function popWin( u, n, atts ){
if ( aWin && ! aWin.closed ) {
if ( aWin.location.href != u ) {
aWin.location.href = u;
}
aWin.focus();
} else {
aWin = window.open( u, n, atts);
aWin.focus();
}
}

</script>
seems to be a common problem. A user opens a window with the
open.window script then the user clicks somewhere on their desktop and
the window disappears under another application. From that point on
any subsquent clicks on the original link with the open.window command
delivers the content to the window but since it's buried the user
doesn't know.

Thanks,
Wayne

--
Rob

[Gérard Talbot]

RobG wrote :

<script type="text/javascript">

var aWin;

function popWin( u, n, atts ){
if ( aWin && ! aWin.closed ) {
if ( aWin.location.href != u ) {
aWin.location.href = u;
}
aWin.focus();
} else {
aWin = window.open( u, n, atts);
aWin.focus();
Can you explain why you need this instruction on the line above?
The way I see this is: if the window pointer is inexistent in memory or
if the window has been closed, then create the window. Now, why would
you need to focus it right after creating it?
}
}

</script>

Gérard
--
remove blah to email me

[Gérard Talbot]

RobG wrote :

<script type="text/javascript">
function popWin( u, n, atts ){
aWin = window.open( u, n, atts);
}
</script>

<a href="photopage#.htm?region=#slave.region#" target="_blank"
onclick="
popWin(this.href,'prop1','height=600,width=800');
return false;
"><img ... ></a>

Why not target="prop1" ?
Also, note that the requested window will not be resizable and will not
render scrollbars if needed, if content overflows requested window
dimensions. Also the window.open() call tries to disable status bar. For
many reasons, none of this is recommendable.

Gérard
--
remove blah to email me

[Randy Webb]

Gérard Talbot said the following on 8/26/2005 6:17 PM:

RobG wrote :

<script type="text/javascript">
function popWin( u, n, atts ){
aWin = window.open( u, n, atts);
}
</script>

<a href="photopage#.htm?region=#slave.region#" target="_blank"
onclick="
popWin(this.href,'prop1','height=600,width=800');
return false;
"><img ... ></a>

Why not target="prop1" ?

<a href="...." target="myWindow"
onclick="popWin(this.href,this.target .....); return false"..
Is definitely a preferred way, especially from a maintenance standpoint.
--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly

[ASM]

Gérard Talbot wrote:

RobG wrote :

<script type="text/javascript">
function popWin( u, n, atts ){
aWin = window.open( u, n, atts);
}
</script>

<a href="photopage#.htm?region=#slave.region#" target="_blank"
onclick="
popWin(this.href,'prop1','height=600,width=800');
return false;
"><img ... ></a>

Why not target="prop1" ?

because return false; :-)
Also, note that the requested window will not
Wasn't it what wanted ?
For
many reasons, none of this is recommendable.

Which reasons ?

I think I've seen at mozilla.org(*)
that height and width would have to be dimensions of viewing area
So, f you know which space you need,
why not to freeze a naked window to this size ?
(*) http://developer.mozilla.org/en/docs/DOM:window.open

--
Stephane Moriaux et son [moins] vieux Mac

[RobG]

Gérard Talbot wrote:

RobG wrote :

<script type="text/javascript">
function popWin( u, n, atts ){
aWin = window.open( u, n, atts);
}
</script>

<a href="photopage#.htm?region=#slave.region#" target="_blank"
onclick="
popWin(this.href,'prop1','height=600,width=800');
return false;
"><img ... ></a>

Why not target="prop1" ?

Indeed.
Also, note that the requested window will not be resizable and will not
render scrollbars if needed, if content overflows requested window
dimensions. Also the window.open() call tries to disable status bar. For
many reasons, none of this is recommendable.
The OP can attempt to set whatever attributes he wants. I reduced the
attributes to width and height for brevity.

In regard to your post above regarding the superfluous focus(), yeah,
it's superfluous.

Gérard
--
remove blah to email me

--
Rob

[RobG]

ASM wrote:

Gérard Talbot wrote:

RobG wrote :

<script type="text/javascript">
function popWin( u, n, atts ){
aWin = window.open( u, n, atts);
}
</script>

<a href="photopage#.htm?region=#slave.region#" target="_blank"
onclick="
popWin(this.href,'prop1','height=600,width=800');
return false;
"><img ... ></a>

Why not target="prop1" ?

because return false; :-)

That just stops the default window opening if scripting is available, it
does not preclude giving the window some other name.

Also, note that the requested window will not

Wasn't it what wanted ?

For many reasons, none of this is recommendable.

Which reasons ?

Because browsers put messages in the status bar that users like to read,
it annoys users if they can't. For example, Safari tells me if a link
will (attempt to) open a new window, so I can put it into a tab instead.

From the page you referenced:

<URL:http://developer.mozilla.org/en/docs/DOM:window.open#Note_on_status_bar>

I think I've seen at mozilla.org(*)
that height and width would have to be dimensions of viewing area
Maybe you misunderstood the notes on height. The article is not
suggested that the height be set to full screen, it just documented the
fact that you can do it.

Browser vendors have a need to supply the same features as their
competitors, even if they may feel it's not a good feature. If you read
some of the entries in bugzilla you'll see that there is constant debate
about whether or not Mozilla should support various Microsoft
proprietary IE features (e.g. element IDs as global variables, support
for document.all).
So, f you know which space you need,
why not to freeze a naked window to this size ?

(*) http://developer.mozilla.org/en/docs/DOM:window.open

Opening a window to 'full screen' size is not polite - let the user
decide what size they want it.
--
Rob

[ASM]

RobG wrote:

ASM wrote:

Gérard Talbot wrote:

Why not target="prop1" ?
because return false; :-)

That just stops the default window opening if scripting is available, it
does not preclude giving the window some other name.

Right ! alors ceci :

<a href="photopage#.htm?region=#slave.region#" target="prop1"
onclick="popWin('','prop1','height=600,width=800') ;"><img ... ></a>

Also, note that the requested window will not

? popWin() { aWin = window.open() }

will 'aWin' not be the name of popup ?

for me : 'prop1' is the target of the window 'aWin'
(seen a kind of spec. spelling 'name' for both 'name' and 'target'
I don't agree with this confusioning
even knowing one of name is for JS and other for HTML)
Which reasons ?

Because browsers put messages in the status bar that users like to read,
it annoys users if they can't. For example, Safari tells me if a link
will (attempt to) open a new window, so I can put it into a tab instead.

Hu ... anyway Safari doesn't accept to close its status bar, no ?
(and fiew others do so)
To open a tab in a small popup unresizable is it a good idea ? :-)

height and width would have to be dimensions of viewing area

Maybe you misunderstood the notes on height. The article is not
suggested that the height be set to full screen, it just documented the
fact that you can do it.

by viewing area I did mean the free area inside the browser's window
(think in ref.d url(*) they call it like that)
they suggest that height and width attributes of window.open() are
these of free area (viewing area) of popup
(NC4, NC6, Moz, IE, Opera)
Browser vendors have a need to supply the same features as their
competitors, even if they may feel it's not a good feature.

it is a real headache !
http://www.quirksmode.org/viewport/compatibility.html
(and NC4 is no more referenced here. iCab, Safari ignored)

So, f you know which space you need,
why not to freeze a naked window to this size ?

(*) http://developer.mozilla.org/en/docs/DOM:window.open

Opening a window to 'full screen' size is not polite - let the user
decide what size they want it.

Never I did suggest a full screen
and did stay to your own example (800/600)
even if I can understand a full screen *popup* using during a short time

full screen != unresizable (except IE with ist fullscreen attribute ?)

--
Stephane Moriaux et son [moins] vieux Mac

[Gérard Talbot]

RobG wrote :

Gérard Talbot wrote:

RobG wrote :

<script type="text/javascript">
function popWin( u, n, atts ){
aWin = window.open( u, n, atts);
}
</script>

<a href="photopage#.htm?region=#slave.region#" target="_blank"
onclick="
popWin(this.href,'prop1','height=600,width=800');
return false;
"><img ... ></a>

Why not target="prop1" ?

Indeed.

Also, note that the requested window will not be resizable and will
not render scrollbars if needed, if content overflows requested window
dimensions. Also the window.open() call tries to disable status bar.
For many reasons, none of this is recommendable.

The OP can attempt to set whatever attributes he wants. I reduced the
attributes to width and height for brevity.

Ok.
In regard to your post above regarding the superfluous focus(), yeah,
it's superfluous.

Ok. :)

Gérard
--
remove blah to email me

[Gérard Talbot]

ASM wrote :

Gérard Talbot wrote:

RobG wrote :

<script type="text/javascript">
function popWin( u, n, atts ){
aWin = window.open( u, n, atts);
}
</script>

<a href="photopage#.htm?region=#slave.region#" target="_blank"
onclick="
popWin(this.href,'prop1','height=600,width=800');
return false;
"><img ... ></a>

Why not target="prop1" ?

because return false; :-)

return false cancels the default action of the element, here it cancels
the default action of the link. In case javascript is disabled, then the
link should open the photopage#.htm?region=#slave.region# resource in a
named window called "prop1". This is important if you want to maximize
the resources your code uses from the users' system resources.
Re-opening and re-using/re-cycling an already opened secondary window is
the most efficient way to use the user's system resources.

"The purpose of the return false in the code is to cancel default action
of the link: if the onclick event handler is executed, then there is no
need to execute the default action of the link. But if javascript
support is disabled or non-existent on the user's browser, then the
onclick event handler is ignored and the browser loads the referenced
resource in the target frame or window (...)"
http://developer.mozilla.org/en/docs...Best_practices

Also, note that the requested window will not

Wasn't it what wanted ?

For many reasons, none of this is recommendable.

Which reasons ?

I think I've seen at mozilla.org(*)
that height and width would have to be dimensions of viewing area

No. Read again. When the web developer codes the window.open() call and
the height and width windowFeature, he's requesting some particular
value for the height and width of the browser window viewport of that
new window to be.

Everything is nicely explained at
http://developer.mozilla.org/en/docs...ow.open#height
So, f you know which space you need,
why not to freeze a naked window to this size ?

Without knowing it, you are exactly making my point regarding always
ensuring that a window is resizable and renders scrollbar(s) if content
exceeds, overflows requested window dimensions. In this case, if the web
developer goes wrong with the requested width and/or height, then a
normal, standard fallback mechanism should prevail and should let the
user adjust the size of that new window according to his needs. Failure
to do so makes the window inaccessible, difficult to use, frustrating to
the user.
Often, the user gets a new window without knowing it in advance; and
often, he gets a crippled window. The result is easy to figure out: the
user closes the stupid window and leaves the web developer's site
without him never knowing about his bad work.
(*) http://developer.mozilla.org/en/docs/DOM:window.open

Gérard
--
remove blah to email me

[ASM]

Gérard Talbot wrote:

ASM wrote :

Gérard Talbot wrote:

RobG wrote :

<a href="photopage#.htm?region=#slave.region#" target="_blank"
onclick="
popWin(this.href,'prop1','height=600,width=800');
return false;
"><img ... ></a>
Why not target="prop1" ?
because return false; :-)

return false cancels the default action of the element

[snip]

return false canceling the element (link) do abort link target too,
so having same target in your open.window() is of no use
(that's what I said)

I think I've seen at mozilla.org(*)
that height and width would have to be dimensions of viewing area

No. Read again.

I do not speak english very well but it is writen :
[ height
Specifies the height of the content area,
viewing area of the new secondary window in pixels
^^^^^^^^^^^^
.... ] ^---- I do speak of this area
Everything is nicely explained at
http://developer.mozilla.org/en/docs...ow.open#height

What have I to understand ?
I think they speak of inside height (free height to display)
in oposite of 'outerHeight' that is the complete height

So, f you know which space you need,
why not to freeze a naked window to this size ?

Without knowing it, you are exactly making my point regarding always
ensuring that a window is resizable and renders scrollbar(s) if content
exceeds,

of course.

--
Stephane Moriaux et son [moins] vieux Mac

[Randy Webb]

ASM said the following on 8/27/2005 8:51 PM:

Gérard Talbot wrote:

ASM wrote :

Gérard Talbot wrote:

RobG wrote :

>
> <a href="photopage#.htm?region=#slave.region#" target="_blank"
> onclick="
> popWin(this.href,'prop1','height=600,width=800');
> return false;
> "><img ... ></a>
>

Why not target="prop1" ?
because return false; :-)

return false cancels the default action of the element

[snip]

return false canceling the element (link) do abort link target too,
so having same target in your open.window() is of no use
(that's what I said)

Not sure I agree with that since what you are saying is that if I do this:

<a href="someWhere.html" target="prop1" onclick="someFunction(this.href,
this.target, props here);return false">Some text</a>

Then the function will ignore the target and it won't. It will open the
resource in the window named prop1 and open that window if it's not open.

Or, is there a browser you have that doesn't follow that behavior?

The major disadvantage of target="_blank" is that if the user clicks on
10 different links (or even the same link 10 times), they get 10 new
windows. Where if the target is the same for all links, and the script
picks up this.target, then the user only gets 1 window.

The advantage of this.target in the script is that you only have one
place to change the target and the script picks it up. If you specify
names in both places, you have to change 2 places in the code, instead of 1.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly

[Gérard Talbot]

ASM wrote :

Gérard Talbot wrote:

ASM wrote :

Gérard Talbot wrote:

RobG wrote :

>
> <a href="photopage#.htm?region=#slave.region#" target="_blank"
> onclick="
> popWin(this.href,'prop1','height=600,width=800');
> return false;
> "><img ... ></a>
>

Why not target="prop1" ?
because return false; :-)

return false cancels the default action of the element

[snip]

return false canceling the element (link) do abort link target too,

Have you tried this? Have you verified this? You can create a little
webpage and verify this yourself, you know..
so having same target in your open.window() is of no use
(that's what I said)

You can read the documentation on all this yourself. And if you don't
understand the documentation or don't believe the documentation, then
you can try the parameters with a webpage.

Gérard
--
remove blah to email me

[Gérard Talbot]

ASM wrote :

Gérard Talbot wrote:

RobG wrote :

<script type="text/javascript">
function popWin( u, n, atts ){
aWin = window.open( u, n, atts);
}
</script>

<a href="photopage#.htm?region=#slave.region#" target="_blank"
onclick="
popWin(this.href,'prop1','height=600,width=800');
return false;
"><img ... ></a>

[snipped]
For many reasons, none of this is recommendable.

Which reasons ?

I mentioned resizability of the window, scrollbar(s) presence if content
exceeds requested window dimensions, statusbar presence which is forced
now by MSIE 6 SP 2.

The reasons are mentioned at the very URL you have provided.
(*) http://developer.mozilla.org/en/docs/DOM:window.open

Gérard
--
remove blah to email me

[ASM]

Gérard Talbot wrote:

I mentioned resizability of the window, scrollbar(s) presence if content
exceeds requested window dimensions, statusbar presence which is forced
now by MSIE 6 SP 2.
If I have a doc sized (i.e. photo)
correct sized popup will not need scrollbars
and statusbar (not only IE-6-SP-2 force this, Opera, Safari ...)
doesn't enter in window.opens' height
The reasons are mentioned at the very URL you have provided.

(*) http://developer.mozilla.org/en/docs/DOM:window.open

of course if doc to display in popup can't be set in absolutly known
sizes, at least popup resizability has to be planed
--
Stephane Moriaux et son [moins] vieux Mac

[ASM]

Randy Webb wrote:

ASM said the following on 8/27/2005 8:51 PM:

return false canceling the element (link) do abort link target too,
so having same target in your open.window() is of no use
(that's what I said)
Not sure I agree with that since what you are saying is that if I do this:

<a href="someWhere.html" target="prop1" onclick="someFunction(this.href,
this.target, props here);return false">Some text</a>

Then the function will ignore the target and it won't. It will open the
resource in the window named prop1 and open that window if it's not open.

because 'return false' and because popWin open a window nammed 'aWin',
even with 10 clicks, you'll get an alone popup (if JS is enabled)
(as I don't know what does someFunction, I can't judge its doing)
The major disadvantage
or advantage, depends what you want
of target="_blank" is that if the user clicks on
10 different links (or even the same link 10 times), they get 10 new
windows. Where if the target is the same for all links, and the script
picks up this.target, then the user only gets 1 window.
Yes ... but ... no need to have same target in html and JS
The advantage of this.target in the script is that you only have one
place to change the target and the script picks it up.

function pop(h,t,p) { truc=window.open(h,'',p) }
doesn't need to refer to the link target

and
function pop(h,t,p) { truc=window.open('',t,p) }
will need to refer to the link target
and will not need to refer to he href

usualy, I use something like last example
--
Stephane Moriaux et son [moins] vieux Mac

[Gérard Talbot]

ASM wrote :

Gérard Talbot wrote:

I mentioned resizability of the window, scrollbar(s) presence if
content exceeds requested window dimensions, statusbar presence which
is forced now by MSIE 6 SP 2.

If I have a doc sized (i.e. photo)
correct sized popup will not need scrollbars

How do you know for sure that your popup is correctly sized for all the
visitors? Please elaborate.

http://developer.mozilla.org/en/docs..._on_scrollbars
and statusbar (not only IE-6-SP-2 force this, Opera, Safari ...)
doesn't enter in window.opens' height
Of course these do not enter in the window.open's height but they do
reduce such height if the whole window can not be rendered entirely on
the screen of the user. Again, I'm pointing you to the dimension error
correction mechanism implemented in Mozilla-based browsers and MSIE 6
SP2: "No part of the new window can be initially positioned offscreen."
http://developer.mozilla.org/en/docs...ror_correction
So, when you do height=600 and width=800, then I immediately know that
your requested dimensions will not appear as intended on all of your
800x600 scr. res. visitors and the height will also be adjusted for a)
several of your 1024x768 scr. res. visitors who can force several
toolbars on the secondary window and b) all your Opera 7+ users. So,
your code is not best. Your code assumes that a secondary window height
(viewing area, content area, viewport) can be 600px high: that is not
true for a very wide majority of users.

The reasons are mentioned at the very URL you have provided.

(*) http://developer.mozilla.org/en/docs/DOM:window.open

of course if doc to display in popup can't be set in absolutly known
sizes,

Even when they can be set in absolutely known sizes. No web developer
can know in advance and for sure what will be the exact dimensions of
the new secondary window to be created (inner viewing area). So if this
is unreliable, the best, safe, sound policy is to always allow the new
window to be created to be resizable, have scrollbars if needed.

at least popup resizability has to be planed

This is where we differ. You think you can establish such possibility in
advance: I think you can not because of many unknown factors unavailable
(user prefs, os settings, font settings, toolbar dimensions, etc.) to
scripts. So the safe and cautious policy should be to always include
resizable,scrollbars,status for many reasons and for reasons that are
mentioned at
http://developer.mozilla.org/en/docs/DOM:window.open

Gérard
--
remove blah to email me

[ASM]

Gérard Talbot wrote:

[naked popup sized]

This is where we differ. You think you can establish such possibility in
advance: I think you can not because of many unknown factors unavailable
(user prefs, os settings, font settings, toolbar dimensions, etc.)
Sure, I expect displaying a jpeg wil not be corrupted by :
- font settings
- toolbars dimensions (non asked)
- os setting : a pixel = 1 pixel (anywhere I hope)
scripts. So the safe and cautious policy should be to always include
resizable,scrollbars,status for many reasons and for reasons that are
mentioned at
http://developer.mozilla.org/en/docs/DOM:window.open

and ...
I don't know how run a browser for bad seeyer(*)

(*) almost blind - Fr: mal-voyant (in english ?)

But you're right a resizable=1 is not really an handicap :-)

--
Stephane Moriaux et son [moins] vieux Mac

[Gérard Talbot]

ASM wrote :

Randy Webb wrote:

ASM said the following on 8/27/2005 8:51 PM:

return false canceling the element (link) do abort link target too,
so having same target in your open.window() is of no use
(that's what I said)

Not sure I agree with that since what you are saying is that if I do
this:

<a href="someWhere.html" target="prop1"
onclick="someFunction(this.href, this.target, props here);return
false">Some text</a>

Then the function will ignore the target and it won't. It will open
the resource in the window named prop1 and open that window if it's
not open.

because 'return false' and because popWin open a window nammed 'aWin',
even with 10 clicks, you'll get an alone popup (if JS is enabled)
(as I don't know what does someFunction, I can't judge its doing)

Well, let's say, then, that Randy meant to use the following code:

<script type="text/javascript">
function popWin( u, n, atts ){
aWin = window.open( u, n, atts);
}
</script>

so that his "someFunction" is your "popWin". Ok?

The major disadvantage

or advantage, depends what you want

Well, this is where we can discuss this issue.

of target="_blank" is that if the user clicks on 10 different links
(or even the same link 10 times), they get 10 new windows. Where if
the target is the same for all links, and the script picks up
this.target, then the user only gets 1 window.

Yes ... but ... no need to have same target in html and JS

Yes you do need to give the same target name in html and JS (like you
say) if you want a js disabled user to be able to benefit from your
code. You need to give all your links with the same target name, say,
"prop1".

What you do not seem to understand here is that there is a difference,
in terms of advantage, an user-friendly difference between

<a href="File1.html" target="prop1">Go to File 1</a>
<a href="File2.html" target="prop1">Go to File 2</a>
<a href="File3.html" target="prop1">Go to File 3</a>

and

<a href="File1.html" target="_blank">Go to File 1</a>
<a href="File2.html" target="_blank">Go to File 2</a>
<a href="File3.html" target="_blank">Go to File 3</a>

If you want 10 links to open 10 unnamed different windows, then I can't
see how this can be advantageous to the users.

Consider that modern browsers can override a target="prop1" and open
such link in an unnamed window if that is what the user really wants to
do. The user gets flexibility, more flexibility with target="prop1" that
he does not get with target="_blank".

The advantage of this.target in the script is that you only have one
place to change the target and the script picks it up.

function pop(h,t,p) { truc=window.open(h,'',p) }
doesn't need to refer to the link target

The window will open in a _blank window (url will show "about:blank"),
in an *unnamed* window.

Such function, written as is, does not refer to the link target, that's
true, and such function is not a flexible, reusable function either.

Furthermore, creating unnamed, non-recyclable, non-reusable secondary
window is not user-friendly and can only contribute to confuse users.

and
function pop(h,t,p) { truc=window.open('',t,p) }
will need to refer to the link target
and will not need to refer to he href

I've seen this way of creating new window and it does not make sense
without dynamically populating its content. And that is another issue...
usualy, I use something like last example

Gérard
--
remove blah to email me

[Gérard Talbot]

ASM wrote :

Gérard Talbot wrote:

[naked popup sized]

This is where we differ. You think you can establish such possibility
in advance: I think you can not because of many unknown factors
unavailable (user prefs, os settings, font settings, toolbar
dimensions, etc.)

Sure, I expect displaying a jpeg wil not be corrupted by :
- font settings
- toolbars dimensions (non asked)

Are you actually saying you can remove by force

- the titlebar of your users' browser?
- the statusbar of your users' browser?
- the toolbars of Opera 7+ users?

" Mozilla and Firefox users can force new windows to always render
the menubar by setting
dom.disable_window_open_feature.menubar
to true in about:config or in their user.js file
(http://www.mozilla.org/support/firefox/edit#user). "
http://developer.mozilla.org/en/docs...hrome_features

Now, how do you remove by force the menubar of that jpeg window of yours?

Same thing with toolbar, personalbar, location bar, Site navigation
toolbar and any other custom toolbar like Tabextension, multibar or web
developer bar, etc... How do you *force* the removal of such toolbars
with your scripts??
when these Mozilla-based-browser users have
dom.disable_window_open_feature.directories set to true
dom.disable_window_open_feature.personalbar set to true
dom.disable_window_open_feature.location set to true
dom.disable_window_open_feature.menubar set to true
etc.etc.et.

My os theme is large fonts. So, this setting makes my titlebar higher.
How does your script calculate and figure out this height? The answer is
that it can not.

My window taskbar is always visible and it is enlarged: that is my own
default setting. Does your script really take into consideration this?

I have a 1024x768 scr. res. At best, the secondary window inner content
area will render 505 pixels under *my* normal conditions. How can you or
your script query and calculate such value? for me or any other users?
The answer is that you can not!

I can modify several other settings which your script - or any script -
will never be able to notice. Not only the user can force the presence
of toolbars but he can also set the dimensions via os settings (or
userChrome.css settings).
And here, we have not even discussed the default margin of browsers
(MSIE 6, Mozilla-based browsers) on the root document, even for a
"naked" jpeg window.
- os setting : a pixel = 1 pixel (anywhere I hope)

scripts. So the safe and cautious policy should be to always include
resizable,scrollbars,status for many reasons and for reasons that are
mentioned at
http://developer.mozilla.org/en/docs/DOM:window.open

and ...
I don't know how run a browser for bad seeyer(*)

(*) almost blind - Fr: mal-voyant (in english ?)

What if an user has MS-Magnify opened in Windows? The available area for
his os workarea for applications will greatly reduce the available
rendering space for your "naked" jpeg window. How does your script takes
that into consideration when your script does not query for the
screen.availHeight value to begin with?

Some people at work have a permanent Office quick launch bar on the
desktop reducing that workarea for applications. Does your script detect
such bar and calculate/anticipate such height value?
But you're right a resizable=1 is not really an handicap :-)

Gérard
--
remove blah to email me

[ASM]

Gérard Talbot wrote:

ASM wrote :
[popup named'aWin' with target'prop1']
Well, let's say, then, that Randy meant to use the following code:

<script type="text/javascript">
function popWin( u, n, atts ){
aWin = window.open( u, n, atts);
}
</script>

so that his "someFunction" is your "popWin". Ok?
I think it is.
What you do not seem to understand here is that there is a difference,
in terms of advantage, an user-friendly difference between

<a href="File1.html" target="prop1">Go to File 1</a>
<a href="File2.html" target="prop1">Go to File 2</a>
<a href="File3.html" target="prop1">Go to File 3</a>

and

<a href="File1.html" target="_blank">Go to File 1</a>
<a href="File2.html" target="_blank">Go to File 2</a>
<a href="File3.html" target="_blank">Go to File 3</a>

If you want 10 links to open 10 unnamed different windows, then I can't
see how this can be advantageous to the users.
I didn't want to discuss about oportunity to use '_blank' or not,
but only did try to say that, in this circumptance, the name of the
target of link has no importance, and have not to be absolutly same as
this of popup because the link is canceled by JS.
not more

by otherway,
When I was surfing with NC4.5 without DSL
I did use to do so by myself because refreshing pages was too long.
Today I use tabs :-) to do not jump up and down in historic.

If it's good for me, it could be good for others (no ! was joke)
Consider that modern browsers can override a target="prop1" and open
such link in an unnamed window if that is what the user really wants to
do. The user gets flexibility, more flexibility with target="prop1" that
he does not get with target="_blank".
modern browser my NC4.5 ?
(it will be very happy to learn that :-) )

with right-clic user decides what he wants, by this way a link with
popup and/or targetted to blank or moon doesn't matter.
Of course, if href is correct and respectfull.

The advantage of this.target in the script is that you only have one
place to change the target and the script picks it up.

Yes but I do prefer the other way :
my function has the right target
and I only need to write this good and always same target
( a copy-past does the job )

Chacun voit midi à sa porte :-)
Sun shines for everybody
function pop(h,t,p) { truc=window.open(h,'',p) }
doesn't need to refer to the link target

The window will open in a _blank window (url will show "about:blank"),
in an *unnamed* window.

no, if JS, it is open in window named 'truc'.
Unfortunatly this 'truc' has no target,
and will can't be reached by html.
It is of no importance since anyway we use JS.
And that doesn't forbid browser to display what it has to (url, title,
satus, if corresponding bars alowed by popup)
Such function, written as is, does not refer to the link target, that's
true, and such function is not a flexible, reusable function either.
the function as is no, but it can do some more use :

<a href="page1.htm" target="foo"
onclick="if(!truc)
pop((this.href,'','width=400,height=300,resizable= 1');
else { truc.location=this.href; truc.focus(); }
return false">re-use</a>

or

<a href="page2.htm" target="foo"
onclick="if(truc) truc.close();
pop(this.href,'','width=435,height=520,resizable=1 ');
return false">other-use</a>
Furthermore, creating unnamed, non-recyclable, non-reusable secondary
window is not user-friendly and can only contribute to confuse users.

users have not to enter in code ... they click and wait to see !
sacrebleu !

and
function pop(h,t,p) { truc=window.open('',t,p) }
will need to refer to the link target
and will not need to refer to he href

I've seen this way of creating new window and it does not make sense
without dynamically populating its content. And that is another issue...

<a href="page.htm" target="foo"
onclick="pop('','foo','width=435,height=520,resiza ble=1');">other</a>

will open 'page.htm' in target 'foo' in popup 'truc'
without any dynamism if JS enabled (a target is a target)
if no JS -> hop! blank window as you said.
My NC4.5, and IE5 do so (hope FF folowes this way)
--
Stephane Moriaux et son [moins] vieux Mac

[Randy Webb]

ASM said the following on 8/28/2005 4:11 PM:

Randy Webb wrote:

ASM said the following on 8/27/2005 8:51 PM:

return false canceling the element (link) do abort link target too,
so having same target in your open.window() is of no use
(that's what I said)

Not sure I agree with that since what you are saying is that if I do
this:

<a href="someWhere.html" target="prop1"
onclick="someFunction(this.href, this.target, props here);return
false">Some text</a>

Then the function will ignore the target and it won't. It will open
the resource in the window named prop1 and open that window if it's
not open.

because 'return false' and because popWin open a window nammed 'aWin',
even with 10 clicks, you'll get an alone popup (if JS is enabled)

And if you use the same target in the HTML that you use as the window
named in the JS code, the user still only gets one window.
(as I don't know what does someFunction, I can't judge its doing)

return false has nothing to do with JS opening a window. The advantage
to using the target in the link, via JS, is that you don't have to edit
in two places. It also allows the link to open in the same secondary
window if something happens in the page to stop JS from executing
(errors or anything else that stops JS executing), then what the user
ends up with is a link that still works, and still re-uses the same
secondary window again.

Without using the same names, you end up with the possibility of a typo
causing problems. But if I were doing a page that had many many links in
it, then I wouldn't pass this.href and this.target, I would pass this as
the only parameter, then grab this.href and this.target in the function
and open the new window.

But, what does the user get in the above scenarios if they use a popup
blocker that re-defines window.open? Norton does that very thing. What
they get is - nothing. The href isn't followed because of the return
false and no window gets opened because the popup blocker redefined
window.open.

Its another reason _not_ to use popups at all.

--
Randy
comp.lang.javascript FAQ - http://jibbering.com/faq & newsgroup weekly

[ASM]

Gérard Talbot wrote:

ASM wrote :

Gérard Talbot wrote:

[naked popup sized]

This is where we differ. You think you can establish such possibility
in advance: I think you can not because of many unknown factors
unavailable (user prefs, os settings, font settings, toolbar
dimensions, etc.)
Sure, I expect displaying a jpeg wil not be corrupted by :
- font settings
- toolbars dimensions (non asked)

Are you actually saying you can remove by force

- the titlebar of your users' browser?
- the statusbar of your users' browser?
- the toolbars of Opera 7+ users?

titlebar has not to be in the heiht of window.open
all as statusbar

Opera ... with all its particularism ... it is a browser ?
If somebody choice Opera and find sonething malfunction :
complain to Opera !
" Mozilla and Firefox users can force new windows to always render
the menubar by setting
dom.disable_window_open_feature.menubar
to true in about:config or in their user.js file
Yes ! c'est la mort des popups. It's death of popups we now.
And all we could say now on this subject will be :
'if your browser accept to do, please, we will very glad if we could
launch a litte popup all sel-handfmade for your own convenience. Thank
you very much a lot and all that ...' :-)
(http://www.mozilla.org/support/firefox/edit#user). "
http://developer.mozilla.org/en/docs...hrome_features
Now, how do you remove by force the menubar of that jpeg window of yours?
? on Mac that doesn't matter, it is in sreen and out of window
buy a Mac all of you. :-)
etc.etc.et.

My os theme is large fonts. So, this setting makes my titlebar higher.
not my problem non yours if window.open()
(except perhaps with IE Win ? but IE is it yet a browser to day ?)
How does your script calculate and figure out this height? The answer is
that it can not.
no, it's not my feature, but this of browser, I have not to consider it.
the JS screen-height would have to be free screen height
(out of taskbar)
My window taskbar is always visible and it is enlarged: that is my own
default setting. Does your script really take into consideration this?
of course : 1) see below 2) screen-height is not for dogs
if my photo is too big : or it is to big and you'll use lifts
or I resize it on the fly (and I do not not because it's a non sens)

and then ? normaly, if popup is too big, it has not to enlarge in height
itself more than screen free space (in width, by its titlebar you can
move it to the left if necessary).
That doesn't work like this on PC Win ?
Go to buy ... :-)
and, anyway, you can tell that free height to him in your function
I have a 1024x768 scr. res. At best, the secondary window inner content
area will render 505 pixels under *my* normal conditions. How can you or
your script query and calculate such value? for me or any other users?
The answer is that you can not!
I understand anything of what you say !
What did you do with your PC ?
It's time to buy a 2nd monitor for my little popup :)

Seriously, I do not understand your meaning about 'your' secondary
window limited in size
It's my code in the page which will launch the popup
that decides (if possible) to display of not all these uselles bars
and to hold complete free screen place if needed.

Or do you mean you have taskbar and menubar and titlebar so big
that only 505 px are free in height on your screen.
Popup will do with that.
You know you can bend down the taskbar ? and get back some more space.
It is the only good thing M$ did with its Windows.
I can modify several other settings which your script - or any script -
will never be able to notice. Not only the user can force the presence
of toolbars but he can also set the dimensions via os settings (or
userChrome.css settings).
And here, we have not even discussed the default margin of browsers
(MSIE 6, Mozilla-based browsers) on the root document, even for a
"naked" jpeg window.
if it is, it is your choice and you know how to do to scroll the content.
I will not pay to you a 30" monitor that you can see last photo of my
mother in law :-)

margin doesn't matter : I display my photos in background (no marge)
(with invible div sized to sizes of photo -> lifts if necessary)
What if an user has MS-Magnify opened in Windows? The available area for
his os workarea for applications will greatly reduce the available
rendering space for your "naked" jpeg window. How does your script takes
that into consideration when your script does not query for the
screen.availHeight value to begin with?
It's what I said about mal-voyant
I've not a PC but hope that MS-Magnify is so clever that Apple one is.
And, one more :
height popup can never be bigger than free height screen.
what I could code ( window.open('photo.jpg','','height=3000') )
the screen will not enlarge this size.
(Unfortunatly! I would have apreciated)
It is much better, and we *have*, to detect those free screen sizes
before to size the popup.
Some people at work have a permanent Office quick launch bar on the
desktop reducing that workarea for applications. Does your script detect
such bar and calculate/anticipate such height value?

What that's more ! an Office Quick Launch that can't be cover ?
Anybody can learn them how to use it ?
All as the taskbar ?
If you leave M$ to try allways to help you and to do so to cover your
screen with useless things, you can keep your PC off.
--
Stephane Moriaux et son [moins] vieux Mac

[Gérard Talbot]

ASM wrote :

Gérard Talbot wrote:

ASM wrote :

[popup named'aWin' with target'prop1']

Well, let's say, then, that Randy meant to use the following code:

<script type="text/javascript">
function popWin( u, n, atts ){
aWin = window.open( u, n, atts);
}
</script>

so that his "someFunction" is your "popWin". Ok?

I think it is.

What you do not seem to understand here is that there is a difference,
in terms of advantage, an user-friendly difference between

<a href="File1.html" target="prop1">Go to File 1</a>
<a href="File2.html" target="prop1">Go to File 2</a>
<a href="File3.html" target="prop1">Go to File 3</a>

and

<a href="File1.html" target="_blank">Go to File 1</a>
<a href="File2.html" target="_blank">Go to File 2</a>
<a href="File3.html" target="_blank">Go to File 3</a>

If you want 10 links to open 10 unnamed different windows, then I
can't see how this can be advantageous to the users.

I didn't want to discuss about oportunity to use '_blank' or not

*You* opened that door many posts ago.

, but only did try to say that, in this circumptance, the name of the
target of link has no importance
Your opinion. Not mine. The name of the target of link has an
importance. target="prop1" has to be preferred over target="_blank". I
explained clearly why.

, and have not to be absolutly same as this of popup because the link is canceled by JS.
That's not what we have been discussing about. A few posts ago, I
originally asked you a simple question:
why not target="prop1"
and you brought up a reason (canceling the target value) that isn't
really there. You're the one who brought the issue of using
target="_blank" in links, you know.
not more

by otherway,
?
When I was surfing with NC4.5 without DSL
I am not following you here. I don't know what you're talking about.
I did use to do so by myself because refreshing pages was too long.
Today I use tabs :-) to do not jump up and down in historic.

If it's good for me, it could be good for others (no ! was joke)

Consider that modern browsers can override a target="prop1" and open
such link in an unnamed window if that is what the user really wants
to do. The user gets flexibility, more flexibility with target="prop1"
that he does not get with target="_blank".

modern browser my NC4.5 ?
(it will be very happy to learn that :-) )

with right-clic user decides what he wants, by this way a link with
popup and/or targetted to blank or moon doesn't matter.

No he can not load an unnamed window, a target="_blank" one into an
already existing window that could be reused. That is what you have
failed to understand.
Of course, if href is correct and respectfull.

You do not understand. The flexibility available for links with
target="prop1" is not there for links with target="_blank". One can open
a link with target="prop1" into an unnamed window, a _blank one; the
reverse is not true. If you do not understand this, then read again
carefully what you have been replied clearly so far.

The advantage of this.target in the script is that you only have one
place to change the target and the script picks it up.

Yes but I do prefer the other way :
my function has the right target
and I only need to write this good and always same target
( a copy-past does the job )

I don't know what you are replying to here.

Gérard
--
remove blah to email me

[Gérard Talbot]

ASM wrote :

Gérard Talbot wrote:

ASM wrote :

Gérard Talbot wrote:

[naked popup sized]

This is where we differ. You think you can establish such
possibility in advance: I think you can not because of many unknown
factors unavailable (user prefs, os settings, font settings, toolbar
dimensions, etc.)
Sure, I expect displaying a jpeg wil not be corrupted by :
- font settings
- toolbars dimensions (non asked)

Are you actually saying you can remove by force

- the titlebar of your users' browser?
- the statusbar of your users' browser?
- the toolbars of Opera 7+ users?

titlebar has not to be in the heiht of window.open

Yes but your script has to consider that too because, like I told you
already and like I've repeated again, browsers have mechanism regarding
browser window dimensions: "No part of the new window can be initially
positioned offscreen."
So you can't ignore this toolbar and all of the other toolbars over
which you have no control, no knowledge, no way to measure, etc..

You just can not request a 600px height for a new window and expect
everything to happen according to your script code: that's not how it works.

Gérard
--
remove blah to email me

[ASM]

Gérard Talbot wrote:

ASM wrote :

Last post because never we talk about same thing
you : '_blank' <-> 'prop1'
me : 'prop1' <-> 'foo'

thread following = misunderstanding :
I didn't want to discuss about '_blank' but about 'prop1'
from one specific function to open a popup

but we learnd it is better if target of popup has the target of link
even if it is not used
that for a lot of reasons several time explained

Yes but I do prefer the other way :
my function has the right target
and I only need to write this good and always same target
( a copy-past does the job )

I don't know what you are replying to here.

to this famous 'pro1' and ist use

I replied :
- my popup function *has* 'prop1'
- no need to tell this function on calling which is the target
- because each link *has* target 'prop1'
and you can use in header :
<base target="prop1">
which fix each link targetting in once alone time

see you soon :-)
--
Stephane Moriaux et son [moins] vieux Mac