Dr.Tube wrote:[color=blue]
> Hi DU,
>
>[color=green]
>>What Neal said about js support disabled applies perfectly to your[/color]
>
> code.
>[color=green]
>>With javascript support disabled, the image pic.gif won't be viewed[/color]
>
> when
>[color=green]
>>it *should* be and it could be.[/color]
>
> Actually, the image DOES open when JS is disabled! Really, try it.[/color]
In the same window, yes, you're right. I was mostly thinking about a
secondary window, a requested popup; in which case,
target="SomeWindowName" is needed.
[color=blue]
> I've just tested it myself (on Mozilla) just to be 100% sure!
>
>[color=green]
>>Also, you do not follow none of the WAI Guidelines regarding[/color]
>
> requested
>[color=green]
>>popups (secondary windows) nor J. Nielsen's. No warning. No title
>>attribute. No cursor in the link. No indication whatsoever that[/color]
>
> clicking
>[color=green]
>>that icon-gif.gif will open a new separate window:[/color]
>
> I agree with you there. There should of course be a warning at the
> start of the page indicating that (all) links will open in a new
> window.
>[/color]
Well, just links that are going to open into a new window (assuming a
single left mouse click). The user can and should always be able to
right-click and open in a new window or in a new tab. Most of the time,
requested popup windows are (unintentionally maybe, but still) coded in
a way that prevents that. That's another problem with *coding* popups
and copy-N-paste javascript sites with poor code.
[color=blue]
>[color=green][color=darkred]
>>>function OpenImgXY(FileName,W,H,Title)
>>>{
>>> var Str="", Max=false;
>>> var X=0,Y=0,oW=0,oH=0;
>>> var aW=0,aH=0;xc=0,yc=0;
>>>[/color]
>>
>>You need 10 local variables and 1 global variable for your code
>>notwithstanding 4 parameters: I already doubt your code very much.[/color]
>
> So? Still, it does work! If we're opening a new window anyway, why not
> control it to the max?
>[/color]
If we're opening a new window, why not code it to the best possible way
respecting all that we can respect like:
- usability guidelines
- accessibility and sane fallback mechanisms
- user's system resources
- valid markup code
- best javascript coding practices
Half of your js variables are pretty much obsolete due to the coming of
SP2 btw which sanitizes positioning of requested popups.
"
if the feature is turned on for Windows Restrictions, this feature:
(...)
Constrains the size and positioning of script-initiated Internet
Explorer windows that have title and status bars to ensure that the
title bar and the status bar in these windows is always visible to the user.
Constrains script-initiated popup windows with no title or status bar or
other frame, so that they:
Do not extend above the top or below the bottom of the parent Web Object
Control (WebOC) window.
"
http://www.microsoft.com/technet/pro...on130121120120
I personally filed myself bugs on sanitizing positioning of requested
popups at bugzilla and they were fixed a few months ago.
Bug 176342: windows opened using innerHeight/Width can open partially
offscreen
http://bugzilla.mozilla.org/show_bug.cgi?id=176342
Bug 118717: Never let sites position windows outside the screen
http://bugzilla.mozilla.org/show_bug.cgi?id=118717
Bug 183633: screenX/left and screenY/top of popups are not corrected
accordingly when sizes are not specified
http://bugzilla.mozilla.org/show_bug.cgi?id=183633
Bug 174519: The window feature "titlebar=yes" will open a popup
maximized covering the window taskbar
http://bugzilla.mozilla.org/show_bug.cgi?id=174519
[color=blue]
>[color=green][color=darkred]
>>> if (window.screen) { // centre it on the screen...
>>> aW=screen.availWidth;
>>> aH=screen.availHeight;
>>> xc=(aW-W)/2;
>>> yc=(aH-H)/2;
>>> }
>>>
>>> if (W!=null) {
>>> if (W>0) { X=W }
>>> if (W>(aW-10) || W<0)[/color]
>>
>>Your code assumes that there is 10 pixels granted to window resizing
>>handles/borders. Already here, your calculations are wrong.[/color]
>
> I had to assume something... Like I said it isn't perfect, but it
> works OK most of the time.
>[/color]
You could have assume the standard default width value in Windows for
window borders and 10 was not the default width value.
[color=blue]
>[color=green]
>>{
>>[color=darkred]
>>> Max=true;
>>> oW=aW;
>>> W=aW-10;
>>> xc=0;
>>> }
>>> }
>>>
>>> if (H!=null) {
>>> if (H>0) { Y=H }
>>> if (H>(aH-30)[/color]
>>
>> From where comes this 30 value? The height of the titlebar is not[/color]
>
> 30
>[color=green]
>>pixels. In fact, the height of the titlebar of windows is entirely
>>configurable in Windows XP and will affect Opera 7 and MSIE 6 users.
>>Again, your calculations ignore all this.[/color]
>
> I know, but I don't how to get at these values without going into a
> lot of OS specific details...
>[/color]
The default height value for Windows Standard theme is available here:
Start/Settings/Control Panel/Display/Appearance tab/Advanced
button/Item: Active Title Bar/Size
[color=blue]
>[color=green][color=darkred]
>>> if (Max)
>>>[/color][/color]
>
> {Str="scrollbars=yes,resizable=yes,width="+W+",hei ght="+H+",outerWidth
>[color=green][color=darkred]
>>>="+oW+",outerHeight="+oH}
>>> else
>>>[/color][/color]
>
> {Str="scrollbars=no,status=no,menubar=no,width="+W +",height="+H+",inne
>[color=green][color=darkred]
>>>rWidth="+W+",innerHeight="+H}[/color]
>>
>>1- innerWidth and width (innerHeight and height) refer to the same[/color]
>
> value
>[color=green]
>>in NS 4, NS 6, NS 7 and Mozilla-based browsers.[/color]
>
> Yes but not in MSIE...
>[/color]
MSIE does not support innerWidth and innerHeight but support width and
height: so there is no need at all to refer to innerWidth and
innerHeight in your windowFeatures string list here. Just width and
height will cover NS 4, NS 6, NS 7, Mozilla-based browsers, MSIE 5+,
Opera 7.x, etc...
"Backwards compatibility:
* open(height,width) equates to the new open(innerHeight,innerWidth)
(...)
Note: innerHeight and innerWidth options replace the height and width
options,
but they remain for backwards compatibility."
JAVASCRIPT 1.2 NEW WINDOW METHODS AND PROPERTIES
http://developer.netscape.com/docs/t...dow/index.html
[color=blue]
>[color=green]
>>2- Since the windowFeatures string list will not be empty, then[/color]
>
> there is
>[color=green]
>>no need to define those with a no value.[/color]
>
> It shouldn't be necessary, but I've seen this gone wrong in at least
> one browser (I can't remember which one though, maybe an old Opera...)
>[/color]
I'm convinced there is no need for the windowFeatures with a "no" value.
[color=blue]
>[color=green]
>>3- You are willing to take a chance on the window dimensions fitting[/color]
>
> the
>[color=green]
>>embedded picture up to a point of disabling scrollbars if needed, if
>>content overflows your requested window dimensions. From an
>>accessibility issue and usability issue, what you do is illogical[/color]
>
> and
>[color=green]
>>not recommendable. As a normal accessibility fallback, every single
>>requested popup window opened via window.open() should have
>>scrollbars=yes. If you're sure about your inner and outer values,[/color]
>
> then
>[color=green]
>>why would you want to remove scrollbars just in case and exactly[/color]
>
> when
>[color=green]
>>your calculations do not work as expected, are wrong.[/color]
>
> Yeah but a 200x200 pixel photograph of some product in a window
> without scrollbars looks so much better than in a window with
> scrollbars.[/color]
You don't understand. If scrollbars are needed, your code and your logic
demands to remove them.
In your else block, you remove both the scrollbars if they are needed
and you remove implicitly the window resizability! So you don't help the
user accessing your content; I'm not referring to cosmetics. If your
sizes are correct, scrollbars won't appear and resizing of the window
won't be needed...but you should always code and consider fallback
mechanisms. You don't know what the user might have: special assistive
technology, user defined stylesheet with !important css declarations,
rules, MS-magnify ON which reduces the height of windows' application
workarea, etc..
Just in case I keep the window resizable.[color=blue]
>[/color]
No you don't in your else block. You implicitly remove window resizability.
Your code:
else
{Str="scrollbars=no,status=no,menubar=no,width="+W +",height="+H+",inne
rWidth="+W+",innerHeight="+H}
[color=blue]
>[color=green]
>>4- You're willing to assume your code will work and that you'll[/color]
>
> remove
>[color=green]
>>status bar in both cases; this is one other area where your code[/color]
>
> fails.
>[color=green]
>>Right now, you have to assume that 90% of all users out there[/color]
>
> (because
>[color=green]
>>XP SP2 users will soon join Mozilla-based users and Opera 7.x users)[/color]
>
> can
>[color=green]
>>force the presence of a status bar on all secondary window... but[/color]
>
> your
>[color=green]
>>code assume you'll be able to remove that. So, your calculations get
>>wrong 90% of the time.[/color]
>
> Mmmmh, point taken and noted!
>
>[color=green]
>>5- Notwithstanding the fact that Mozilla-based users and Opera 7.x[/color]
>
> users
>[color=green]
>>can force the presence of scrollbars if needed (if content overflows
>>requested dimensions), menubar, statusbar and personalbar that your[/color]
>
> code
>[color=green]
>>explicitly or implicitly tries to remove.[/color]
>
> Point taken and noted.
>
>[color=green][color=darkred]
>>> myWin=window.open("",'_blank',Str);[/color]
>>
>>myWin was not properly declared before: that's another thing with js
>>function code being robust and working as efficiently as possible:[/color]
>
> scope
>[color=green]
>>appropriately all variables.[/color]
>
> That's an oops...
>
>[color=green]
>>You're creating a whole html document from a blank one.
>>1- Not what the original poster requested.[/color]
>
> OP wanted "Opening image in new window without padding". That's what
> this JS does...
>
>[color=green]
>>2- You're going to dynamically populate it with appending string
>>involving 7 document.write[ln] commands when at most 3 would have[/color]
>
> been
>[color=green]
>>sufficient. (document.write[ln] is not the most efficient too)
>>I hope you see the considerable amount of time, cpu, RAM all this[/color]
>
> will
>[color=green]
>>involve....[/color]
>
> I agree that this isn't the most "efficient" way of doing this, but my
> time is limited as well. CPU time is cheap. I wanted to keep the UA
> specifics to minimum. But I agree this code can be "optimized".
>[/color]
window.open() calls involves more and more lines of long branching code
these days as popup coding has become the strategical target of browser
manufacturers in the last 2 years: SP2 is another demonstration and
certainty that the browser code regarding window.open() and secondary
windows has now grown bigger. More complex, more user settings involves.
For instance, Mozilla code regarding window.open() exceeds 5,000 lines,
notwithstanding all the code related to tabs, as one can open a link
(with an onclick handler) in a new tab.
[color=blue]
>[color=green][color=darkred]
>>> if (myWin) {[/color]
>>
>>myWin could exist (typeof object) and the window being referenced by[/color]
>
> it
>[color=green]
>>could be closed: your code makes no difference, no distinction at[/color]
>
> all
>[color=green]
>>here, just doesn't care about it. So, if the window is behind the
>>opener, the window will be recreated and dynamically repopulated all
>>over again. What a waste of the user's system resources.[/color]
>
> So exactly how much user resources are "wasted" here? Opening a new
> instance of IE has a minor impact on system resources...
>[/color]
I don't agree. It takes time, cpu, RAM, memory management code, etc.
Some sites with many thumbnails are slow because it takes time/cpu/RAM
to close and delete secondary windows and do necessary memory management
stuff and then create new ones from scratch for enlarged images.
[color=blue]
>
> myWin.document.writeln("<HTML><HEAD><TITLE>"+Title +"</TITLE></HEAD>");
>[color=green][color=darkred]
>>> myWin.document.writeln("<BODY BGColor=#FFFFFF LeftMargin=0
>>>TopMargin=0 MarginWidth=0 MarginHeight=0>");[/color]
>>
>>Invalid code here. These *Margin attributes are non-standard markup.[/color]
>
> I know. But there is no DocType here either, so all browsers go into
> quircks mode anyway. A CSS based solution would be better though.
>
>[color=green][color=darkred]
>>> myWin.document.write("<IMG Src="+FileName);
>>> if (X!=0) { myWin.document.write(" Width="+X) }
>>> if (Y!=0) { myWin.document.write(" Height="+Y) }
>>> myWin.document.writeln(">");
>>> myWin.document.writeln("</BODY></HTML>");[/color]
>>
>>No escape of the forward slashes: the W3C HTML validator will[/color]
>
> complaint
>[color=green]
>>and report these.[/color]
>
> I have this JS in a separate file. Should the slashes still be
> "escaped" there?
>[/color]
If it is in a separate file, then you're ok. But in an usenet newsgroup,
you can assume people won't know that and will paste your code into
their webpage.
No need to escape the forward slashes for an external file. But this is
minor issue compare to the recourse to document.write[ln] and the number
of times being called. Appending strings is cpu demanding.
I personally always stay from document.write() calls and use exclusively
DOM methods.
[color=blue]
>[color=green]
>>If the popup goes behind the opener, then the user clicking again[/color]
>
> the
>[color=green]
>>link will NOT bring up back on top the popup and will be confused[/color]
>
> since
>[color=green]
>>the window is not brought back. So, the user will keep on clicking[/color]
>
> the
>[color=green]
>>link not understanding what is happening. This happens often, has[/color]
>
> been
>[color=green]
>>well documented and is known to be the nr 1 usability problem with
>>popup: the js code you have here does not compensate for an inherent
>>flaw in the windowing system of known operating system.[/color]
>
> So where is this documented? I'm obviously unaware of this problem.
>[/color]
You may start here: many quotes, urls are there:
Popup windows and Netscape 7
http://www10.brinkster.com/doctorunc...nLinkNewWindow
[color=blue]
>[color=green]
>>Also, what if the user now clicks another thumbnail link? What if[/color]
>
> the
>[color=green]
>>user expects your code to recycle and reuse that first window? How[/color]
>
> does
>[color=green]
>>your code react to all this? Creating new windows on the user's[/color]
>
> system
>[color=green]
>>requires a lot of system resources. Now, if you're willing to do[/color]
>
> that,
>[color=green]
>>then the nice thing would be to make the best out of this usage, to[/color]
>
> make
>[color=green]
>>such window reusable, recycle in and for a page where there are many
>>clickable thumbnails. Your code does not do that, does not take that
>>under consideration.[/color]
>
> I deliberately do not recycle a popup window as my users will probably
> want to compare the images in the newly opened windows.[/color]
You can still code in a way that will give such flexibility and freedom
to the users.
You deliberately do not recycle a popup window; I deliberately code
links like that so that I can propose to my users such recycling
scenario without constraining them, without limiting their choice,
without limiting their freedom as to how (new window, new tab,
background or not, new unnamed window) they want to see the referenced
resource of such link. That's coding for flexibility and accessibility.
As long as your link does not interfere with right-click context-menu
commands (open in a tab, open in a new window, open in background tab or
window), then you can still do this: it's even a site, webpage feature
in fact. In K-meleon 0.8.2, I can open links of my page in 5 different
ways if I want to while still being able to recycle the only target window.
DU
[color=blue]
> I appreciate your comments. I agree with some of your points, and
> obviously my JS code here can be much improved.
>
> Regards Xavier.
>[/color]
