reptile7's JavaScript blog
Wednesday, September 29, 2010
 
Approaching Iridescence
Blog Entry #192

We continue today our discussion of HTML Goodies' "So, You Want A Background JavaScript, Huh?" tutorial and its document.bgColor-manipulating script. In the previous entry, I noted, [A]t earlier editions of the tutorial ... the script does not work as advertised on my computer - let me flesh this out a bit.

The tutorial's 'blurb' on the Beyond HTML : JavaScript portal page reads Produce a burst of color before your page loads and alter the colors that display!, which suggests that the "Background JavaScript" script should be placed in the document head. Just before the tutorial's "Changing Colors" section, Joe more specifically recommends, Paste the script right under your <HTML> command, before the title commands. In this position it will run before putting up any text. Then write the rest of your page as you would any other. However, on my system - my Intel iMac plus the hard disk rescued from my defunct G3 iMac - all of the OS X browsers and a majority of the Classic Mac browsers balk at executing a document.bgColor command if its trigger - the command itself as top-level code, or a call to a function containing the command - appears in the document head.

Upon placing the script's bgChanger( ) calls in the document body (the bgChanger( ) function itself can be left in the document head), a much more serious problem becomes apparent. All of my system's browsers smoke through the script's bgChanger( ) runs at a rate that precludes seeing any color changes - all I see is the final white ("FFFFFF") background color - with one exception: executing the script with MSIE 4.5 (in the SheepShaver environment) gives the desired effect, an effect whose document.bgColor change occurs much faster than that of the black-to-red demo I gave you last time, I might add.

Did Joe actually try the script with Netscape way back when? I can confirm that neither Netscape 3.04, Netscape 4.61, Netscape 6.2.3, nor Netscape 7.02 acts on the script as MSIE 4.5 does, although the tutorial makes no mention of browser-specificity. But anyway, now that I know how this thing is supposed to work, let me give you a new-and-improved demo. In the div below, click the button:

Ta-da!

 
Clearly, it is necessary to somehow slow the script down in order to see its color changes. In this regard, the script's key feature - the while loop that increments red, grn, and blu - is also its Achilles heel: loops are not meant to be slowed down but rather to execute an iterative block of code as quickly as possible. The present situation is reminiscent of the assignment for HTML Goodies' JavaScript Primers #24, which attempts to use for loops to delay the execution of document.bgColor commands and is plagued by the same only-the-final-color-is-visible problem. Alternatively, we can recast the loop as a recursive function and then control the rate of recursion via the setTimeout( ) method of the window object - a technique we are well versed in at this point and that underpins the above demo. Here is an outline of the changes that the demo makes to the original backjava.txt code: • bgChanger( ) has been split into two functions: (1) an initRGB( ) function that sets up red, grn, and blu, and sets the document background to the begin color, and (2) a changeBC( ) function that handles red/grn/blu background color incrementation. Before going any further, I should note that document.bgColor is in fact deprecated and that, per Mozilla's recommendation, my demos use document.body.style.backgroundColor to set the document background color. As identifiers, the begin, end, and steps initRGB( ) parameters would ordinarily be scope-wise limited to the initRGB( ) function. The changeBC( ) function does not need to act on begin but does need to act on end and steps, and thus it is necessary to pass the latter two parameters to changeBC( ).
	...
	changeBC(end, steps); } // End of the initRGB( ) function

function changeBC(end, steps) {
	...
• Delayed changeBC( ) recursion is carried out via the following conditional: if (step <= steps) window.setTimeout("changeBC('" + end + "'," + steps + ");", 70); /* The setTimeout( ) delay in the #bgcolordemo1 demo was 200 milliseconds. Your specific choice for this number is ultimately a matter of taste, of course. */ • After an initial black-to-red run, subsequent begin-to-end runs are triggered not as top-level code but in the changeBC( ) function, and in sync with a totalsteps variable that is globally initialized to 0 and is increased by one whenever document.body.style.backgroundColor is set.
else {
	document.body.style.backgroundColor = "#" + end;
	totalsteps++;
	if (totalsteps == 25) initRGB("ff0000", "000000", 25);
	if (totalsteps == 50) initRGB("000000", "aa00ee", 25);
	if (totalsteps == 75) initRGB("aa00ee", "000000", 25);
	... } } // End of the changeBC( ) function
