reptile7's JavaScript blog
Thursday, July 31, 2008
Tales from Topographic Images, Side 1
Blog Entry #121

"Basic HTML: Images", the fifth of Joe Burns' original HTML primers, contains a section that discusses the "activation" of an image, i.e., turning an img element into a hyperlink by wrapping it in an anchor element:

<a href=""><img src="homepage.gif" alt="Home"></a>

Image maps, our 'topic du jour' for the next few posts, are an extension of this basic concept. Instead of associating a link with an entire image (as the above code does), an image map defines subregions of an image and associates linking and/or other actions with those subregions.

Anatomy of an image map

An image map comprises a parent map element containing a series of area element or anchor element descendants.

The HTML map element has one #REQUIRED attribute, a name attribute that links the map to its image via the image's usemap attribute, as follows:

<img src="myImage.gif" alt="Alternate text" usemap="#myMap">
<map name="myMap"> ... </map>

More formally, for an img element and a map element to be coassociated, the img usemap and map name "fragment identifiers" (in the code above, myMap) must match. The usemap attribute value is actually a URL, and the map element is in effect the 'destination anchor' of that URL; when the browser hits the img usemap attribute, it will jump forwards or backwards to the map and then apply the map to the image. The img/map element order in the document source is thus unimportant, in much the same way that an <a name="myAnchor"> anchor can follow or precede an <a href="#myAnchor"> link.

Section 4.10 of the XHTML 1.0 Specification notes that XHTML 1.0 deprecates the name attribute of the map element, and that a corresponding id attribute should instead be used to link a map element to its associated img element.

According to its content model, the map element, which is itself an inline element, can have one or more block-level elements or area elements as immediate children:

<!ELEMENT MAP - - ((%block;) | AREA)+ -- client-side image map -->

<!-- Regarding the map element content models in the XHTML DTDs (see here, e.g.), %block;, form, and %misc; add up to the same collection of elements that constitutes the %block; set of elements in the HTML DTDs. -->

This is why I used the word "descendants" earlier: in a valid document, a map element cannot have anchor element children. Look over the W3C's client-side image map examples - note that the anchor elements that define image subregions are all wrapped in p elements.

The area element and the anchor element share three key attributes that relate to the use of these elements in image maps:
(1) shape
(2) coords
(3) href
(Relatedly, you may know that classical JavaScript featured a client-side area object that was a type of link object.)

You know all about href; we'll flesh out shape and coords when we analyze an actual image map later.

Like the img element, the area element
(a) is a 'contentless' empty element, and thus its end-tag is "forbidden" in HTML, and
(b) has a #REQUIRED alt attribute for specifying alternate text, which evidently comes into play for non-visual browsers; at least on my computer, it's the img alt text, and not the area alt text, that is rendered if an image-map image is not available.

An example...

It's time we moved from theory to practice, wouldn't you say? Accordingly, let's turn now to HTML Goodies' "So You Want A Client-Side Image Map, Huh?" tutorial, which associates a monk.gif image

An image of a monk

with the following map element:

<!-- This code and the image code in the next section have been taken from the tutorial source, not from the tutorial itself. -->
<map name="monkmap">
<area shape="rect" coords="91,30 186,98" href="" alt="NFL Home Page">
<area shape="circle" coords="25,72 28,97" href="" alt="CNN Home Page">
<area shape="circle" coords="107,158 132,162" href="" alt="CBS Home Page">
<area shape="poly" coords="9,115 86,79 98,116 69,131 86,175 48,206" href="" alt="USA TODAY Home Page">

<area shape="default" href="index.html">

The preceding code was not written 'from scratch' but was derived from an image map that Joe created with the Mapedit (not "MapEdit") image map editor program. Program? In order to make a map, you need to go and get a map-making program. There's no way around it, Joe contends in the tutorial's "Let's Make A Map!" section. Maybe you'd need a specialized program for a complex image map, but for the simple map above, such a program is definitely not necessary - I'll show you how to define image subregions via crosshairs and mouse clicks in a subsequent post.

