open.window() and passing URL string

[Gérard Talbot]

ASM wrote :

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/DOM:window.open#Note_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/DOM:window.open#Note_on_position_and_dimension_error_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.

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

 

[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

 

[Gérard Talbot]

ASM wrote :

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?

or advantage, depends what you want

Well, this is where we can discuss this issue.

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".

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

 

[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/DOM:window.open#Toolbar_and_chrome_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)



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

 

[ASM]

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.

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

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');

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 !

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,resizable=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)

 

[Randy Webb]

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

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.

 

[ASM]

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/DOM:window.open#Toolbar_and_chrome_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.

 

[Gérard Talbot]

ASM 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)



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.

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

 

[Gérard Talbot]

ASM 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

 

[ASM]

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

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