reptile7's JavaScript blog: Getoverture II

Sunday, December 12, 2010

Getoverture II
Blog Entry #199

In the previous post we introduced HTML Goodies' "How to Populate Fields from New Windows Using JavaScript" tutorial and we are ready to get our analysis thereof under way. We kick things off with an overview of the forms.html opener document.

forms.html

Structure

The forms.html document body comprises a name="myForm" form that holds a respectfully diverse collection of controls: two text fields, a four-option selection list, a pair of radio buttons, a checkbox, a textarea field, and a submit button.

Implicitly associated with each control element is a label element parent. Excluding that for the submit button, each label element contains (in addition to its associated control) an Input #[1-7] text label preceded by a square-bracketed question mark, [?], that will serve as a help icon and link us to the help.html remote control document. Here's the label/control code for the second text field:

<label>[<a href="help.html#input2" onclick="openWin(this.href); return false;" title="Help on filling out input #2.">?</a>]

Input #2 <input type="text" value="Value #2" name="input2"></label>

Finally, the form display is framed by a fieldset element and given a Dummy Form caption by a legend element.

Presentation

Let's temporarily turn to the style.css file that styles the forms.html page. The style.css style sheet is imported into forms.html by, appropriately, an @import rule:

<style type="text/css"></style>

The forms.html label elements and textarea element are given block-level renderings via display:block; declarations. (Interactive or not, labels are extrinsic to a form's data set and consequently are not controls, although for the purpose of layout classification, the HTML 4.01 Strict and Transitional DTDs both put the label element in the %formctrl; group of elements, which is a subset of the %inline; group of elements.)

Interestingly, the forms.html document body is centered by (a) giving it a width that is less than the viewport width and (b) setting its margin-left and margin-right properties to auto:

body { width: 50%; margin: 10px auto; /* ...other declarations... */ }

/* Note that margin: 10px auto; is equivalent to: margin-top: 10px; margin-right: auto; margin-bottom: 10px; margin-left: auto; */

I've never seen this done before, but it makes sense, as it's the same approach we used to center a form in Blog Entry #93.

Setting a width for the body element effectively sets widths for the myForm form and its fieldset frame, as the form and fieldset elements are both block-level elements with effective widths of 100%. The label elements are centered within the fieldset (their "containing block") à la the body element. By default, label elements are "non-replaced inline elements" (see the "Applies to:" field of the aforelinked width property definition) and thus cannot ordinarily be given widths, but we've made them block-level elements here, so we're OK.

And for my fellow nitpickers:

(1) In choosing a typeface for the fieldset caption, the author initially sets the legend font-family to georgia, a serif font, and then switches to sans-serif for a generic backup. Why? Your guess is as good as mine.

(2) The input, select, textarea selector has two color declarations: the latter declaration, color:#3af*, "wins", i.e., is operative.
*color:#3af is equivalent to color:#33aaff.

Behavior

The style.css style sheet contains the following onmouseover-type rules:

a:hover { border-bottom: solid 1px #f90; }

label:hover { color: #39f; border-left: solid 5px #3af; padding-left: 10px; }

Mousing over each link (? help icon) changes its border-bottom color from #39f to #f90; more noticeably, mousing over each label changes its text color from #39a (this value is inherited from the body element) to #39f. More significantly, mousing over each label renders a thick, bluish border-left that highlights the label for the user:

Moreover, mousing over each link pops up a Help on filling out input #[1-7] tooltip via the link's title attribute.

The main behavioral aspect of the forms.html document, however, is the onclick="openWin(this.href); return false;" event handler that graces each help icon link, e.g.:

<a href="help.html#input1" onclick="openWin(this.href); return false;" title="Help on filling out input #1.">?</a>

For JavaScript-enabled users, clicking each link triggers the openWin( ) function in the forms.html document head and passes thereto this.href, the link's destination URL, which is given a page identifier by the openWin( ) declaration:

function openWin(page) {

	var w = window.open(page, "", "menubar=no,history=no,resizable=yes,scrollbars=yes,toolbar=no,width=400,height=400"); }

openWin( ) opens a 400px-by-400px secondary window holding the page resource. FYI: Neither Mozilla nor Microsoft lists a history feature in its window.open( ) documentation.

For JavaScript-disabled users or users without JavaScript support ("sans-JavaScript users"), clicking each link loads the page resource into the current window via the link's href attribute - the return false; statement of the onclick event handler prevents this from happening for JavaScript-enabled users.

Each link's href value points to a help.html fragment that will assist the user with the link's associated control by providing
(a) information about the control, and
(b) one or more interface elements allowing the user to indirectly interact with the control.

help.html

We move now to the help.html remote control document. The entire help.html source is reproduced on the tutorial's first page, and a deconstruction for that source fills out the rest of the tutorial - a deconstruction that is a bit rough in places but is basically on target.

As implied by the last paragraph of the preceding section, the help.html document can be structurally subdivided into seven sections, one for each input-type control of the myForm form. Each section contains three parts:
(1) an Input #[1-7] h2 heading that also serves as a target anchor via its id attribute;
(2) a p element that gives information about the control; and
(3) a JavaScript script that writes out an interface via which the user can set a value for the control.

On the rendered help.html page, sans-JavaScript users see the (1) and (2) parts but not the (3) parts. Here's what JavaScript-enabled users get for part (3):

• For the Input #[1-2] text fields, the script interface comprises a labeled text field and an push button; analogously, a labeled, smaller-than-its-forms.html-counterpart textarea field and button compose the interface for the Input #7 textarea field. The user enters a value into a text field or the textarea field and then clicks the button, which triggers a function that transfers the entered value to the corresponding field in the opener document.

• For the Input #3 selection list, the script interface comprises a set of three links - Option A, Option B, and Option C - that correspond respectively to the Option A, Option B, and Option C options of the selection list. Clicking each link triggers a function that changes the selection list's current selection to that specified by the link.

• For the Input #[4-5] radio buttons, the script interface comprises a Choose input #[4-5] link that when clicked triggers a function that checks the appropriate radio button.

• For the Input #6 checkbox, the script interface depends on whether the checkbox is checked or unchecked. If the checkbox is unchecked, as is the case when forms.html first loads, then the help.html#input6 fragment displays a Choose input #6 link, whereas if the checkbox is checked, then the help.html#input6 fragment displays a Deselect input #6 link; clicking the former or latter link triggers a function that checks or unchecks the checkbox, respectively.
(N.B. This interface is not visible at the isolated help.html page as it is written by a conditional that throws an error in the absence of an opener document.)

We'll take a detailed look at - and hopefully improve - the help.html script interfaces and the functions they call in the next entry.

reptile7
- posted by A. Peak @ 2:55 PM

Comments: Post a Comment

<< Home

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

About Me