Regarding the "Let's Make A Map!" section's links, I should note before moving on that:
(1) The link to the Mac-ImageMap (not "Mac-Image-Map") program for the Macintosh is dead; however, I'm delighted to report that Mapedit now has a Mac version (but we still won't be using it).
(2) The If these don't suit you, click Here to search [for] others link is also broken; however, the "Making the Map" section of HTML Goodies' related "So, You Want An Image Map, Huh?" tutorial provides the correct URL for this link, which is:

The image code

Before we get into the monkmap map element, let's take a look at Joe's code for the monk.gif image:

<a href="/legacy/tutorials/image_maps/">
<img src="/images/monk.gif" height="255" width="262" ismap usemap="#monkmap">

Upon reading the W3C's subsection on server-side image maps, it is clear that the preceding code originates from Joe's discussion of server-side image maps in the aforecited "So, You Want An Image Map, Huh?" tutorial.
• According to the W3C, for a server-side image map, the img element must have an anchor element parent with a href attribute that specifies the server destination to which the coordinates of the user's mouse clicks on the image will be sent.
• The W3C doesn't have much to say about the img element's Boolean ismap attribute other than that it must be set for an image associated with a server-side image map.

But we're (well, at least I'm) not interested in a server-side map - we want a map that can be rendered directly by the user's browser without having to horse around with a server. And for a client-side image map, the above anchor element wrapper* and img ismap attribute are excess baggage that should be thrown out.
(* is not a map file anyway - check its source.)

The monkmap map

Joe makes no effort to explain the monkmap map: he simply unloads the area shape and coords data on the reader and states, The map program will tell you [what] all this [means]. It thus falls to us to carry out a detailed dissection of the monkmap map - this could take a while, so let's leave it for the next post.


Wednesday, July 23, 2008
Viewport Flux, Part 3
Blog Entry #120

Lagniappe: Using links to open new windows

In the "Minimize/Maximize a Browser Window" tutorial, Joe codes the hyperlink to the tutorial's demo page as:

<a href="/legacy/beyond/javascript/bigsmall.html" target="new window">Click me</a>

The above link opens the demo page in a new browser window; this reminded me that HTML Goodies' Getting Started Tutorial sector sports a "So, You Want A New Browser Window, Huh?" tutorial that offers the following code for using links to open new windows:

<a href="" target="resource window">Text Text Text</a>

How 'bout them target attribute values, huh? new window? resource window? Seem suspicious, don't they? To be sure, they're not standard, but - at least with respect to HTML - they're not invalid, either.

Shared by the anchor, area, base, form, and link elements, the target attribute is detailed in the Transitional Document Type Definitions (DTDs) of HTML and XHTML but is not deprecated. The target attribute's data type designation is %FrameTarget;, an entity reference whose replacement text is "CDATA" in the HTML 4.01 Transitional DTD but is "NMTOKEN" in the XHTML 1.0 Transitional DTD.

