If you don't use the "win" variable outside the function,
make it a local variable.
As there are a number of JavaScript capable browsers that do not have a
window.open function I would additionally like to see the above line
wrapped in appropriate tests. Else it will generate an error and deprive
the script the option of controlled fall-back. An - if(window.open) -
test seems like a good starting point, except that Pocket IE apparently
lacks a global 'window' property so even that test will error ("window
is null or not an object!, though Pocket IE does not report errors by
default).
The fall-back for a browser without a window.open function should be
navigation within the same window, so the user can get to see the
content. To achieve that the AREA tag could become:-
<area SHAPE=RECT COORDS="216,154,414,296" HREF="1.htm"
ALT="Billede 1"
onclick="return NewWindow(this.href,'link','566','400','no');">
- and the - NewWindow - function could return false to cancel the
navigation and return true to allow the fall-back of navigating within
the current window when the call to window.open is not possible.
However, If you start providing fall-back it becomes worth while to
check the object returned from the call to window.open to ensure that it
has not been influenced by browser settings, content
inserting/re-writing proxies or external pop-up blocking software.
Unfortunately a full battery of tests to cover all of those
possibilities has not yet been written (and is widely believed to be
impossible). Those tests might include:-
if((!win)||(win.closed){
// window has already been squashed by browser settings
// or an external pop-up blocker.
}else{
// window may yet be squashed by external pop-up blocker.
}
if(win == window){
// Proximatron default pop-up blocking filter or similar
// content inserting/re-writing proxy.
}
//and so on.
I also recommend against depending on new windows.
Absolutely.
Richard.
).