reptile7's JavaScript blog is Andrew Peak's personal technical writing project: it focuses on JavaScript and the analysis of JavaScript scripts, although HTML, CSS, and anything else related to coding for the Web are also fair game.

Today's and the next posts will examine the Script Tip #74 Script, the second of three password-protection scripts that are discussed by HTML Goodies' JavaScript Script Tips #73-75. We saw in the previous entry that the Script Tip #73 Script contained its password and its target Web page URL, which were unrelated to each other. In contrast, the Script Tip #74 Script's target Web page URL is partially composed of the script password. As we'll see later, the Script Tip #74 Script concatenates an inputted password with other text strings to give a value for a location.href command: if this value matches the target page URL, then the user is linked to the target page; if not, the user is taken to a "File not found" page.

The Script Tip #74 Script's display is mostly housed in a one-row, three-cell table; commingled with the table is a form named iAccInput. The first table cell holds User Name: and Password: strings that serve as labels for text boxes that are respectively named iName and iAccID and that are held by the second table cell. The third table cell contains self-explanatory Login and Reset buttons.

Above the table, and separated therefrom by a horizontal rule (<hr>), is a large Login heading, which is as good a place as any to begin crafting a style sheet. The Login heading is coded as:

This heading is marked up in six different ways:
(1) The p element parent gives it a block-level display.
(2) The (deprecated) align="center" attribute centers it on the page.
(3-4) Its font size and typeface are set by the size="5" and face="arial" attributes of the (deprecated) font element.
(5) The b element boldens it.
(6) The (deprecated) u element underlines it.
(Curiously enough, this is the first time we've encountered the u element in HTML Goodies' JavaScript materials. Why the W3C decided to retain the b and i elements but deprecate the no-less-wonderfully-intuitive center and u elements surely ranks as one of the great mysteries of the ages.)

The display table is itself centered on the page by a center element. Also, in the demo page document Joe equips the table element start-tag with six attributes that do not appear on Script Tip #74's "Here's the Code" page:

Bordercolor? Bordercolorlight? Bordercolordark? As you might suspect, these attributes are neither "strict" nor "transitional" W3C table element attributes but are - you guessed it - proprietary Microsoft...I would say "attributes" but according to the MSDN Library links above, borderColorLight and borderColorDark are properties of the table scripting object and are not supposed to be HTML attributes at all. The borderColorLight and borderColorDark properties are meant to be used in conjunction with the W3C-kosherborder property of the table object; regarding Joe's table element, we would write these properties in a script as follows:

And just what do borderColorLight and borderColorDark do, anyway? The MSDN Library gives each of these properties the same description:

Sets or retrieves the color for one of the two colors used to draw the 3-D border of the object.

Turning to HTML Goodies' highly useful "CSS and Borders" tutorial, we see that there are four values of the CSS border-style property that seem to give rise to "3-D" borders: groove, inset, outset, and ridge. (However, CSS 2.1 specifies context-dependent definitions for the inset and outset values when applied to tables - see here.) In practice at the demo page, inspection of the display table shows that the bordercolor="gray" bordercolorlight="gray" bordercolordark="black" markup gives a border whose appearance is a cross between the solid and outset CSS border styles when using MSIE: the top and left borders are solidly gray and the right and bottom borders are solidly black, even though we would expect all four borders to be solidly gray because only the bordercolor attribute should be operative.

In any case, if your browser is up to date, then you can replace the display table's centering and attributes - all of them - with the following style rules:

Comments
• Tables are normally rendered as block-level elements, which can be centered by setting the CSS margin-left and margin-right properties to auto.
• CSS 2.1 discusses here the use of the border-collapse and border-spacing properties to insert spacing between the table border and adjacent cells and between the table cells themselves, i.e., as a replacement for the table cellspacing attribute.
• The grayblackblackgray values of the border-color property respectively set colors for the top, right, bottom, and left borders of the table/td elements, as detailed here.
• Table cellpadding can be handled at the td element level via the padding property.

The first table cell is also marked up in several different ways:

<td align="right"><font size="3" color="#ff0000" face="arial"><b>User Name:</b></font><br><br>
<fontsize="3" color="#ff0000" face="arial"><b>Password:</b></font></td>
<!-- In the preceding line, there's supposed to be a space between font and size; as a result of this typo, the font element attributes are not applied to the Password: label on the demo page. -->

(The first table cell has a header-like quality, and an argument can be made that it should be coded as a th element as opposed to a td element, but I'm going to stick with a td element for this post.)

Moving to the second and third table cells, three of the four iAccInput controls have been equipped with height and/or width attributes, which are not valid for the input element; for a second example, the Login button is coded as:

The MSDN Library says that the width attribute (but not the height attribute) should be legit for all of the visible input element types, so one might expect the Login and Reset buttons to have 50px widths when using MSIE, but this isn't what I see on my computer. (In case you were wondering, I don't see a 50px height for the iAccID text box nor a 40px height for the Login button, either.)

Leaving aside for a moment the issue of whether or not you actually want to set non-default dimensions for these controls, the question arises: Can we use CSS to change input element heights and widths? The W3C confesses:

CSS 2.1 does not define which properties apply to form controls and frames, or how CSS can be used to style them. User agents may apply CSS properties to these elements. Authors are recommended to treat such support as experimental. A future level of CSS may specify this further.

In the event, I find that both MSIE 5.1.6 and Netscape 7.02 will apply a

input { height: 50px; width: 50px; }

rule set to the iAccInput controls, although my preference is to go with their default dimensions (and simply remove the input height/width attributes).

Finally, we can set the document background color with:

body { background-color: lime; }

OK, that should take care of the presentational aspects of the Script Tip #74 Script. We'll look at the JavaScript parts of the script in the following entry.