*********You do not have javaScript enabled.*********
If there is no navigation on the left of your screen, then please go to the Main Page (or open "index.html" in the current directory)

Designer

Client-side Techniques

The site uses a wide variety of client-side techniques, some of which are described here.

Frames

A frame-based structure with 'navigation' and 'content' frames requires minimal changes for new page additions, into the navigation frames.

One disadvantage of frames is that content-frames can be opened independently. Here, JavaScript forces a page into its frameset.
However, many visitors have browsers without JavaScript support, or disabled. Every page includes a <noscript> tag, with navigation-instructions and hard-coded links to guide the user. All non-demonstration pages are accessible without JavaScript.

A third, hidden, frame also exists. This retains variables used throughout the site. Alternatives for global-variables are transient cookies or hidden windows, but for a frames-based site, this was easiest.

Techniques used in Feedback.html

The Feedback page uses many different JavaScript-based techniques.
Field validation is done on both field-exit (onblur event) and form-submission.
Techniques include:

Use of regular expressions for pattern-matching where possible.
Gain and loss of focus in a field fires onblur / onfocus events, to change the field style.background-color property.
In one case during data-entry, an "alert" box communicates concern.

On form-submission:

Revalidation may result in a plain, text-only, error-report.
This is presented in a new page in a new window.
Page-visit counts (stored in an array in the hidden frame) are written to the document.cookie.
All cookies are read into a hidden <textarea> (display property ='none'). When the form is submitted, both this 'cookie data' and the entered 'form data' are sent.

return to top

Event-handling and Cookies

Event-handling is used for field-colour-changes and for storing cookies between sessions.
Page-visits increment array values and at session's end, the onunload event of the frameset (index.html) causes page-visit counts and other values to be written to the document.cookie.
Of the options:

to write cookies on entry to a page, or
accumulate page-counts during the session, then write them at end of session,

I chose the latter for coding style - despite its failure in Opera which does not support onunload (or many events).

Internationalisation

All pages have been defined to use the English language and all define the international-standard for (western) characters, charset=iso-8859-1.


<?xml version="1.0" ?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html lang="en" xmlns="http://www.w3.org/1999/xhtml" >

<head>
<meta http-equiv="Content-Language" content="en" />
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />

Other techniques

Some pages use a button to toggle the visibility of code samples, which are intrusive to reading the page. This changes the display property of the enclosing <pre> tags.
The 'DOM_Manipulation' and 'Folding_Tables' demonstrations open existing pages in new windows
Page names are stored in arrays.
Code navigation links, page-visits counts for cookies, and the page-feedback table use this array.

return to top

Development Techniques

Browser in-compatibility and W3C validations

All pages have been validated to W3-recommendations, using 'XHTML1-Strict' wherever possible. (Deviations from this standard are explained when they occur - see Validation Chart). This helps accessibility through adherence to common standards.

Javascript syntax

By using Netscape as a development browser, access is given to the JavaScript console, which pinpoints the location of syntax errors.

return to top

The World Wide Web

There are plenty of resources on the web; the browser-detection code that is used was found there, and familiarity with www.W3.org and development sites is essential.

Validation of Site Pages

Whereever possible, validation is to XHTML1-Strict.
For various reasons, some pages cannot make the grade:

Most pages	<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
Index.html	This is the frameset page, which cannot be validated to html-strict. Instead, it is written to the frameset level: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Frameset//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-frameset.dtd">
Nav.html and navCode.html	As the site uses frames, the frame-navigation pages cannot be written to strict standards. They require the use of the "target" attribute to tell navigation where (i.e. into which frame) to put a page. As the target attribute is deprecated, this cannot be done when writing XHTML_Strict.For these pages, the HTML-Transition level of validation is used: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
Group1.html (new Window)	In the "open a new Window" page, I demonstrate opening a new window with the html "target" attribute. As with the navigation pages, I can validate only to XHTML 1.0 Transitional (as above)
Group4 demo, DOMPlay.html	When manipulating the DOM, I force a table cell to particular dimensions, using the deprecated "width" and "height" attributes. This makes it much clearer to see what is being shown, so I accept teh degraded valdiation for demonstration purposes.

return to top

word count = 534, excluding return-to-top links, code and table.

Array Usage

The use of arrays makes site maintenance and addition of a new code-sample simple:

Call the new page 'group6' ( i.e. sequential to the last)
Add an html-link into 'codeMain.html' (for accesibility)
Add to the following arrays in 'TT281.js':


//indexes into arrays relating to Pages 
//(i.e. page name and visitor count.)
var idxHome = 0,   idxFeedback=1, idxDesigner=2
var idxcodeMain=3, idxGroup1=4,   idxGroup2=5
var idxGroup3=6,   idxGroup4=7,   idxGroup5=8	

//Array of page names:
pageArray = new Array  _
("home.html","feedback.html","designer.html", "codeMain.html", _
"group1.html","group2.html","group3.html", _
"group4.html","group5.html")

//Array of code-sample page names 
//(*** relate in sequence to group1 = group5 above *** )
codePages = new Array  _
("Opening a New Window", "Select and Go", 
"Generating Dynamic Web Pages", _ 
"Manipulating the DOM", "Folding Tables")

The new page will auto-magically appear in all areas that use these arrays.

return to top

There should be a designer's page.
This page should list and summarise the client techniques that you have employed in the implementation of your site, and state why you have used them.
These techniques might be the same as or different from those of the illustrative JavaScript examples.

More weight will be given to the explanation of why you have taken the approach and used each of the techniques.
You should also briefly describe any measures you have taken to improve accessibility, browser independence and internationalisation of your site.

The designer's page should be no more than 500 words long.