CDATA is defined in Section 6.2 ("SGML basic types") of the HTML 4.01 Specification. A CDATA string can contain any Unicode characters, including white space characters, and also character references (e.g., &pound; for £); however, before you add a target="@#$%" attribute to your Web page, I draw your attention to Section 6.16 ("Frame target names") at the bottom of the page, which states, [F]rame target names (%FrameTarget; in the DTD) must begin with an alphabetic character (a-zA-Z). User agents should ignore all other target names. (So as to why the target attribute has a CDATA data type and not a NAME data type, well, you'll have to ask Dave Raggett about that.)

• For a definition of NMTOKEN, Section C.8 ("Fragment Identifiers") of the XHTML 1.0 Specification directs the reader to the Name and NameChar productions in the XML 1.0 Specification

Name ::= (Letter | '_' | ':') (NameChar)*
NameChar ::= Letter | Digit | '.' | '-' | '_' | ':' | CombiningChar | Extender

according to which a NMTOKEN string must begin with an alphabetic character, an underscore, or a colon, followed by zero or more NameChar characters (letters, digits, periods, hyphens, etc.). NameChar characters do not include white space characters, and thus the new window and resource window target values are actually invalid from an X(HT)ML standpoint.

The aforecited "Frame target names" section specifies that the reserved target value _blank

<a href="fileURI" target="_blank">Link text</a>

can be used to open a link in a new window. But why do the new window and resource window target values open links in new windows? Our situation is addressed by the W3C in Section 16.3.2 ("Target semantics") of the HTML 4.01 Specification:
4. If any target attribute refers to an unknown frame F, the user agent should create a new window and frame, assign the name F to the frame, and load the resource designated by the element in the new frame.
It follows that there's nothing special about the new window and resource window target values - we could set a link's target attribute to Bond_007 (but not 007_Bond) and the link will open in a new window as long as there isn't another window named Bond_007 open on the screen.
FYI: If an empty string is assigned to the target attribute (target=""), then the link's href file will not be loaded into a new window but into the current window.

Interestingly, Mozilla pooh-poohs the use of target="_blank", arguing that
(a) it's inefficient, more specifically, a given target value should be reusable by other links in the document, which is not the case for the _blank value, and
(b) it's semantically unsatisfying: target="demoWindow" would be a better choice for a demo page link, for example.
(For that matter, Mozilla argues against loading files into new windows more generally.)
But I'm sure Mozilla would agree that there's nothing terribly wrong with target="_blank" if you only use it once or twice in your document.

The next Beyond HTML : JavaScript tutorial is "No Dotted Line On Links", which is concerned with getting rid of the "selection rectangles" that surround active hyperlinks (active as in the CSS :active dynamic pseudo-class):

A 'Click Here' link surrounded by a selection rectangle

I think we can skip a discussion of this, uh, crucial issue, but one sentence in the tutorial did grab my attention: [A selection rectangle] makes image maps look cruddy. This reminded me that HTML Goodies has an Image Maps Tutorial sector, a part of the site I had previously not worked through. I then read the sector's "So You Want A Client-Side Image Map, Huh?" tutorial, which presents image map code that in some respects is seriously out of sync with the W3C's image map documentation and which, given that image maps would be an entirely new topic for us, we'll check over in the next post.


Wednesday, July 16, 2008
Viewport Flux, Part 2
Blog Entry #119

We return now to our discussion of HTML Goodies' "Minimize/Maximize a Browser Window" tutorial. In this entry:
(1) We'll address the tutorial script's (in)compatibility with Internet Explorer with respect to the script's original property-based design.
(2) Subsequently, I'll give you a cross-browser script and demo based on window object methods for maximizing/minimizing browser windows.

Window dimensions

The MSDN Library's window object page doesn't list any width/height-type properties associated with the window object*: no width/height, innerWidth/innerHeight, or outerWidth/outerHeight.
(*This isn't quite true: Microsoft's window object does have dialogWidth and dialogHeight properties that apply to "dialog" windows created by the showModalDialog( ) and showModelessDialog( ) methods, but this is a can of worms we're not going to open.)

Microsoft introduced with MSIE 4 clientWidth and clientHeight properties that are applicable to the body element/object; respectively, the expressions document.body.clientWidth and document.body.clientHeight are approximately equivalent (they don't take scrollbars into account) to Mozilla's window.innerWidth and window.innerHeight. However, clientWidth and clientHeight are read-only properties; I can confirm that MSIE throws "Object doesn't support this property or method" runtime errors upon attempts to write them. And now that I think about it, even if clientWidth/clientHeight were writable, there's no reason to expect that changing the size of the body element would change the size of the window that contains it.

With respect to maximizing a window, and pushing a minimized window off-screen, MSIE does at least support a screen object with width and height properties that are equivalent to their Mozilla counterparts.

Window positioning

Microsoft offers screenX and screenY properties for the event object (as does Mozilla) but not for the window object. Instead, MSIE supports screenLeft and screenTop properties that correspond, but are not equivalent, to Mozilla's screenX and screenY window object properties; screenLeft measures the horizontal distance between the left edge of the monitor screen and the left edge of a browser window's document content area (unlike the screenX length, the screenLeft length includes the left part of the browser chrome), whereas screenTop measures the vertical distance between the top edge of the screen and the top edge of a window's document content area (unlike the screenY length, the screenTop length includes the top part of the browser chrome).

The preceding MSDN links say that screenLeft/screenTop are also read-only, although I don't know for certain what happens if you try to write them because they are not supported by MSIE 5 for the Macintosh; as noted here in Blog Entry #18, window.screenLeft and window.screenTop both return undefined with MSIE 5.1.6 on my iMac.

A method-based approach

So for getting the script to work with MSIE, things aren't looking so good on the window object properties front. But hold on a minute: the second paragraph of the tutorial's "Here's What's Happening" section begins, There are other methods of getting the same resize effect, but the first time I saw this done, the author used the innerWidth and innerHeight commands, so I kept it that way. Ka-ching! Methods? Speak up, Dr. Burns, what methods might those be? Come, gentle reader, let me tell you about them...

For setting a window's dimensions:

(1) Both Microsoft and Mozilla offer a resizeTo( ) method

window.resizeTo(iWidth, iHeight);

that resizes the current window to a width** of iWidth pixels and a height** of iHeight pixels, subject to browser constraints: specifically, the resizeTo( ) method will not generate a smaller-than-the-minimum or larger-than-the-maximum window allowed by a browser.

**The precise meanings of width and height in this context are browser-dependent. We noted in the previous entry that Netscape 7.02 and Netscape 4.79 interpret the outerWidth and outerHeight properties differently; I find that both MSIE 5.1.6 and Netscape 7.02 use the resizeTo( ) iWidth/iHeight values to set a window's outerWidth/outerHeight lengths as Netscape 7.02 interprets them, i.e., the left border, right border, title bar, and bottom border parts of the browser chrome are excluded. In contrast, Netscape 4.79 uses the iWidth/iHeight values to set a window's innerWidth/innerHeight lengths (ironically, Netscape's original resizeTo( ) documentation specifies that the iWidth/iHeight values should set a window's outerWidth/outerHeight lengths as Netscape 4.x interprets them, i.e., all parts of the browser chrome should be included).

(2) Microsoft and Mozilla also provide a related resizeBy( ) method that resizes a window vis-à-vis its current size.

For positioning a window:

(1) Both Microsoft and Mozilla offer a moveTo( ) method

window.moveTo(x, y);

that offsets the left edge of a window x pixels from the left edge of the monitor screen and the top edge of a window y pixels from the top edge of the screen, again subject to browser constraints: specifically, a window cannot be pushed completely off-screen via the moveTo( ) method.

(2) Microsoft and Mozilla also provide a related moveBy( ) method that offsets a window vis-à-vis its current position.

The browsers on my computer generate differently sized maximum windows and differently sized minimum windows, and they behave differently in response to attempts to push a window off-screen, and thus the code I offer below does not give identical results with these browsers but it works well enough for my tastes (it'll be up to you to tweak it if the results are not to your tastes).

Maximizing a window

Let's pick the low-hanging fruit first; maximizing a window is definitely more straightforward than minimizing a window. I find that

window.resizeTo(screen.width - 13, screen.height - 49);
window.moveTo(0, 0);

gives a nicely maximized and entirely on-screen window when using either MSIE 5.1.6, Netscape 7.02, or Netscape 4.79. Of these browsers, Netscape 7.02 gives the largest maximum window; the -13/-49 screen.width/screen.height adjustments are the minimum needed to get the Netscape 7.02 window completely on-screen.

Minimizing a window

Let's begin by harmonizing the hyperlink font/position across (modern) browsers with the following style rule set:

body { font-size: 16px; font-family: Arial, sans-serif; margin-left: 10px; margin-top: 8px; }

After quite a bit of experimentation, I find that

window.resizeTo(152, 154);
window.moveTo(screen.width - 158, screen.height - 170);

gives an acceptable minimized window with both MSIE 5.1.6 and Netscape 7.02.

Of the browsers on my computer, Netscape 7.02 gives the smallest minimum window, measuring outerWidth=100px by outerHeight=100px or precisely 113px by 129px if all of the browser chrome is included. With Netscape 7.02, if all of the top chrome bars are visible, the preceding code generates a window with a 152px-by-34px on-screen document content area in which the "Maximize" hyperlink does not wrap:

Netscape 7.02's minimized window

MSIE 5.1.6 gives a considerably larger minimum window, measuring precisely 329px by 229px if all of the browser chrome is included; on the other hand, unlike Netscape, MSIE allows its windows to be pushed almost completely off-screen with the moveTo( ) method. With MSIE 5.1.6, if all of the top chrome bars are visible, the preceding code generates a window with a 152px-by-35px on-screen document content area:

MSIE 5.1.6's minimized window

Netscape 4.79's minimum window measures innerWidth=100px by innerHeight=100px or precisely 113px by 239px if all of the browser chrome is included. The Netscape 7.02/MSIE 5.1.6 code can be used with Netscape 4.79, but you'll get a smaller window if you use the following code that mirrors the corresponding commands in the original script:

window.resizeTo(100, 100);
window.moveTo(screen.width, screen.height);

Here's the Netscape 4.79 minimized window - its document content area and right chrome are entirely on-screen but its bottom chrome is mostly off-screen:

Netscape 4.79's minimized window

The "Maximize" hyperlink wraps, as it does in Joe's original demo.

Follow this link to try out my code (I've slightly modified it so as to accommodate the OS X browsers on my current computer) on your system - a demo page will open in a new 400px-by-400px window.

Before ending this section, I should mention that the innerWidth, innerHeight, outerWidth, outerHeight, clientWidth, clientHeight, screenX, and screenY properties are all on track for W3C adoption, but only in a read-only sense. It is to be hoped that the W3C will in the future decide that the normal CSS width and height properties should apply to browser windows in a read/write sense, and that Microsoft, Mozilla, and other vendors will update their browsers accordingly.

We'll wrap up our analysis of the "Minimize/Maximize a Browser Window" tutorial with a brief follow-up post in which we'll discuss the use of hyperlinks to open new browser windows.


Friday, July 04, 2008
Viewport Flux
Blog Entry #118

Many moons ago, way back in Blog Entry #18, we briefly discussed the use of the Netscape-specific innerWidth and innerHeight properties of the window object to set the dimensions of a browser window and also the use of the Netscape-specific screenX and screenY properties of the window object to position a browser window relative to the monitor screen. We return to these properties in today's post as we take up HTML Goodies' "Minimize/Maximize a Browser Window" tutorial, which presents a script containing
(a) a Maximize( ) function that 'maximizes' a browser window, i.e., blows it up so that it covers the entire screen, and
(b) a Minimize( ) function that 'minimizes' a browser window, more specifically, shrinks it to a 100px-by-100px smaller window; Netscape notes here that the Navigator browser's windows have an enforced minimum size of 100 x 100 pixels.
The Maximize( ) function thus effectively mimics the maximize button of the Windows interface:

Components of the Windows interface

However, per the above description, the Minimize( ) function does not convert a browser window to a button on the task bar.
(A picture is worth a thousand words, eh? The Windows components image came from Figure 2.14 on this page (sorry for providing a link to a cached resource, but the original file is at press time strangely unavailable) created by Professor Charles Ward at the University of North Carolina Wilmington.)

Here's the "Minimize/Maximize a Browser Window" script:

<script type="text/javascript">

function Minimize( )
window.innerWidth = 100;
window.innerHeight = 100;
window.screenX = screen.width;
window.screenY = screen.height;
alwaysLowered = true;

function Maximize( )
window.innerWidth = screen.width;
window.innerHeight = screen.height;
window.screenX = 0;
window.screenY = 0;
alwaysLowered = false;

<a href="javascript:onclick=Minimize( );">Minimize</a>
<a href="javascript:onclick=Maximize( );">Maximize</a>

The tutorial provides a script demo page here.


The Minimize( ) and Maximize( ) functions are called by JavaScript URLs assigned to the href attributes of the "Minimize" and "Maximize" hyperlinks. The "onclick=" part of these URLs can be removed:

href="javascript:Minimize( );" <!-- and --> href="javascript:Maximize( );"

is all that's necessary.

Mozilla's DOM window Reference will tell you that the innerWidth property and the innerHeight property are read-only, but the now-"obsolete"-but-still-essential JavaScript 1.3 Client-Side Reference will tell you that they are writable; in practice on my computer, I find that Netscape 7.02 does indeed write them. The Minimize( ) function sets both innerWidth and innerHeight to 100 (pixels), the minimum value as noted earlier. Conversely, the Maximize( ) function sets innerWidth to screen.width and innerHeight to screen.height.

The client-side screen object, which represents the monitor screen, does not appear in the 'classical JavaScript' Navigator object hierarchy but is now listed as a property (child object) of the window object on Mozilla's DOM window Reference page (this might seem counterintuitive - you might think that the screen object would be at least a peer or even the parent of the window object - however, there's no reason why a browser window can't be larger than the monitor screen, and recall from CSS 2.1 that a browser window ("viewport") frames a document "canvas" whose dimensions are "infinite"); you won't find anything on the screen object in any of the W3C's DOM materials. Mozilla's definitions of screen.width and screen.height could be fleshed out a bit more; although it's true that, respectively, these properties return the width and height in pixels of the monitor screen, it would be more accurate to say that they return the horizontal and vertical resolutions in pixels of the screen: the values of these properties will change if you change the resolution of your monitor (e.g., from 800 x 600 to 1024 x 768).

Above and beyond the document content area, the innerWidth width and the innerHeight height respectively include (if present) the right and bottom scrollbars but they exclude the rest of the 'browser chrome': specifically for Netscape 7.02, innerWidth does not include the window's left and right borders or sidebar whereas innerHeight does not include the window's title bar, navigation toolbar, personal toolbar, tab bar, status and component bars, or bottom border. In practice, I find that assigning screen.width to window.innerWidth and screen.height to window.innerHeight gives an enlarged window whose
(a) right border has been pushed beyond the right edge of the screen (as expected),
(b) left border/sidebar are still on-screen and abut the left edge of the screen (in theory, these components should be pushed just beyond the left edge of the screen),
(c) bottom border and status/component bars have been pushed beyond the bottom edge of the screen (as expected), and
(d) upper browser chrome is still on-screen and abuts the top edge of the screen (in theory, these components should be pushed just beyond the top edge of the screen).

The window object has outerWidth and outerHeight properties whose values are supposed to include the browser chrome parts excluded by the innerWidth/innerHeight properties, but at least with Netscape 7.02 on my computer, assigning screen.width to window.outerWidth and screen.height to window.outerHeight gives a window identical to that described above - the right and bottom parts of the browser chrome are again pushed off-screen.

A careful counting of window pixels with the DigitalColor Meter utility revealed that, in fact, outerWidth was not including the window's left and right borders (together constituting 13 pixels of unrecognized horizontal chrome) and outerHeight was not including the window's title bar and bottom border (together constituting about 30 pixels of unrecognized vertical chrome).* In addition, a probe of my system's screen.availHeight return - the amount of vertical space available to the window on the screen - revealed that an 800px-by-20px region at the bottom of my screen is unavailable for display (with my monitor's resolution set to 800 x 600, screen.height returns 600 and screen.availHeight returns 580, whereas screen.width and screen.availWidth both return 800). To get the entire maximized window on-screen, then, we'll need to assign slightly smaller lengths to the window width and height; it follows from the preceding discussion that

window.outerWidth = screen.width - 13;
window.outerHeight = screen.height - 50;

will reliably do the trick when using Netscape 7.02.

*I repeated this exercise with an earlier version of Netscape, specifically, Netscape 4.79 (the tutorial script was evidently designed for Netscape 4.x given that the tutorial was written in July 2000, a few months prior to Netscape 6.0's release); with this browser, I found that outerWidth and outerHeight pick up every pixel of chrome (as they are supposed to). You would thus expect

window.outerWidth = screen.availWidth;
window.outerHeight = screen.availHeight;

to get all of the maximized window on-screen, and they do, with 8 pixels of horizontal space and 8 pixels of vertical space to spare.

(Something else I learned: both Netscape 7.02 and Netscape 4.79 impose a limit on how large of a window they will generate; for an 800 x 600 screen, regardless of the values assigned to innerWidth and innerHeight, Netscape 7.02 gives a maximum window whose document content area measures a full 800px by 600px whereas Netscape 4.79 gives a maximum window whose document content area measures 792px by 572px.)

There's more to maximizing a window than getting its dimensions right; we must also line up the window/screen x-y coordinate systems. Accordingly, the Maximize( ) function equalizes the window/screen 'origins' (i.e., their upper-left-hand corners) by assigning 0 to both window.screenX and window.screenY. The preceding Mozilla links imply that screenX and screenY are read-only properties; for its part, the JavaScript 1.3 Client-Side Reference alleges, Setting the values of the screenX and screenY properties requires the UniversalBrowserWrite privilege. In the event, I find that both Netscape 7.02 and Netscape 4.79 write these properties uneventfully without doing anything special on my part.

The Minimize( ) function sets window.screenX and window.screenY to screen.width and screen.height, respectively; in theory, these assignments should push a window completely off-screen - the window's upper-left-hand corner should coincide with the screen's lower-right-hand corner - the whole point of minimizing a window, after all, is to get it out of the way. In practice, however, the minimized window is still on-screen and approximately abuts the screen's lower-right-hand corner - depending on the version of Netscape you're using, the window's right and bottom chrome, plus a small amount of adjoining document content area, may or may not be pushed off-screen. (As noted earlier, the Minimize( ) function does not convert a window to a task bar button, and perhaps the script's author thought that this was 'the next best thing'.) Netscape notes here that a [Navigator] window won't move past the screen boundaries if you don't have the UniversalBrowserWrite privilege, which I guess is really necessary this time.

Lastly and leastly, the Minimize( ) and Maximize( ) functions respectively assign true and false to "alwaysLowered". Contra the tutorial, alwaysLowered has absolutely nothing to do with lower[ing] and mov[ing] the [minimized] window to the bottom right of the screen - it isn't even a normal property of the window object. Actually, alwaysLowered is an optional feature for a )-opened window; Netscape defines it here: If yes, creates a new window that floats below other windows, whether it is active or not. This is a secure feature and must be set in signed scripts - in other words, "alwaysLowered=yes" generates a persistently 'popped-under' window. Even if the alwaysLowered statements were deployed correctly, and assuming that another window is open on the screen, are we interested in hiding the minimized window and its "Maximize" hyperlink? Not at all. The alwaysLowered code can and should be thrown out.

In sum, the "Minimize/Maximize a Browser Window" script works reasonably well with Netscape given that, at least on the basis of Mozilla's materials, the innerWidth/innerHeight and screenX/screenY properties would not be expected to be writable. Next question: can the script be modified so that it works with MSIE? Tune in to the next post to find out!


Powered by Blogger

Actually, reptile7's JavaScript blog is powered by Café La Llave. ;-)