Other code possibilities   Losing Dec2Hex( ) I stated in the previous entry that the script's Dec2Hex( ) function is unnecessary; this is because document.body.style.backgroundColor can be set to a stringified rgb(R,G,B) function taking decimal R, G, and B values. Accordingly, in the changeBC( ) function we can comment out the red_hex/grn_hex/blu_hex lines and then set the intermediate (non-begin/end) document.body.style.backgroundColor values with: document.body.style.backgroundColor = "rgb(" + red_round + "," + grn_round + "," + blu_round + ")"; Relatedly, we could if desired feed decimal R, G, and B values to the initRGB( ) function - this would allow us to ditch initRGB( )'s charAt( ) and parseInt( ) code:
function initRGB(red_valA, grn_valA, blu_valA, red_valB, grn_valB, blu_valB, steps) {
	steps = steps - 1;
	red_int = (red_valB - red_valA) / steps;
	grn_int = (grn_valB - grn_valA) / steps;
	blu_int = (blu_valB - blu_valA) / steps;
	... }

<!-- Black to red: -->
<element onEvent="initRGB(0,0,0,255,0,0,25);"> ...
Moreover, there's no need to hold on to the begin variable in this case as document.body.style.backgroundColor can be set to its initial color with document.body.style.backgroundColor = "rgb(" + red_valA + "," + grn_valA + "," + blu_valA + ")"; but you'll still need to define end in the initRGB( ) function as end = "rgb(" + red_valB + "," + grn_valB + "," + blu_valB + ")"; and then pass end to the changeBC( ) function for setting document.body.style.backgroundColor to its final color. (OK, we could get rid of end too if we wanted to. I can think of at least one end-less alternative but it doesn't offer any improvement over the preceding code.) A smoother color change In preparation for this post, I wrote an alternate version of the #bgcolordemo2 demo in which red/grn/blu are incremented not by red_int/grn_int/blu_int but by one decimal unit at a time; this alternate demo - let's call it #bgcolordemo3 - was inspired by HTML Goodies' JavaScript Script Tips #76-78 script, which (when using Netscape 4.x, and only when using Netscape 4.x) vertically rolls out and rolls up a layer element on a pixel-by-pixel basis and which we checked over in Blog Entry #94. As a means of effecting the color 'flashes' of the #bgcolordemo2 demo, the #bgcolordemo3 code now strikes me as inefficient but it does give smoother transitions vis-à-vis the slower color change of the #bgcolordemo1 demo, so I thought we would talk about it a bit. #bgcolordemo3's initRGB( ) function has a two-parameter String hexcodeA, String hexcodeB signature, and it specifies red, grn, blu, red_valB, grn_valB, and blu_valB à la the #bgcolordemo2 script. However, #bgcolordemo3 eliminates the initRGB( ) steps calculations and recasts the incrementation code in the changeBC( ) function as: if (red < red_valB) red++; else if (red > red_valB) red--; if (grn < grn_valB) grn++; else if (grn > grn_valB) grn--; if (blu < blu_valB) blu++; else if (blu > blu_valB) blu--; document.body.style.backgroundColor = "rgb(" + red + "," + grn + "," + blu + ")"; Delayed changeBC( ) recursion is carried out via the following conditional: if (!(red == red_valB && grn == grn_valB && blu == blu_valB)) window.setTimeout(changeBC, 10); /* More incrementations ⇒ a shorter setTimeout( ) delay. Mozilla addresses here the minimum value for the setTimeout( ) delay parameter. */ As long as the current color - rgb(red,grn,blu) - is not equal to the final color - rgb(red_valB,grn_valB,blu_valB) - then changeBC( ) will be re-called. changeBC( ) is not parameterized: we've already gotten rid of steps; the end variable is eliminated by setting document.body.style.backgroundColor to its final color with document.body.style.backgroundColor = "rgb(" + red_valB + "," + grn_valB + "," + blu_valB + ")"; in an accompanying else clause. After an initial script run, subsequent runs are triggered in the else clause and in sync with a bgChange variable that is globally initialized to 0 and increased by one at the end of a run. ... bgChange++; if (bgChange == 1) initRGB("ff0000", "000000"); if (bgChange == 2) initRGB("000000", "aa00ee"); if (bgChange == 3) initRGB("aa00ee", "000000"); ...   Other applications/demo #3 The code detailed in this entry can be applied not only to the background color of a document but to any colorable aspect of a Web page: text, borders, tables and rows/cells thereof, etc. Accordingly, I thought it would be cool to wrap up this post by applying the A smoother color change code to a text scroll:
 

The scroll part of the demo was taken from the #scrolldemo189 demo at the end of Blog Entry #189. The demo applies to the scroll a series of colors - red, orange, yellow, green, blue, indigo, and violet - that runs cyclically via the following conditional:

if (bgChange == 6) { bgChange = 0; initRGB("ee82ee", "ff0000"); } // Violet to red

A brief note on script authorship

At the top of the tutorial page, Joe acknowledges, Thanks to Josh Robbins for this script. On the other hand... I was curious as to whether anyone had come up with a catchy name for #aa00ee, which is not a standard color, so I did a Google search on it; among the many resulting hits were a number of pages hosting the "Background JavaScript" script, including this page on which a Geoff Baysinger claims authorship of the script (excluding the Dec2Hex( ) function, which he credits to the hIdaho ColorCenter). Geoff or Josh or whoever, we thank you for your efforts.

We're nearing the end of the 'classic' Beyond HTML : JavaScript tutorials written by Joe, and there's really just one left to cover, "A Quick Tutorial on JavaScript Variable Passing" - we'll hit this guy next time.

reptile7

Saturday, September 18, 2010
 
The Black and the Red
Blog Entry #191

The scrolling text scripts we've discussed in recent entries nicely illustrate an important aspect of JavaScript: JavaScript can dynamically change object.property values not only 'all in one go' but also in a gradual, stepwise manner. Our Beyond HTML : JavaScript tutorial du jour, "So, You Want A Background JavaScript, Huh?", continues in this vein by presenting a script designed to gradually change a document's background color.

The "Background JavaScript" script can be accessed by following the tutorial's The Script Is Here link. The script was once put in the tutorial source so as to provide a script demo as the tutorial page loads but, à la the "Live Script" script discussed in the previous post, was removed therefrom when the HTML Goodies site was remodeled in early 2005. However, at earlier editions of the tutorial (e.g., here) the script does not work as advertised on my computer, so perhaps I should give you a little taste of how it's supposed to go here and now. In the div below, click the button:

Cool, huh?

 
I'll discuss my demo, how its code differs from that on the backjava.txt page, and how it can be improved in due course, but for now, let's get deconstructing the backjava.txt code, shall we? Script overview The "Background JavaScript" script comprises two script elements (the first script element's start-tag is missing on the current backjava.txt page but is present on the pre-15-February-2005 backjava.txt page). The first script element contains three functions, in source order: (1) an initArray( ) function, which is never called and can be thrown out; (2) a Dec2Hex( ) function for converting decimal numbers to hexadecimal numbers - we'll see later that this function is also unnecessary; and (3) a bgChanger( ) function that does most of the script's work. The second script element holds a series of eight calls to bgChanger( ); each call takes the document background color from a begin color to an end color. Per these calls, the document's background color is changed from black to red to black to #aa00ee (labeled purple in the preceding comment, but purple is actually #800080) to black to blue to black to finally white. The first bgChanger( ) call (bgChanger("000000", "000000", 25);) does not in fact effect a background color change - it is meant to function as a black-to-black "pause" - and can be removed. Let us then consider the second bgChanger( ) call, which takes us from black to red: // black to red bgChanger("000000", "FF0000", 25); 000000 and FF0000 are of course the RRGGBB hex codes for black and red, respectively. bgChanger( ) will initially set document.bgColor to 000000 (it was not necessary to preface an RRGGBB value with a hash mark (#) in classical JavaScript) and then incrementally change document.bgColor to FF0000 over the course of 23 intermediate RRGGBB values; however, this change is carried out on a decimal basis, as detailed below. 00 to FF The black to red background color change makes a good deconstruction test case as it will allow us to focus on the RR parts of these colors' hex codes and mostly ignore the GG and BB parts, for which no change occurs. As shown above, the second bgChanger( ) call passes to bgChanger( )
function bgChanger(begin, end, steps) {
	steps = steps -1;
	... }
three arguments: (1) the string "000000", which is assigned to begin; (2) the string "FF0000", which is assigned to end; and (3) 25, which specifies the total number of values that will be assigned to document.bgColor from start to finish and is given a steps identifier. bgChanger( )'s first statement decrements steps to 24 - we'll see why in a moment. The next two bgChanger( ) lines extract the RR part of "000000" and convert it to its decimal equivalent redA = begin.charAt(0) + begin.charAt(1); // Returns the string "00" red_valA = parseInt(redA, 16); // Returns the number 0 /* In the original script, the parseInt( ) radix argument, 16, is single-quoted; it shouldn't be. */ and the two bgChanger( ) lines after that do the same for "FF0000": redB = end.charAt(0) + end.charAt(1); // Returns the string "FF" red_valB = parseInt(redB, 16); // Returns the number 255 So, RR-wise we want to decimally begin at 0 (red_valA) and end at 255 (red_valB). The next bgChanger( ) line uses steps to calculate an equidistant spacing between (25) successive R values via which 0 will be incremented to 255: red_int = ((red_valB - red_valA) / steps) * -1; // Returns the number -10.625 (Recall from middle school geometry class that if a line segment running from a to b is divided into c point-delimited segments of equal length, then the distance between points is given by (a - b) / c.) The next ten bgChanger( ) lines carry out analogous operations for the GG and BB parts of "000000" and "FF0000"; by inspection, you should be able to determine that grn_valA, grn_valB, grn_int, blu_valA, blu_valB, and blu_int will all be 0. The following bgChanger( ) line declares/initializes to 2 a step counter variable for RR value incrementation. Subsequently, red_valA, grn_valA, and blu_valA, all 0, are respectively assigned to red, grn, and blu variables. step = 2; red = red_valA; grn = grn_valA; blu = blu_valA; We are ready to begin setting and changing the document background color. A document.bgColor = begin; assignment sets the document background color to its initial color, black, and is followed by a while loop that will take the red part of document.bgColor from 0 to 244.375.
while (steps >= step) {
	red -= red_int;
	red_round = Math.round(red);
	red_hex = Dec2Hex(red);
	
	/* Analogous code for grn and blu */
	
	document.bgColor = red_hex + grn_hex + blu_hex;
	step++; }
The loop body will be executed 23 times. Here's what happens in the first loop iteration: (1) red -= red_int; increments red to 10.625. Perhaps you are wondering, "Why don't we use the += operator to increment red, and get rid of the -1 factor in red_int's declaration?" Well, that would be more intuitive, wouldn't it? (2) red_round = Math.round(red); rounds red up to 11, which is assigned to red_round. (3) The script's Dec2Hex( ) function is called; Dec2Hex( ) should be passed red_round and not red.
var hexChars = "0123456789ABCDEF";

function Dec2Hex(Dec) {
	var a = Dec % 16; /* The % arithmetic operator is briefly summarized here. */
	var b = (Dec - a) / 16;
	hex = "" + hexChars.charAt(b) + hexChars.charAt(a);
	return hex; }
(4) Dec2Hex( ) converts the red_round number to a corresponding two-digit hexadecimal string. (a) red_round is given a Dec identifier. (b) The var a = Dec % 16; line indirectly calculates the ones-place digit of Dec's hexadecimal equivalent. 11 % 16 gives 11, which is assigned to an a variable. (c) The var b = (Dec - a) / 16; line indirectly calculates the tens-place digit of Dec's hexadecimal equivalent. (11 - 11) / 16 gives 0, which is assigned to a b variable. (d) The hex = "" + hexChars.charAt(b) + hexChars.charAt(a); line builds the two-digit hexadecimal string. An empty string, 0 (hexChars.charAt(b)), and B (hexChars.charAt(a)) are concatenated to give the string "0B", which is assigned to hex. (e) hex is returned to the Dec2Hex( ) function call. Back in the bgChanger( ) function, the Dec2Hex( ) return is given a red_hex identifier. We can convert Dec to hex more straightforwardly, and without the need for the hexChars hexadecimal digit string, via the toString( ) method of the Number object:
function Dec2Hex(Dec) {
	var hex = Dec.toString(16);
	if (/^[0-9a-f]$/.test(hex)) hex = 0 + hex; /* This statement ensures a two-digit hex if the toString( ) return only holds one digit. */
	return hex; }
(5) The analogous grn and blu parts of the loop lead to a "00" string return for both grn_hex and blu_hex. (6) red_hex ("0B"), grn_hex ("00"), and blu_hex ("00") are concatenated to give "0B0000", which is assigned to document.bgColor. (7) step++; increments step to 3. In the second loop iteration: red increments to 21.25, which is rounded to 21, which is converted by Dec2Hex( ) to the string "15", and therefore "150000" is assigned to document.bgColor. red_hex - more precisely, the number it stringifies - continues to hexadecimally increase by B or A (depending on whether the Math.round( ) operation rounds up or down, respectively) in successive iterations until it hits "F4" in the 23rd iteration. Here are the document.bgColor hex codes for these iterations:
3rd: 200000		10th: 6A0000		17th: B50000
4th: 2B0000		11th: 750000		18th: BF0000
5th: 350000		12th: 800000		19th: CA0000
6th: 400000		13th: 8A0000		20th: D50000
7th: 4A0000		14th: 950000		21st: DF0000
8th: 550000		15th: 9F0000		22nd: EA0000
9th: 600000		16th: AA0000		23rd: F40000
At the end of the 23rd iteration, step increments to 25 and consequently the while condition is no longer true. Control now passes to bgChanger( )'s final statement, a document.bgColor = end; command that sets the document background color to FF0000. I trust you can à la my analysis work through the other bgChanger( ) color changes at this point. Let's sum up: • The bgChanger( ) function first separates the RR/GG/BB parts of the begin and end hex code strings and converts them to decimal equivalents. • bgChanger( ) next calculates equidistant spacings for the R/G/B parts of the values that we want to assign to document.bgColor and then serially raises or lowers the decimal begin R/G/B numbers by those spacings. • The raised/lowered decimal R/G/B numbers are converted back to corresponding hexadecimal strings, which are reassembled into hex code strings, which in turn are assigned to document.bgColor to change the document background color. So far, so good. As for how this all works in practice, well, we'll get to that in the next post. reptile7

Thursday, September 09, 2010
 
Got Live and In Print If You Want It
Blog Entry #190

Today we will briefly discuss the "Print a Web Page Using JavaScript" and "So, You Want A Live Script, Huh?" tutorials in HTML Goodies' Beyond HTML : JavaScript sector.

Print it

Back when we were discussing the document.execCommand( ) method not so long ago, we noted in the "Syntax" section of Blog Entry #179 that a few execCommand( ) commands have an associated user interface and that one of those commands is a print command. Microsoft provides at this page a summary of the print execCommand( ) command, which [o]pens the print dialog box so the user can print the current page. The print command does not appear in Mozilla's list of supported execCommand( ) commands nor is it among the execCommand( ) commands that are slated to be standardized in HTML5 (the W3C may or may not standardize execCommand( ) and its commands in the future).

In querying support for the print command with the document.queryCommandSupported( ) method, I find on my iMac that document.queryCommandSupported("print") returns true when using Safari or Chrome and false when using Opera; as noted in the "Query it" section of Blog Entry #180, document.queryCommandSupported( ) is not supported/implemented by Firefox and Camino. In the event, running document.execCommand("print") (the print command doesn't take a value, required or optional) with Safari and Chrome does indeed pop up my print dialog box
[My iMac's print dialog box]
but with Opera throws a NOT_SUPPORTED_ERR error. Somewhat strangely, nothing happens at all when I try to run document.execCommand("print", false, null) with Firefox and Camino: although the print dialog doesn't pop up (I wasn't expecting it to), no errors are thrown, either.

Fortunately, there is a simpler, cross-browser way to open a print dialog box - a way I heretofore had been unaware of, as we've never used it previously, and that was brought to my attention by HTML Goodies' "Print a Web Page Using JavaScript" tutorial. In JavaScript 1.2 (i.e., for Navigator 4.0-4.05), Netscape added to the client-side window object a print( ) method for printing the contents of the window. The window.print( ) method was subsequently picked up by Microsoft; according to irt.org, MSIE support for window.print( ) began with MSIE 5 (the MSDN Library doesn't specify any 'this feature requires Microsoft Internet Explorer x.x or later' history at its window.print( ) page). That would be MSIE 5 for Windows, guys - I find that window.print( ) throws an Object doesn't support this property or method runtime error with MSIE 5.x for the Mac. Moreover, the W3C has brought window.print( ) into HTML5.

window.print( ) is a pretty basic method - it takes no parameters and doesn't have a return value (var printReturn = window.print( ); returns undefined) - and "Print a Web Page Using JavaScript" is accordingly a pretty basic tutorial. Joe provides code for triggering window.print( ) with a link or a button. His link-trigger code

<a href="javascript:window.print( );"> ...text or an image... </a>

features a JavaScript URL whereas his button-trigger code

<form><input type="button" onclick="window.print( );" /></form>

employs an input element-type button wrapped in a form element. I recommend the latter approach - I don't like the use of links as user interface elements - but with a standalone button element:

<button type="button" onclick="window.print( );"> ...text, an image, whatever... </button>

That said, Joe's Click to Print This Page link demo works with all of the non-MSIE OS X GUI browsers on my computer.

The tutorial also sports a "Some Printing Suggestions" section whose useful recommendations include:
(1) Use window.print( ) with a print-optimized page, more specifically, a page whose content width is no more than 500px and with no more color/graphics than is necessary.
(2) Don't trigger window.print( ) via an event that might catch the user by surprise (Joe doesn't quite put it this way, but that's what he means), e.g., a load or mouseover event.

Before moving on...
As pointed out in the tutorial comment thread, it is possible to print only part of a page by combining window.print( ) with some CSS: simply apply to the page a media="print" style element that zeroes out unwanted content via a display:none; declaration.

<style type="text/css" media="print">
.noprint { display: none; }
/* Equivalently, you can subtract the media="print" attribute and use
@media print { .noprint { display: none; } }
for the style rule. */
</style>
...
<p class="noprint">Don't print me, Bro...</p>


Is it live, or is it JavaScript?

As recounted in Wikipedia's "JavaScript" entry and references cited thereby, JavaScript was in mid-1995 originally named "Mocha"; over the next several months, "Mocha" was rechristened "LiveScript" and then "JavaScript". HTML Goodies' "So, You Want A Live Script, Huh?" tutorial presents a small script comprising a script element equipped with a LANGUAGE="LiveScript" attribute but that is otherwise recognizable as classical JavaScript.

The "Live Script" script can be accessed by following the tutorial's Here's the Script! link and is given below:
<script language="LiveScript"><!--
// This script is by Paul Tahan, Jr.

function checkAGE( ) {
	if (!window.confirm("WRITE YOUR OWN MESSAGE IN HERE"))
		history.go(-1);
	return " "; }
document.writeln(checkAGE( ));

// End -->
</script>
(For reasons beyond my understanding, the script element start-tag's beginning < and ending > have been respectively escaped to &lt; and &gt; at the popup.txt page - I've unescaped them in the above code. Other changes: I've switched the script element's HTML-type comments to JavaScript comments and removed the extra right parenthesis character at the end of the confirm( ) parameter string.)

Joe credits the "Live Script" script to a Paul Tahan, Jr.; however, the above script is only slightly different than the script discussed by HTML Goodies' JavaScript Script Tips #5-9, which has a Copyright © JemWeb 1997 credit and which we covered in Blog Entry #55. (The former script at least has a checkAGE( ) function call; a corresponding JemWebCONFIRM( ) call in the latter script is missing.)

Quick deconstruction

The document.writeln(checkAGE( )); line calls the checkAGE( ) function, which first pops up a confirm( ) box:
[The confirm( ) box for the 'Live Script' script]
Upon clicking the button, the if condition returns true and the user is taken back to the previous page by the history.go(-1); command. Upon clicking the button, the if condition returns false; subsequently, a space character is returned to the checkAGE( ) function call and the current (script-running) document is loaded. In effect, the "Live Script" script acts as a gateway for asking the age-old question, "Are you sure you want to enter [this Web page]?", which is the confirm( ) message in Joe's not-really-a-demo for the Script Tips #5-9 script.

Speaking of demos, there should be a script demo at the "Live Script" tutorial page, i.e., the script should run and the confirm( ) box should pop up as the page loads; however, the script was inexplicably taken out of the tutorial source when the HTML Goodies site was overhauled in mid-February 2005. To see Joe's original "Live Script" demo, follow this link to a 1999 edition of the tutorial.

Two more points:

(1) If the "Live Script" script is placed in the document head (and that's where it belongs), then the space that is returned to the checkAGE( ) function call and the newline appended thereto by the document.writeln( ) command will be collapsed to an empty string, and the document body content will begin at the origin of the canvas as it normally would. Alternatively, a return "Some text...";-type statement could be used to place a message (e.g., Hello, Visitor.) at the canvas origin, if you'd rather do that.

(2) Near the end of the tutorial, Joe reports, Also, as far as I can see, it doesn't matter which [confirm( )] button people click on, OK or Cancel. The [current] page loads either way. This would seem to contradict my Quick deconstruction above, but if the script page were accessed in a new window/tab, which would not have a history.go(-1) location, then Joe would in fact be correct. He's not correct if the page is accessed in the same window/tab framing some other page; in this case, clicking the button will definitely return the user to the history.go(-1) page.

Do I really need to put a separate demo in front of you? Oh, why not? In the div below, click normally (don't right-click or control-click) on the here Div A link. When the confirm( ) box pops up, click the button, which should bring you back to Div A. Reclick the Div A link to redisplay the confirm( ) box; click the button to load Div B.

This is Div A.

Click here to test the "Live Script" script.

The next Beyond HTML : JavaScript tutorial, "Advanced JavaScript for Web Developers: onClick and onMouseOver", is very basic (there's nothing remotely "advanced" about it, although at least its demos work) and we won't be covering it, but the sector tutorial after that, "So, You Want A Background JavaScript, Huh?", offers some real 'flesh on the bone', namely, a complicated coloring script that we'll take up in the following entry.

reptile7


Powered by Blogger

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